Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#2733 WBEMClient.associatorClasses use wrong xml markup

Function
open
Dave Heller
jsr48-client
2
2014-09-15
2014-05-07
Jerry Yuan
No

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

1 Attachments

Discussion

  • Jerry Yuan
    Jerry Yuan
    2014-05-07

    Please review the attachment for the problem description.

     
  • Dave Blaschke
    Dave Blaschke
    2014-05-28

    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
    1406 )
    

    where:

    <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?

     
  • Jerry Yuan
    Jerry Yuan
    2014-06-13

    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.

    Regards, Jerry

     
  • Dave Blaschke
    Dave Blaschke
    2014-09-02

    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. (-:

     
    Last edit: Dave Blaschke 2014-09-02
  • Dave Blaschke
    Dave Blaschke
    2014-09-12

    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.

     
  • Dave Blaschke
    Dave Blaschke
    2014-09-15

    • Description has changed:

    Diff:

    --- old
    +++ new
    @@ -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
    
    • assigned_to: Dave Heller