[Sblim-issues] [ sblim-Bugs-1760613 ] GetInstance fails on repository association

[SourceForge.net <no...@so...>]

Bugs item #1760613, was opened at 2007-07-25 23:40
Message generated for change (Settings changed) made by ebak
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1760613&group_id=128809

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: Java Client (JSR48)
Group: Function
>Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: David Simpson (dasimpso)
Assigned to: Endre Bak (ebak)
Summary: GetInstance fails on repository association

Initial Comment:
I've got instances of the CIM_ReferencedProfile association defined in an OpenPegasus (V2.5.2) repository.  Using the Java client, I issue a EnumerateInstanceNames for this class and then issue a GetInstance request using one of the returned CIMInstance objects.  This request fails with an ERR_NOT_FOUND return code.  Using the CLI client, I'm able to enumerate names and successfully get one of the instances that are returned.

Comparing traces of the two scenarios, the difference appears to be in the namespace specification for the object reference key properties in the association instances.  In the CLI case, the namespaces are specified as "root/PGInterOp", which exactly matches the way the instance was created in the repository.  With the Java Client, the namespaces are specified as "//dasimpso/root/PGInterOp".  Given that the instances reside on host "dasimpso", I don't understand why these are not equivalent, but Pegasus does not appear to be treating them as such.  I can create the same error by adding the host to the CLI GetInstance request.

This may very well be a bug or limitation of Pegasus, however when all is said and done, I would expect the Java Client to be able to successfully fetch any path returned in a previous enumeration.

This problem appears to be limited to instances that exist in the repository, as I have no problem doing the same requests for any of my other association classes, which are all serviced by providers.

I am attaching a CIM trace.  The first two request/response pairs correspond to the CLI requests that are successful.  The remaining request/response pairs are generated by my Java Client testcase that is failing.

----------------------------------------------------------------------

Comment By: David Simpson (dasimpso)
Date: 2007-08-29 23:54

Message:
Logged In: YES 
user_id=1825322
Originator: YES

I have discovered that this bug is due to my own code.  In an effort to
compare different types of object paths, the code was "fixing up" objects
paths by adding the hostname when it did not exist.  Enumerated object
paths were fixed as soon as they were received, so when one of those paths
was later used in a getInstance() call, it contained a hostname that wasn't
there before.  I've moved the path fixing to within the comparison code,
and I no longer see the problem with or without the proposed patch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=712784&aid=1760613&group_id=128809