Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
Mr Heller - FYI, in case you haven't been getting the email updates... looks like a little work in the client is required to fix this
Please review the attachment for the problem description.
The latest (1.4.0) version of DSP0200 defines the following for AssociatorNames:
1400 <objectPath>* AssociatorNames (
1401 [IN] <objectName> ObjectName,
1402 [IN,OPTIONAL,NULL] <className> AssocClass = NULL,
1403 [IN,OPTIONAL,NULL] <className> ResultClass = NULL,
1404 [IN,OPTIONAL,NULL] string Role = NULL,
1405 [IN,OPTIONAL,NULL] string ResultRole = NULL
<objectName> = (CLASSNAME|INSTANCENAME)
This is also described in the paragraph about ObjectName:
1410 The ObjectName input parameter defines the source CIM object whose associated names are to be
1411 returned. This is either a class or instance name (model path).
This same definition goes all the way back to the initial (1.0.0) version of DSP0200, so the problem does not relate to changed behavior.
What CIMOM are you using? Is it capable of handling both CLASSNAME and INSTANCENAME for the ObjectName parameter passed in to AssociatorNames?
Hi Dave, thanks for comments. We will check spec again.
We are using OpenPegasus as cimom server. V2.9 work with CLASSNAME and INSTANCENAME, but upgrading to 2.13 only support CLASSNAME.
I'm thinking it probably has something to do with OpenPegasus Bug 5904, which went into 2.13. Prior to its inclusion, Pegasus didn't care what came in from a client (INSTANCENAME vs CLASSNAME), it would just extract the ObjectName and return whatever that ObjectName represented (instances or classes). After its inclusion, Pegasus takes note of what came in from the client, and if it is INSTANCENAME but ObjectName is really a class, you get an error (and probably vice versa too, although that can't be tested with the client). At least that's my theory. (-:
Here's my take on the issue, but I may be missing something since I've looked at it for a grand total of... about an hour. There are three items of interest in the Java CIM Client's CIMClientXML_HelperImpl.java:
1) associatorNames_request (and the intended target of this bug): ObjectName can be a class (if COP represents class, e.g. has no keys) or an instance (if COP represents instance, e.g. has keys), but this method always calls createINSTANCENAME. This needs to be fixed.
2) associatorClasses_request: ObjectName must be a class (an exception is thrown if COP has keys), but this method calls createINSTANCENAME. This needs to be fixed.
3) referenceClasses_request: ObjectName must be a class (an exception is thrown if COP has keys), but this method calls createOBJECTNAME which is a waste since that method also checks to see if there are keys. This can just call createCLASSNAME directly, but this does not need to be fixed since it works... eventually.
I have attached a crude patch made against the HEAD branch, and have left the comments AND unneeded code in there.
@@ -1 +1 @@
+Mr Heller - FYI, in case you haven't been getting the email updates... looks like a little work in the client is required to fix this