You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(2) |
Feb
|
Mar
(4) |
Apr
|
May
(2) |
Jun
(2) |
Jul
|
Aug
|
Sep
(2) |
Oct
(2) |
Nov
(4) |
Dec
(1) |
2003 |
Jan
(2) |
Feb
(17) |
Mar
(14) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(21) |
2004 |
Jan
(27) |
Feb
(32) |
Mar
(28) |
Apr
(28) |
May
(5) |
Jun
(5) |
Jul
(8) |
Aug
(10) |
Sep
(25) |
Oct
(11) |
Nov
(4) |
Dec
(5) |
2005 |
Jan
(11) |
Feb
(2) |
Mar
|
Apr
(2) |
May
(16) |
Jun
(9) |
Jul
|
Aug
(18) |
Sep
(2) |
Oct
(3) |
Nov
(11) |
Dec
(7) |
2006 |
Jan
(6) |
Feb
(2) |
Mar
(3) |
Apr
(3) |
May
|
Jun
(2) |
Jul
(8) |
Aug
(10) |
Sep
|
Oct
(10) |
Nov
|
Dec
|
2007 |
Jan
(4) |
Feb
|
Mar
|
Apr
(17) |
May
(3) |
Jun
(1) |
Jul
(4) |
Aug
(3) |
Sep
(7) |
Oct
(8) |
Nov
(3) |
Dec
|
2008 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(2) |
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
2009 |
Jan
|
Feb
(1) |
Mar
|
Apr
(3) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: SourceForge.net <no...@so...> - 2011-04-24 13:47:31
|
Bugs item #3292431, was opened at 2011-04-24 09:47 Message generated for change (Tracker Item Submitted) made by rabinnh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116214&aid=3292431&group_id=16214 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Other Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: rabinnh (rabinnh) Assigned to: Nobody/Anonymous (nobody) Summary: Build on Linux Initial Comment: Version 3.2.2 - has this build even been tested? I ran ./configure and ./make. configure worked just fine, but while running make, I got a ton of errors. All of them are because of missing #includes for standard stuff like stdio.h, stdlib.h, string.h etc. It's hard for me to believe that someone actually tried to build this on Linux before posting this version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116214&aid=3292431&group_id=16214 |
From: SourceForge.net <no...@so...> - 2009-09-22 02:03:11
|
Patches item #1886143, was opened at 2008-02-04 01:19 Message generated for change (Settings changed) made by kpharris You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316214&aid=1886143&group_id=16214 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Siarhei Dzeraviaha (s_dzeraviaha) Assigned to: Nobody/Anonymous (nobody) Summary: Win32 patch (OpenWBEM part) Initial Comment: The goal of these changes is to pass the OpenWBEM acceptance tests on Windows. The both BloCxx and OpenWBEM code lines were modified so the OpenWBEM patch can’t be used without the corresponding BloCxx patch applied. The zipped files are grouped by the status: add[ed], del[eted], mod[ified]. I don’t have the write access to the CVS repository so I couldn’t create a usual patch file. The main change points are: 1. Win32 Project files were rearranged into the new directory structure to follow the Unix build system as close as possible. VisualStudioPropertySheet files (.vsprops) were used to hold the common project properties. 2. The scripts for automated build/testing were created. Native Windows Script was used instead of autoconf tool chain. Use make.bat to build and test the project. 3. Several source files were slightly changed to be Win32 friendly. Some OW_EXPORT/OW_IMPORT-related defines added. 4. OW_HTTPServer and OW_HTTPSvrConnection were simplified: unnecessary Win32-specific code snippets were removed. 5. The Win32 page size bug in __bt_open() function was fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316214&aid=1886143&group_id=16214 |
From: SourceForge.net <no...@so...> - 2009-09-22 02:01:48
|
Patches item #2782119, was opened at 2009-04-27 07:00 Message generated for change (Settings changed) made by kpharris You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316214&aid=2782119&group_id=16214 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Pawel Sklarow (psklarow) Assigned to: Nobody/Anonymous (nobody) Summary: CMPI broker bug under x86_64 Initial Comment: CMPI headers contain a bug replicable under x86_64 Linuxes - CMPI broker operation "getInstance" causes CIMOM crash with core dump. Problem is located in header file "openwbem-3.2.2/src/providerifcs/cmpi/common/cmpift.h" in declaration of _CMPIBrokerFT struct. Member _CMPIBrokerFT::brokerClassification type is "unsinged long" instead of "unsigned int" as defined by CMPI spec. In 32bit systems problem is not visible: sizeof(unsinged long) is 4 - like sizeof(unsigned int) defined by CMPI spec. But in x86_64 systems problems appears because sizeof(unsinged long) is 8 bytes and CMPI spec defines that as 4 bytes. So all following definitions are shifted. When CMPI provider attempts to call "_CMPIBrokerFT::getInstance" function, different function is called: "_CMPIBrokerFT::enumInstanceNames". This causes returning wrong object to the provider and when provider sends this object back to the CIMOM the CIMOM callback - that receives instances from the provider - treats this object like object returned by _CMPIBrokerFT::getInstance, but in fact the object is returned _CMPIBrokerFT::enumInstanceNames. Finally the CIMOM crashes with core dump. ---------------------------------------------------------------------- >Comment By: Kevin Harris (kpharris) Date: 2009-09-21 20:01 Message: A variant of this patch was applied. I used CMPIUint32 instead of unsigned int because it has a known size. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316214&aid=2782119&group_id=16214 |
From: Shreyas D <no...@ci...> - 2009-05-24 08:40:42
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> <title>Private Message from Shreyas is about to expire</title> </head> <body> <img src="http://www.faniq.com/invite_reminder_email.php?invite_id=231920226&stkn=c272fc8bf746fc9839b3998fb5698a7c&src=reminder2" width="1" height="1" alt=""/> <div style="width: 592px; height: 377px; font-family: Verdana; font-size: 12px; border: 1px solid #cccccc; text-align: center;"> <div style="background: #253D6E"> <a href="http://www.faniq.com/user/shreyasdeodhar/connect/231920226/?reminder2=dd07bf7e9b0b50d31072540d5c3a9d77"> <img src="http://cdn.faniq.com/img/email_template_header.png" width="592" height="97" border="0" alt="FanIQ" /> </a> </div> <div style="font-size: 1.5em; color: #5a5a5a; padding-top: 5px;"> Your private message from Shreyas will expire tonight at midnight. </div> <div style="color: #253D6E; font: bold 1.7em Verdana; margin-top: 12px;"> <a href="http://www.faniq.com/user/shreyasdeodhar/connect/231920226/?reminder2=dd07bf7e9b0b50d31072540d5c3a9d77" style="text-decoration: none; color: #253D6E"> Click to read message </a> </div> <div> <a href="http://www.faniq.com/user/shreyasdeodhar/connect/231920226/?reminder2=dd07bf7e9b0b50d31072540d5c3a9d77"> <img src="http://cdn.faniq.com/img/email_template_envelope2.png" width="127" height="91" border="0" alt="Click to read private message" /> </a> </div> <div style="font-size: 12px; font-weight: bold; margin-top: 10px; color: #253D6E"> Please read it or Shreyas will think you ignored this :( </div> <div style="font-size: 0.75em; color: #949494; padding: 0px 20px; text-align: left; margin-top: 30px;"> This message has been forwarded at the request of <a href="mailto:shr...@gm..." style="color: #949494">shr...@gm...</a>.To block all emails from FanIQ, please <a href="http://www.faniq.com/unsubscribe.php?invite_id=231920226&stkn=c272fc8bf746fc9839b3998fb5698a7c" style="color:#949494">click here</a>.FanIQ is located at 604 mission St, Suite 600, San Francisco, CA 94105, USA. </div> </div> </body> </html> |
From: SourceForge.net <no...@so...> - 2009-04-27 13:00:44
|
Patches item #2782119, was opened at 2009-04-27 15:00 Message generated for change (Tracker Item Submitted) made by psklarow You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316214&aid=2782119&group_id=16214 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pawel Sklarow (psklarow) Assigned to: Nobody/Anonymous (nobody) Summary: CMPI broker bug under x86_64 Initial Comment: CMPI headers contain a bug replicable under x86_64 Linuxes - CMPI broker operation "getInstance" causes CIMOM crash with core dump. Problem is located in header file "openwbem-3.2.2/src/providerifcs/cmpi/common/cmpift.h" in declaration of _CMPIBrokerFT struct. Member _CMPIBrokerFT::brokerClassification type is "unsinged long" instead of "unsigned int" as defined by CMPI spec. In 32bit systems problem is not visible: sizeof(unsinged long) is 4 - like sizeof(unsigned int) defined by CMPI spec. But in x86_64 systems problems appears because sizeof(unsinged long) is 8 bytes and CMPI spec defines that as 4 bytes. So all following definitions are shifted. When CMPI provider attempts to call "_CMPIBrokerFT::getInstance" function, different function is called: "_CMPIBrokerFT::enumInstanceNames". This causes returning wrong object to the provider and when provider sends this object back to the CIMOM the CIMOM callback - that receives instances from the provider - treats this object like object returned by _CMPIBrokerFT::getInstance, but in fact the object is returned _CMPIBrokerFT::enumInstanceNames. Finally the CIMOM crashes with core dump. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316214&aid=2782119&group_id=16214 |
From: SourceForge.net <no...@so...> - 2009-02-20 16:43:04
|
Bugs item #2620513, was opened at 2009-02-20 10:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116214&aid=2620513&group_id=16214 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Other Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matt Gulick (mattgulick) Assigned to: Nobody/Anonymous (nobody) Summary: Provider Compile Failures Initial Comment: Under both OpenSuSE 11.1 on an i686 platform and Fedora 10, I get errors when building openwbem. I downloaded the latest OpenWBEM-3.2.2. and ran ./configure which with no errors. I the ran make (as root) and I get the following error: ( I also tried OpenWBEM-3.1.0 and got different errors - See below) make[3]: Entering directory `/usr/local/openwbem-3.2.2/src/provideragent' if g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../src/common -I../../src/client -I../../src/common/socket -I../../src/cim -I../../src/ifcs -I../../src/http/common -I../../src/http/client -I../../src/services/http -I../../src/providerifcs/cpp -I../../src/provider -fno-enforce-eh-specs -g -O2 -fPIC -D_REENTRANT -D_GNU_SOURCE -pipe -DNDEBUG -O3 -MT OW_ProviderAgentCIMOMHandle.o -MD -MP -MF ".deps/OW_ProviderAgentCIMOMHandle.Tpo" -c -o OW_ProviderAgentCIMOMHandle.o OW_ProviderAgentCIMOMHandle.cpp; \ then mv -f ".deps/OW_ProviderAgentCIMOMHandle.Tpo" ".deps/OW_ProviderAgentCIMOMHandle.Po"; else rm -f ".deps/OW_ProviderAgentCIMOMHandle.Tpo"; exit 1; fi In file included from /usr/include/c++/4.3/backward/hash_map:64, from ../../src/common/OW_HashMap.hpp:40, from ../../src/common/OW_Cache.hpp:38, from OW_ProviderAgentEnvironment.hpp:46, from OW_ProviderAgentCIMOMHandle.hpp:45, from OW_ProviderAgentCIMOMHandle.cpp:38: /usr/include/c++/4.3/backward/backward_warning.h:33:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated. In file included from ../../src/common/OW_Cache.hpp:38, from OW_ProviderAgentEnvironment.hpp:46, from OW_ProviderAgentCIMOMHandle.hpp:45, from OW_ProviderAgentCIMOMHandle.cpp:38: ../../src/common/OW_HashMap.hpp:60: error: ‘hash’ is not a template ../../src/common/OW_HashMap.hpp:61: error: explicit specialization of non-template ‘std::hash’ ../../src/common/OW_HashMap.hpp: In member function ‘size_t std::hash::operator()(const OpenWBEM4::String&) const’: ../../src/common/OW_HashMap.hpp:64: error: ‘std::hash’ is not a template In file included from OW_ProviderAgentEnvironment.hpp:46, from OW_ProviderAgentCIMOMHandle.hpp:45, from OW_ProviderAgentCIMOMHandle.cpp:38: ../../src/common/OW_Cache.hpp: At global scope: ../../src/common/OW_Cache.hpp:100: error: ISO C++ forbids declaration of ‘hash_map’ with no type ../../src/common/OW_Cache.hpp:100: error: typedef name may not be a nested-name-specifier ../../src/common/OW_Cache.hpp:100: error: expected ‘;’ before ‘<’ token ../../src/common/OW_Cache.hpp:102: error: ‘cache_index_t’ does not name a type ../../src/common/OW_Cache.hpp: In member function ‘void OpenWBEM4::Cache<T>::addToCache(const T&, const OpenWBEM4::String&)’: ../../src/common/OW_Cache.hpp:118: error: ‘theCacheIndex’ was not declared in this scope ../../src/common/OW_Cache.hpp:129: error: ‘theCacheIndex’ was not declared in this scope ../../src/common/OW_Cache.hpp:129: error: ‘cache_index_t’ has not been declared ../../src/common/OW_Cache.hpp: In member function ‘T OpenWBEM4::Cache<T>::getFromCache(const OpenWBEM4::String&)’: ../../src/common/OW_Cache.hpp:139: error: ‘cache_index_t’ has not been declared ../../src/common/OW_Cache.hpp:139: error: expected initializer before ‘ii’ ../../src/common/OW_Cache.hpp:140: error: ‘ii’ was not declared in this scope ../../src/common/OW_Cache.hpp:140: error: ‘theCacheIndex’ was not declared in this scope ../../src/common/OW_Cache.hpp: In member function ‘void OpenWBEM4::Cache<T>::removeFromCache(const OpenWBEM4::String&)’: ../../src/common/OW_Cache.hpp:159: error: ‘cache_index_t’ has not been declared ../../src/common/OW_Cache.hpp:159: error: expected initializer before ‘i’ ../../src/common/OW_Cache.hpp:160: error: ‘i’ was not declared in this scope ../../src/common/OW_Cache.hpp:160: error: ‘theCacheIndex’ was not declared in this scope ../../src/common/OW_Cache.hpp: In member function ‘void OpenWBEM4::Cache<T>::clearCache()’: ../../src/common/OW_Cache.hpp:174: error: ‘theCacheIndex’ was not declared in this scope ../../src/common/OW_Cache.hpp: In member function ‘void OpenWBEM4::Cache<T>::setMaxCacheSize(OpenWBEM4::UInt32)’: ../../src/common/OW_Cache.hpp:185: error: ‘theCacheIndex’ was not declared in this scope make[3]: *** [OW_ProviderAgentCIMOMHandle.o] Error 1 make[3]: Leaving directory `/usr/local/openwbem-3.2.2/src/provideragent' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/openwbem-3.2.2/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/openwbem-3.2.2' make: *** [all] Error 2 When I tried OpenWBEM-3.1.0, I got different errors: source='OW_CIMDataType.cpp' object='OW_CIMDataType.o' libtool=no \ depfile='.deps/OW_CIMDataType.Po' tmpdepfile='.deps/OW_CIMDataType.TPo' \ depmode=gcc3 /bin/sh ../../depcomp \ g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../src/common -I../../src/ifcs -fno-enforce-eh-specs -fPIC -D_REENTRANT -D_GNU_SOURCE -pipe -DNDEBUG -O3 -c -o OW_CIMDataType.o `test -f 'OW_CIMDataType.cpp' || echo './'`OW_CIMDataType.cpp source='OW_CIMDateTime.cpp' object='OW_CIMDateTime.o' libtool=no \ depfile='.deps/OW_CIMDateTime.Po' tmpdepfile='.deps/OW_CIMDateTime.TPo' \ depmode=gcc3 /bin/sh ../../depcomp \ g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../src/common -I../../src/ifcs -fno-enforce-eh-specs -fPIC -D_REENTRANT -D_GNU_SOURCE -pipe -DNDEBUG -O3 -c -o OW_CIMDateTime.o `test -f 'OW_CIMDateTime.cpp' || echo './'`OW_CIMDateTime.cpp OW_CIMDateTime.cpp: In function ‘void OpenWBEM::fillDateTimeData(OpenWBEM::CIMDateTime::DateTimeData&, const char*)’: OW_CIMDateTime.cpp:339: error: ‘atoi’ was not declared in this scope OW_CIMDateTime.cpp:353: error: ‘atoi’ was not declared in this scope make[3]: *** [OW_CIMDateTime.o] Error 1 make[3]: Leaving directory `/usr/local/openwbem-3.1.0/src/cim' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/openwbem-3.1.0/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/openwbem-3.1.0' make: *** [all] Error 2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116214&aid=2620513&group_id=16214 |
From: Dan N. <dan...@qu...> - 2008-09-23 16:02:00
|
[The first time I sent this was during sf.net's transition of the list servers and it got rejected. Hopefully it makes it this time.] Hi all, Yesterday I discovered that the hard drive on cvs.openwbem.org had failed. We have been running backups of the repository, but I figured this would be a good time to transition to subversion. I have moved the entire repository over to sourceforge's subversion server. See https://sourceforge.net/svn/?group_id=16214 for information about accessing it. As there are actually 3 projects (codegen, exec-providers & openwbem) I changed the default subversion layout slightly so that each project is a top-level directory: openwbem/ trunk/ branches/ tags/ codegen/ trunk/ branches/ tags/ exec-providers/ trunk/ branches/ tags/ -- Dan |
From: SourceForge.net <no...@so...> - 2008-09-18 09:52:24
|
Patches item #2118170, was opened at 2008-09-18 19:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316214&aid=2118170&group_id=16214 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kanstantsin Dzenisevich (k_dzenisevich) Assigned to: Nobody/Anonymous (nobody) Summary: Sockets, Pipes, Exec Windows changes Initial Comment: Hi Dan, It's our new patch 'Sockets, Pipes' for OpenWBEM project. It's connected with BloCxx patch ID=2118165 and they should be applied together. The main changes are: 1) Many Windows dependant code was removed from OpenWBEM because of unifying Socket and UnnamedPipe implementation with Posix. 2) ThreadSafeProcess::getProcess(), OOPProviderBase::getProcess() were added to support a passing descriptors between related processes. 3) calcCheckSum() function workaround was added to avoid inline function optimization error. 4) DataTransfer in socketCat.cpp was improved ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316214&aid=2118170&group_id=16214 |
From: SourceForge.net <no...@so...> - 2008-08-21 09:04:18
|
Patches item #2064291, was opened at 2008-08-21 12:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316214&aid=2064291&group_id=16214 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kanstantsin Dzenisevich (k_dzenisevich) Assigned to: Nobody/Anonymous (nobody) Summary: FileSystem, PathSecurity changes Initial Comment: This patch must be applied together with 2059979 BloCxx patch https://sourceforge.net/tracker/index.php?func=detail&aid=2059979&group_id=176030&atid=875613 The patch was created and can by applied by the following commands: cvs diff -N -u >openwbem.patch patch -f -p0 -E < openwbem.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316214&aid=2064291&group_id=16214 |
From: SourceForge.net <no...@so...> - 2008-05-22 14:26:58
|
Bugs item #1969632, was opened at 2008-05-22 09:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116214&aid=1969632&group_id=16214 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Other Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Indravijay Gohil (indravijay) Assigned to: Nobody/Anonymous (nobody) Summary: Incomplete CMPI Implementation Initial Comment: The LSI MegaRAID provider has been successfully integrated with OpenPegasus and SFCB using the CMPI implementations available for those CIMOMs. Our expectations with regards to availability of features and completeness of a CMPI implementation have been set based on our experiences with those two CIMOMs. Coming from that perspective, we’ve found the OpenWBEM CMPI feature set wanting in a few areas. 1. cmpiObjectPath::refToString –we’ve made use of this function in our provider. An empty implementation (i.e. it returns “method not available”) is currently all that is available in the OpenWBEM CMPI implementation. The implementation is trivial and can be supplied by LSI. Replacing the current cmpiObjectPath.cpp file with our modified version and rebuilding the CMPI support library (libcmpisupport.so.4) fixes this problem. 2. cmpiObjectPath::refSetHostName –this function is missing from the OpenWBEM CMPI implementation. As with the above, the implementation is trivial and can be supplied by LSI. Again as above, replacing the current cmpiObjectPath.cpp file with our modified version and rebuilding the CMPI support library fixes the problem. 3. CmpiBroker::deliverIndication –the current OpenWBEM implementation throws an exception indicating that the method is not supported. LSI has made no attempt to resolve this issue. 4. CMPIIndicationMIFT.enableIndication –the method is implemented in the LSI provider. It must be called by OpenWBEM to activate the provider indication processing logic. OpenWBEM does not do so at this time (which is logical given that deliverIndication is not supported, as described in the previous item). This could be reasonably worked around in the LSI provider but if support were added for deliverIndication, this might as well be supported too. SIGIO Support Missing The LSI device management library (StoreLib) is notified of asynchronous events occurring on the device using SIGIO. The CIM provider, in turn, links in StoreLib and relies on StoreLib’s ability to receive these events. Receiving the events is crucial to the provider’s ability to maintain an accurate representation of the state of the device. The OpenWBEM OW_Platform.cpp (as compiled for SLES 9, 10) sets the handler for this signal to SIG_IGN which tells the operating system not to deliver the signal. Doing so prevents StoreLib and the LSI provider from receiving the signal. The OpenWBEM code is organized so as to make this a compile time option (i.e., it is ifdef protected). It is possible for the provider to reset the handler and thereby solve the problem. Doing so resets the handler for the whole CIMOM process, and as it was specifically turned off in OpenWBEM, we are unsure of the full impact of making this change in the provider. In limited testing it doesn’t seem to cause any problems, but we would like some history and background on the decision to turn off the signal. Conclusion LSI believes it is reasonable to expect the CIMOM to support customary event and indication handling. Provider-based workarounds for these issues, if possible, are very development-intensive, may involve firmware changes, and add complexity and fragility to the server management framework. The fixes are significantly more straightforward to make in the CIMOM, and LSI is willing to provide detailed support for such an effort. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116214&aid=1969632&group_id=16214 |
From: <sye...@gm...> - 2008-04-30 17:08:46
|
Does openwbem support ipv6 protocol? Thanks Atif Sent via BlackBerry from T-Mobile |
From: Shreyas D. <shr...@gm...> - 2008-04-09 14:15:38
|
/* * * cmpiObjectPath.cpp * * Copyright (c) 2002, International Business Machines * * THIS FILE IS PROVIDED UNDER THE TERMS OF THE COMMON PUBLIC LICENSE * ("AGREEMENT"). ANY USE, REPRODUCTION OR DISTRIBUTION OF THIS FILE * CONSTITUTES RECIPIENTS ACCEPTANCE OF THE AGREEMENT. * * You can obtain a current copy of the Common Public License from * http://oss.software.ibm.com/developerworks/opensource/license-cpl.html * * Author: Adrian Schuur <sc...@de...> * * Contributor: Markus Mueller <sed...@ya...> * * Description: CMPIObjectPath support * */ #include <iostream> #include "cmpisrv.h" static CMPIStatus refRelease(CMPIObjectPath* eRef) { OpenWBEM::CIMObjectPath* ref=(OpenWBEM::CIMObjectPath*)eRef->hdl; if (ref) { delete ref; ((CMPI_Object*)eRef)->unlinkAndDelete(); } CMReturn(CMPI_RC_OK); } static CMPIStatus refReleaseNop(CMPIObjectPath* eRef) { CMReturn(CMPI_RC_OK); } static CMPIObjectPath* refClone(const CMPIObjectPath* eRef, CMPIStatus* rc) { OpenWBEM::CIMObjectPath *ref=(OpenWBEM::CIMObjectPath*)eRef->hdl; //OpenWBEM::CIMObjectPath *nRef=new OpenWBEM::CIMObjectPath(ref->getClassName(), // ref->getNameSpace()); //nRef->setHost(ref->getHost()); //nRef->setKeys(ref->getKeys()); OpenWBEM::CIMObjectPath *nRef = new OpenWBEM::CIMObjectPath(* ref); CMPIObjectPath* neRef=(CMPIObjectPath*)new CMPI_Object(nRef,CMPI_ObjectPath_Ftab); CMSetStatus(rc,CMPI_RC_OK); return neRef; } static CMPIStatus refSetNameSpace(CMPIObjectPath* eRef, const char* ns) { OpenWBEM::CIMObjectPath* ref=(OpenWBEM::CIMObjectPath*)eRef->hdl; ref->setNameSpace(OpenWBEM::String(ns)); CMReturn(CMPI_RC_OK); } static CMPIStatus refSetHostName(CMPIObjectPath* eRef, const char* ns) { OpenWBEM::CIMObjectPath* ref=(OpenWBEM::CIMObjectPath*)eRef->hdl; ref->setHost(OpenWBEM::String(ns)); CMReturn(CMPI_RC_OK); } static CMPIString* refGetNameSpace(const CMPIObjectPath* eRef, CMPIStatus* rc) { OpenWBEM::CIMObjectPath* ref=(OpenWBEM::CIMObjectPath*)eRef->hdl; const OpenWBEM::String &ns=ref->getNameSpace(); CMPIString *eNs=string2CMPIString(ns); CMSetStatus(rc,CMPI_RC_OK); return eNs; } static CMPIStatus refSetClassName(CMPIObjectPath * eRef,const char * cl) { OpenWBEM::CIMObjectPath* ref=(OpenWBEM::CIMObjectPath*)eRef->hdl; ref->setClassName(OpenWBEM::String(cl)); CMReturn(CMPI_RC_OK); } static CMPIString* refGetClassName(const CMPIObjectPath* eRef, CMPIStatus* rc) { OpenWBEM::CIMObjectPath * ref=(OpenWBEM::CIMObjectPath*)eRef->hdl; const OpenWBEM::String &cn=ref->getClassName(); CMPIString* eCn=string2CMPIString(cn); CMSetStatus(rc,CMPI_RC_OK); return eCn; } static long locateKey(const OpenWBEM::CIMPropertyArray &kb, const OpenWBEM::String& eName) { for (unsigned long i=0,s=kb.size(); i<s; i++) { const OpenWBEM::String &n=kb[i].getName(); if (n.equalsIgnoreCase(eName)) { return i; } } return -1; } static CMPIStatus refAddKey(CMPIObjectPath* eRef, const char* name, const CMPIValue* data, const CMPIType type) { OpenWBEM::CIMObjectPath* ref=(OpenWBEM::CIMObjectPath*)eRef->hdl; OpenWBEM::CIMPropertyArray keyBindings=ref->getKeys(); OpenWBEM::String key(name); CMPIrc rc; long i = locateKey(keyBindings, key); if (i >= 0) { keyBindings.remove(i); ref->setKeys(keyBindings); } OpenWBEM::CIMValue val = value2CIMValue(data,type,&rc); ref->setKeyValue(key, val); CMReturn(CMPI_RC_OK); } static CMPIData refGetKey(const CMPIObjectPath* eRef, const char* name, CMPIStatus* rc) { OpenWBEM::CIMObjectPath* ref=(OpenWBEM::CIMObjectPath*)eRef->hdl; const OpenWBEM::String eName(name); OpenWBEM::CIMProperty cpr = ref->getKey(eName); CMPIData data = {(CMPIType) 0, CMPI_nullValue, {0} }; CMSetStatus(rc,CMPI_RC_OK); if (cpr) { OpenWBEM::CIMValue cv = cpr.getValue(); value2CMPIData(cv, type2CMPIType(cv.getType(), cv.isArray()), &data); return data; } CMSetStatus(rc,CMPI_RC_ERR_NOT_FOUND); return data; } static CMPIData refGetKeyAt(const CMPIObjectPath* eRef, unsigned pos, CMPIString** name, CMPIStatus* rc) { OpenWBEM::CIMObjectPath* ref=(OpenWBEM::CIMObjectPath*)eRef->hdl; const OpenWBEM::CIMPropertyArray &akb=ref->getKeys(); CMPIData data={(CMPIType) 0, CMPI_nullValue, {0} }; CMSetStatus(rc,CMPI_RC_OK); if (pos >= akb.size()) { CMSetStatus(rc,CMPI_RC_ERR_NOT_FOUND); return data; } OpenWBEM::CIMValue cv = akb[pos].getValue(); value2CMPIData(cv, type2CMPIType(cv.getType(),cv.isArray()) ,&data); if (name) { const OpenWBEM::String &n=akb[pos].getName(); *name=string2CMPIString(n); } return data; } static CMPICount refGetKeyCount(const CMPIObjectPath* eRef, CMPIStatus* rc) { OpenWBEM::CIMObjectPath* ref=(OpenWBEM::CIMObjectPath*)eRef->hdl; const OpenWBEM::CIMPropertyArray &akb=ref->getKeys(); CMSetStatus(rc,CMPI_RC_OK); return akb.size(); } static CMPIStatus refSetNameSpaceFromObjectPath(CMPIObjectPath* eRef, const CMPIObjectPath* eSrc) { OpenWBEM::CIMObjectPath* ref=(OpenWBEM::CIMObjectPath*)eRef->hdl; OpenWBEM::CIMObjectPath* src=(OpenWBEM::CIMObjectPath*)eSrc->hdl; ref->setNameSpace(src->getNameSpace()); CMReturn(CMPI_RC_OK); } #if 0 static CMPIBoolean refClassPathIsA(CMPIObjectPath *eRef, char * classname, CMPIStatus * rc) { return false; } #endif #if defined(CMPI_VER_86) /** Generates a well formed string representation of this ObjectPath @param op ObjectPath this pointer. @param rc Output: Service return status (suppressed when NULL). @return String representation. */ static CMPIString *refToString(const CMPIObjectPath* op, CMPIStatus *rc) { OpenWBEM::CIMObjectPath* ref=(OpenWBEM::CIMObjectPath*)op->hdl; const OpenWBEM::String &n =ref->toString(); CMPIString* eCn=string2CMPIString(n); return eCn; } #endif static CMPIObjectPathFT objectPath_FT={ CMPICurrentVersion, refRelease, refClone, refSetNameSpace, refGetNameSpace, refSetHostName, // setHostName NULL, // getHostName refSetClassName, refGetClassName, refAddKey, refGetKey, refGetKeyAt, refGetKeyCount, refSetNameSpaceFromObjectPath, NULL, //refSetHostAndNameSpaceFromObjectPath, //refClassPathIsA, // no qualifier support yet NULL, NULL, NULL, NULL, refToString // toString }; CMPIObjectPathFT *CMPI_ObjectPath_Ftab=&objectPath_FT; static CMPIObjectPathFT objectPathOnStack_FT={ CMPICurrentVersion, refReleaseNop, refClone, refSetNameSpace, refGetNameSpace, refSetHostName, // setHostName NULL, // getHostName refSetClassName, refGetClassName, refAddKey, refGetKey, refGetKeyAt, refGetKeyCount, refSetNameSpaceFromObjectPath, NULL, //refSetHostAndNameSpaceFromObjectPath, //refClassPathIsA, // no qualifier support yet NULL, NULL, NULL, NULL, refToString // toString }; CMPIObjectPathFT *CMPI_ObjectPathOnStack_Ftab=&objectPathOnStack_FT; CMPI_ObjectPathOnStack::CMPI_ObjectPathOnStack(const OpenWBEM::CIMObjectPath& cop) { hdl=(void*)&cop; ft=CMPI_ObjectPathOnStack_Ftab; } |
From: SourceForge.net <no...@so...> - 2008-02-04 08:19:03
|
Patches item #1886143, was opened at 2008-02-04 10:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316214&aid=1886143&group_id=16214 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Siarhei Dzeraviaha (s_dzeraviaha) Assigned to: Nobody/Anonymous (nobody) Summary: Win32 patch (OpenWBEM part) Initial Comment: The goal of these changes is to pass the OpenWBEM acceptance tests on Windows. The both BloCxx and OpenWBEM code lines were modified so the OpenWBEM patch can’t be used without the corresponding BloCxx patch applied. The zipped files are grouped by the status: add[ed], del[eted], mod[ified]. I don’t have the write access to the CVS repository so I couldn’t create a usual patch file. The main change points are: 1. Win32 Project files were rearranged into the new directory structure to follow the Unix build system as close as possible. VisualStudioPropertySheet files (.vsprops) were used to hold the common project properties. 2. The scripts for automated build/testing were created. Native Windows Script was used instead of autoconf tool chain. Use make.bat to build and test the project. 3. Several source files were slightly changed to be Win32 friendly. Some OW_EXPORT/OW_IMPORT-related defines added. 4. OW_HTTPServer and OW_HTTPSvrConnection were simplified: unnecessary Win32-specific code snippets were removed. 5. The Win32 page size bug in __bt_open() function was fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=316214&aid=1886143&group_id=16214 |
From: SourceForge.net <no...@so...> - 2008-01-11 06:34:07
|
Bugs item #1869052, was opened at 2008-01-11 06:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116214&aid=1869052&group_id=16214 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Other Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Manju (jmanju) Assigned to: Nobody/Anonymous (nobody) Summary: Path separator specified wrongly in openwem.conf comments Initial Comment: For many multi-valued path options in openwbem.conf (e.g, cppprovifc.prov_location), the separator is specified as ":" for Windows and ";" for POSIX systems. But giving two paths separated by ";" (path1;path2) for cppprovifc.prov_location in a Linux machine and running owcimomd resulted in the error "C++ provider ifc failed getting contents of directory:path1;path2", and it failed to load any C++ provider. The separator should actually be ":" for Linux and ";" for Windows: In src/common/OW_Types.hpp, the following are defined: #ifdef OW_WIN32 #define OW_PATHNAME_SEPARATOR ";" #else #define OW_PATHNAME_SEPARATOR ":" #endif The following patch changes the comments in etc/openwbem.conf.sh to fix this problem in openwbem 3.2.2. (I haven't checked for this bug in any other version.) Apply it from the directory openwbem-3.2.2/etc/ and use the option -p1 for patch. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% --- etc/openwbem.conf.sh 2008-01-11 16:51:15.000000000 +0530 +++ etc/openwbem.conf.sh.new 2008-01-11 14:25:31.000000000 +0530 @@ -20,7 +20,7 @@ ################################################################################ # For each directory specified, all the files contained in the directory will # be loaded and processed as additional config files. -# This is a multi-valued option. ':' (windows) or ';' (POSIX) is the separator. +# This is a multi-valued option. ';' (windows) or ':' (POSIX) is the separator. # This option will be evaluated after the main config file is parsed, and so # additional directories specified in additional config files will not be # examined. @@ -526,7 +526,7 @@ ################################################################################ # owcimomd.services_path Specifies the directory containing the services # shared libraries to be loaded by the CIMOM. -# This is a multi-valued option. ':' (windows) or ';' (POSIX) is the separator. +# This is a multi-valued option. ';' (windows) or ':' (POSIX) is the separator. # You probably don't need to modify this option. # The default is "@libdir@/openwbem/services" owcimomd.services_path = @libdir@/openwbem/services @@ -534,7 +534,7 @@ ################################################################################ # owcimomd.request_handler_path Specifies the directory containing the # request handler shared libraries to be loaded by the CIMOM. -# This is a multi-valued option. ':' (windows) or ';' (POSIX) is the separator. +# This is a multi-valued option. ';' (windows) or ':' (POSIX) is the separator. # You probably don't need to modify this option. # The default is "@libdir@/openwbem/requesthandlers" owcimomd.request_handler_path = @libdir@/openwbem/requesthandlers @@ -566,7 +566,7 @@ # interfaces will be loaded from. owcimomd assumes all shared libraries in # these directories are provider interfaces. If a shared library in this directory # does not support the provider interface api, it will be rejected. -# This is a multi-valued option. ':' (windows) or ';' (POSIX) is the separator. +# This is a multi-valued option. ';' (windows) or ':' (POSIX) is the separator. # You probably don't need to modify this option. # The default is "@libdir@/openwbem/provifcs" owcimomd.provider_ifc_libs = @libdir@/openwbem/provifcs @@ -575,7 +575,7 @@ # One of the provider interfaces provided with owcimomd is the C++ provider # interface. The cppprovifc.prov_location option specifies where the C++ # provider interface will load it's providers from. -# This is a multi-valued option. ':' (windows) or ';' (POSIX) is the separator. +# This is a multi-valued option. ';' (windows) or ':' (POSIX) is the separator. # You probably don't need to modify this option. # The default is "@libdir@/openwbem/c++providers" cppprovifc.prov_location = @libdir@/openwbem/c++providers @@ -584,7 +584,7 @@ # One of the provider interfaces provided with owcimomd is the OWBI1 provider # interface. The owbi1provifc.prov_location option specifies where the OWBI1 # provider interface will load it's providers from. -# This is a multi-valued option. ':' (windows) or ';' (POSIX) is the separator. +# This is a multi-valued option. ';' (windows) or ':' (POSIX) is the separator. # You probably don't need to modify this option. # The default is "@libdir@/openwbem/owbi1providers" owbi1provifc.prov_location = @libdir@/openwbem/owbi1providers @@ -609,7 +609,7 @@ # One of the provider interfaces provided with owcimomd is the NPI provider # interface. The npiprovifc.prov_location option specifies where the NPI # provider interface will load it's providers from. -# This is a multi-valued option. ':' (windows) or ';' (POSIX) is the separator. +# This is a multi-valued option. ';' (windows) or ':' (POSIX) is the separator. # The default is "@libdir@/openwbem/npiproviders" npiprovifc.prov_location = @libdir@/openwbem/npiproviders @@ -617,7 +617,7 @@ # One of the provider interfaces provided with owcimomd is the CMPI provider # interface. The cmpiprovifc.prov_location option specifies where the CMPI # provider interface will load it's providers from. -# This is a multi-valued option. ':' (windows) or ';' (POSIX) is the separator. +# This is a multi-valued option. ';' (windows) or ':' (POSIX) is the separator. # The default is "@libdir@/openwbem/cmpiproviders" cmpiprovifc.prov_location = @libdir@/openwbem/cmpiproviders @@ -634,7 +634,7 @@ # One of the provider interfaces provided with owcimomd is the perl provider # interface. The perlprovifc.prov_location option specifies where the perl # provider interface will load it's providers from. -# This is a multi-valued option. ':' (windows) or ';' (POSIX) is the separator. +# This is a multi-valued option. ';' (windows) or ':' (POSIX) is the separator. # The default is "@libdir@/openwbem/perlproviders" perlprovifc.prov_location = @libdir@/openwbem/perlproviders %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% --Manju ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116214&aid=1869052&group_id=16214 |
From: Dan N. <Dan...@qu...> - 2007-11-26 21:08:06
|
It looks like the enumInstanceNames pointer is null which is the direct cau= se of your crash. The real problem though is with whatever set it to null, = since it shouldn't be null, it should be pointing to the mbEnumInstanceName= s function. It also looks like the brokerVersion and brokerName are also in= correct. Probably something overwrote memory and clobbered the bft table. Y= ou could try using valgrind, it may point you to the culprit. -- Dan -----Original Message----- From: ope...@li... [mailto:openwbem-devel-b= ou...@li...] On Behalf Of Ramandeep Kaur Sent: Wednesday, November 21, 2007 9:53 PM To: ope...@li... Subject: [Openwbem-devel] CMPI issue Hi, I am working on the CMPI providers for OpenWBEM. I have two providers A and= B. Whenever I try to invoke enumInstanceNames of Provider B from an extrinsic = method of Provider A, it results in segmentation fault. Although, when enum= InstanceNames of B is invoked from any CIM Client, it is always successful. While debugging the problem with gdb, I am getting following trace: 166 en =3D broker->bft->enumInstanceNames(broker, ctx, oPath, r= c); (gdb) p *broker->bft $1 =3D {brokerCapabilities =3D 0, brokerVersion =3D 0, brokerName =3D 0x64 = <Address 0x64 out of bounds>, prepareAttachThread =3D 0x2b15c878a705 <_fini+19126925>, attachThread =3D= 0, detachThread =3D 0, deliverIndication =3D 0, enumInstanceNames =3D 0, getInstance =3D 0x2b15c8777db0 <_fini+19050808>,= createInstance =3D 0x2b15c877bcb0 <_fini+19066936>, modifyInstance =3D 0x2b15c8779bd0 <_fini+19058520>, deleteInstance =3D 0x= 2b15c877b630 <_fini+19065272>, execQuery =3D 0x2b15c8779690 <_fini+19057176>, enumInstances =3D 0x2b15c8= 778ec0 <_fini+19055176>, associators =3D 0x2b15c8778510 <_fini+19052696>, associatorNames =3D 0x2b= 15c877ab90 <_fini+19062552>, references =3D 0x2b15c8777520 <_fini+19048616>, referenceNames =3D 0x2b15= c877a180 <_fini+19059976>, invokeMethod =3D 0x2b15c8776d60 <_fini+19046632>, setProperty =3D 0x2b15c= 8776660 <_fini+19044840>, getProperty =3D 0x2b15c8775a80 <_fini+19041800>} (gdb) Plz share your inputs for resolving this problem. Regards Raman ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Openwbem-devel mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/openwbem-devel |
From: Ramandeep K. <RK...@no...> - 2007-11-22 04:48:48
|
Hi, I am working on the CMPI providers for OpenWBEM. I have two providers A = and B. Whenever I try to invoke enumInstanceNames of Provider B from an extrinsic = method of Provider A, it results in segmentation fault. Although, when = enumInstanceNames of B is invoked from any CIM Client, it is always = successful. While debugging the problem with gdb, I am getting following trace: 166 en =3D broker->bft->enumInstanceNames(broker, ctx, oPath, = rc); (gdb) p *broker->bft $1 =3D {brokerCapabilities =3D 0, brokerVersion =3D 0, brokerName =3D 0x64 = <Address 0x64 out of bounds>, prepareAttachThread =3D 0x2b15c878a705 <_fini+19126925>, attachThread = =3D 0, detachThread =3D 0, deliverIndication =3D 0, enumInstanceNames =3D 0, getInstance =3D 0x2b15c8777db0 <_fini+19050808>,= createInstance =3D 0x2b15c877bcb0 <_fini+19066936>, modifyInstance =3D 0x2b15c8779bd0 <_fini+19058520>, deleteInstance =3D = 0x2b15c877b630 <_fini+19065272>, execQuery =3D 0x2b15c8779690 <_fini+19057176>, enumInstances =3D = 0x2b15c8778ec0 <_fini+19055176>, associators =3D 0x2b15c8778510 <_fini+19052696>, associatorNames =3D = 0x2b15c877ab90 <_fini+19062552>, references =3D 0x2b15c8777520 <_fini+19048616>, referenceNames =3D = 0x2b15c877a180 <_fini+19059976>, invokeMethod =3D 0x2b15c8776d60 <_fini+19046632>, setProperty =3D = 0x2b15c8776660 <_fini+19044840>, getProperty =3D 0x2b15c8775a80 <_fini+19041800>} (gdb) Plz share your inputs for resolving this problem. Regards Raman |
From: SourceForge.net <no...@so...> - 2007-11-13 04:29:03
|
Bugs item #1830852, was opened at 2007-11-13 13:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116214&aid=1830852&group_id=16214 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Other Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Frederic Desmons (penpenthetom) Assigned to: Nobody/Anonymous (nobody) Summary: CMPI interface non-standard declarations Initial Comment: In OpenWBEM 3.2.2. In file src/providerifcs/cmpi/common/cmpift.h, declaration of _CMPIBrokerFT: unsigned long brokerClassification should be unsigned int brokerCapabilities; enumInstances() should be enumerateInstances() enumInstanceNames() should be enumerateInstanceNames() This is documented in version 1 and 2 of the CMPI specification: http://www.opengroup.org/bookstore/catalog/select.tpl?text=cmpi And in the offical CMPI headers from the OpenGroup: http://www.opengroup.org/tech/management/cmpi/ The declaration in the cmpift.h file and the definition in the source code as well as the internal references should be changed to the standard name. Best regards, Frederic Desmons ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=116214&aid=1830852&group_id=16214 |
From: Mike M. <bi...@ya...> - 2007-10-11 04:36:27
|
Could anyone share with me how to build OpenWBEM with Visual C++ 2005 on Windows or share with me your Project files for VC 2005 so that I build the kit owwin32? Could someone also post the PDB files for owwin32? Thanks in advance, Mike Mike <bi...@ya...> wrote: Hi, I am wondering if anyone has the Project file for VC2005 of OpenWBEM. Does anyone have any info on how to build it on Windows? I am especially interested in building the CIM Client SDK in addition to OpemWBEM CIMOM. Regards, -Mike --------------------------------- Check out the hottest 2008 models today at Yahoo! Autos. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/_______________________________________________ Openwbem-devel mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/openwbem-devel --------------------------------- Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. |
From: Mike M. <bi...@ya...> - 2007-10-11 04:20:35
|
Hi Everyone, Does anyone know why the following (property filtering) code is causing openWBEM api to crash (when testing with OpenPegasus CIMOM)? Any working-around for this issue or did I do something wrong? It is also oddly strange that the try-catch exception handling does not work neither! try { StringArray myPropertyList; myPropertyList.append("Name"); CIMOMHandleIFCRef ch = ClientCIMOMHandle::createFromURL("http://user:pwd@localhost:5988/root/pg_interop"); CIMInstanceEnumeration enu = ch->enumInstancesE("root/pg_interop", "CIM_namespace", WBEMFlags::E_DEEP, WBEMFlags::E_NOT_LOCAL_ONLY, WBEMFlags::E_EXCLUDE_QUALIFIERS, WBEMFlags::E_EXCLUDE_CLASS_ORIGIN, &myPropertyList);//OpenWBEM API crashes here with ¡§access violation" } catch (const CIMException& e) { txtResult = (const char*) e.getDescription () ; } catch (Exception& e) { txtResult = e.getMessage(); } catch (...) { txtResult = "Unknown Exception"; } -Mike --------------------------------- Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. |
From: Dan N. <dan...@qu...> - 2007-10-10 12:21:54
|
On Wed, 2007-10-10 at 15:15 +0530, Nagasamudram, Prasanna Kumar wrote: > Hi All > > > > Is it possible to write providers in java for openWBEM. > > > > I know its possible in wbemservices. > > > > But is it possible in openWBEM ? > > You could do it, but it would be a lot of work because you'd have to write the JNI translation layer yourself. Architecturally, it would be best to write a java provider interface that could run any java provider. As far as I know, no one has done this for OpenWBEM, but it is possible to do. There is a java provider interface for OpenPegasus, so you might be able to leverage a lot of that code and port it over to OpenWBEM. -- Dan |
From: Nagasamudram, P. K. <Pra...@in...> - 2007-10-10 09:49:50
|
Hi All =20 Is it possible to write providers in java for openWBEM. =20 I know its possible in wbemservices. =20 But is it possible in openWBEM ? =20 Thanks Prasanna |
From: Mike <bi...@ya...> - 2007-10-08 01:15:41
|
Bart, Thanks for the response. For the HTTPS requests, I think the exception was caused by a bug in the OpenWbem code. It incorrectly assumes that the app can write to and create the file ¡§C:/.rnd¡¨; But for my windows system, only System Admin can write to C:\; but when OpenWBEM fails to create a file handle on c:\, it just crashed. A better solution is to just create the file ¡§.rnd¡¨ on %HOMEPATH% (rather than c:\). For the properpty filtering, I still haven¡¦t figured out why I am still getting unknow exception(actually OpenWBEM API crashes with ¡§access violation¡¨). Here is my code sampe: StringArray myPropertyList; myPropertyList.append("Name"); CIMOMHandleIFCRef ch = ClientCIMOMHandle::createFromURL("http://user:pwd@localhost:5988/root/pg_interop"); CIMInstanceEnumeration enu = ch->enumInstancesE("root/pg_interop", "CIM_namespace", WBEMFlags::E_DEEP, WBEMFlags::E_NOT_LOCAL_ONLY, WBEMFlags::E_EXCLUDE_QUALIFIERS, WBEMFlags::E_EXCLUDE_CLASS_ORIGIN, &myPropertyList);//OpenWBEM crashes here with ¡§access violation Any ideas or other suggestions? Regards, -Mike Bart Whiteley <ba...@wh...> wrote: On 10/4/07, Mike <bi...@ya...> wrote: Hello Everyone, I was trying to use OpenWBEM CIMclient to make a connection over HTTPS; but I got an unknown exception. Here is my code sample: try { CIMClient securedClient(" https://user:passwd@localhost:5989/cimom" , "root/pg_interop"); securedClient.getClass(...); /// print the result } catch (const CIMException& e) { //print CIM exception } catch (...) { // print "Unknown Exception"; } Did I miss anything? Or how should I make a HTTPS connection to a CIMOM? By the way, I was also able to use Pegasus CIM CLI to connect via HTTPS on port 5989. So I guest I must miss something. Help or suggestions are greatly appreciated. By the way, does anyone know any good examples on how to use OpenWbem CIMClient, specicially the CIM Client APIs with the proprerty filtering? For example, how to tell the CIMClient to filer out all the properties exception "name" for CIM_System of enumInstancesE() without causing a unknown exception? Try this: #include <openwbem/OW_ClientCIMOMHandle.hpp> #include <openwbem/OW_CIMInstance.hpp> #include <openwbem/OW_CIMInstanceEnumeration.hpp> #include <openwbem/OW_CIMValue.hpp> #include <iostream> using namespace OpenWBEM; int main() { CIMOMHandleIFCRef ch = ClientCIMOMHandle::createFromURL(" https://root:secret@localhost/root/cimv2"); StringArray propertyList; propertyList.append("Name"); CIMInstanceEnumeration enu = ch->enumInstancesE("/root/cimv2", "CIM_System", WBEMFlags::E_DEEP, WBEMFlags::E_NOT_LOCAL_ONLY, WBEMFlags::E_EXCLUDE_QUALIFIERS, WBEMFlags::E_EXCLUDE_CLASS_ORIGIN, &propertyList); while(enu.hasMoreElements ()) { CIMInstance inst = enu.nextElement(); CIMValue cv = inst.getPropertyValue("Name"); String name; cv.get(name); std::cout << name << std::endl; } } --------------------------------- Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. |
From: Bart W. <bwh...@no...> - 2007-10-06 16:33:44
|
Mike wrote: > Hello Everyone, > I was trying to use OpenWBEM CIMclient to make a connection over > HTTPS; but I got an unknown exception. Here is my code sample: > > try > { > > CIMClient securedClient("https://user:passwd@localhost:5989/cimom" , > "root/pg_interop"); > > securedClient.getClass(...); > /// print the result > } > catch (const CIMException& e) > { > //print CIM exception > } > catch (...) > { > // print "Unknown Exception"; > } > > Did I miss anything? Or how should I make a HTTPS connection to a > CIMOM? > > By the way, I was also able to use Pegasus CIM CLI to connect via > HTTPS on port 5989. > > So I guest I must miss something. Help or suggestions are greatly > appreciated. > > By the way, does anyone know any good examples on how to use OpenWbem > CIMClient, specicially the CIM Client APIs with the proprerty > filtering? For example, how to tell the CIMClient to filer out all > the properties exception "name" for CIM_System of enumInstancesE() > without causing a unknown exception? > Try this: #include <openwbem/OW_ClientCIMOMHandle.hpp> #include <openwbem/OW_CIMInstance.hpp> #include <openwbem/OW_CIMInstanceEnumeration.hpp> #include <openwbem/OW_CIMValue.hpp> #include <iostream> using namespace OpenWBEM; int main() { CIMOMHandleIFCRef ch = ClientCIMOMHandle::createFromURL("https://root:secret@localhost/root/cimv2"); StringArray propertyList; propertyList.append("Name"); CIMInstanceEnumeration enu = ch->enumInstancesE("/root/cimv2", "CIM_System", WBEMFlags::E_DEEP, WBEMFlags::E_NOT_LOCAL_ONLY, WBEMFlags::E_EXCLUDE_QUALIFIERS, WBEMFlags::E_EXCLUDE_CLASS_ORIGIN, &propertyList); while(enu.hasMoreElements()) { CIMInstance inst = enu.nextElement(); CIMValue cv = inst.getPropertyValue("Name"); String name; cv.get(name); std::cout << name << std::endl; } } |
From: Mike <bi...@ya...> - 2007-10-05 02:20:20
|
Hello Everyone, I was trying to use OpenWBEM CIMclient to make a connection over HTTPS; but I got an unknown exception. Here is my code sample: try { CIMClient securedClient("https://user:passwd@localhost:5989/cimom" , "root/pg_interop"); securedClient.getClass(...); /// print the result } catch (const CIMException& e) { //print CIM exception } catch (...) { // print "Unknown Exception"; } Did I miss anything? Or how should I make a HTTPS connection to a CIMOM? By the way, I was also able to use Pegasus CIM CLI to connect via HTTPS on port 5989. So I guest I must miss something. Help or suggestions are greatly appreciated. By the way, does anyone know any good examples on how to use OpenWbem CIMClient, specicially the CIM Client APIs with the proprerty filtering? For example, how to tell the CIMClient to filer out all the properties exception "name" for CIM_System of enumInstancesE() without causing a unknown exception? Regards, -Mike --------------------------------- Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. |
From: Mike <bi...@ya...> - 2007-10-05 01:54:57
|
Hi, I am wondering if anyone has the Project file for VC2005 of OpenWBEM. Does anyone have any info on how to build it on Windows? I am especially interested in building the CIM Client SDK in addition to OpemWBEM CIMOM. Regards, -Mike --------------------------------- Check out the hottest 2008 models today at Yahoo! Autos. |