I ran this bug by the developer who added the code which your proposed patch affects for bug 1848607 - Strict EmbeddedObject types. Here is his response:
=======================
Let's see the response:
[indication.response snipped]
First of all it is interesting that the <VALUE> element doesn't have a </VALUE> closing pair....
2nd, see a comment below from the Strict EmbeddedObject types patch:
/*
* In case of strict parsing Object means CIMClass, Instance means CIMInstance.
* Pegasus 2.7.0 seems to handle it this way.
*/
So it is the intended behaviour to throw an Exception for this input. It is not a bug. Changing the sblim.wbem.cimxmlParser.strictEmbObjTypes into false should change this as you mentioned.
3rd point that this EmbeddedObject and EmbeddedInstance stuff is not exactly defined. I always tried to align the implementation to the latest available Pegasus. It would be good to clarify with the Pegasus team, that what means what in this area and both side should keep the agreement.
It sometimes happend during my testes that CIM client was able to parse an Embedded Object sent by Pegasus, but Pegasus replied with an error message for the same style of Embedded Object.
=======================
Comments? Suggestions?
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In response to the second point of the previous comment, where it says
/*
* In case of strict parsing Object means CIMClass, Instance means
CIMInstance.
* Pegasus 2.7.0 seems to handle it this way.
*/
Lifecycle indications are modelled in the CIM Schema using the CIM_InstIndication class. And this class always contains the source instance of an indication as a property of type EmbeddedObject, rather than as EmbeddedInstance. So for indications the "embedded instances" are always represented as objects.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The attached patch concerns me a bit because it allows all elements that are embedded objects to have values which are either a class or instance, and that seems to go against the idea of strict parsing as mentioned in the comment - "Object means CIMClass, Instance means CIMInstance." Now Robert mentions that this logic doesn't hold true for indications, so can't we just add a special check for indications only or is that not possible/feasible?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Where, except for the comment in the source code, is stated that "Object means CIMClass"?
Here is an excerpt from the CIMXML Operations over HTTP specification:
3.1.11 EmbeddedObject
...
If the qualifier EMBEDDEDOBJECT is defined for the method, parameter, or property, the EmbeddedObject attribute MUST BE attached to the corresponding property in any instance, PARAMVALUE, or RETURNVALUE with the value "object".
3.2.5.4. PROPERTY
...
1. A property that is defined in MOF as an embeddedObject with the inclusion of the EmbeddedObject qualifier on the property MUST be defined using the type "object". The value MUST be a valid INSTANCE element, defining a single CIM Instance of a CIM Class or a valid CLASS element.
Therefore I do not agree that this is a special case for indications.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's just that this patch seems to go against what was done for bug 1848607 - Strict EmbeddedObject types:
"Pegasus2.7.0 accepts only Class value as EmbeddedObject. Previously at jsr48-client side it was assumed that EmbeddedObjects can be both Instances and Classes. Due to it the client doesn't change the type of valueless EmbeddedObject CIMElements (the string type is kept).
If EmbeddedObject always means Class for the CIMOM, mapping the type of valueless EmbeddedObject CIMElements is trivial."
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After discussing things over with a former Pegasus developer, I think we reached a reasonable conclusion with regard to this issue.
Here are a couple quotes from the developer:
1) "So, I guess your question is what to do about strict parsing in the CIM Client? It seems to me like it should be removed, and if that causes a problem with earlier versions of Pegasus, then a bug should be written against Pegasus for that."
2) "By valueless embedded objects, do you mean those with a NULL string? I'm not sure why you would ever see one of those -- it seems they should be invalid. Is there an application for that? ie. a case where null embedded objects are valid?"
Not sure what the answer is to that last question, but the developer who added strict parsing to the CIM Client encountered while testing the interoperability between the client and Pegasus. However, because strict parsing is there to make an assumption when a valueless embedded object is encountered, it should not be applied to embedded objects with values.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Patch sent for community review. During a 2 week period any exploiter may comment on the patch, request changes or turn it down completely (with good reason). For the time being the patch is part of the "Experimental" branch in CVS.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The community review is completed and we received no substantial critisism. Therefore the patch has been approved and merged into the "HEAD" branch. The next release will pick it up.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OpenPegasus indication.
Possible solution.
Logged In: YES
user_id=1617521
Originator: YES
File Added: JSR48NoIndication.patch
Logged In: YES
user_id=1215427
Originator: NO
Have you set either of these two config properties to something other than their default?
#sblim.wbem.cimxmlEmbObjBuilder=AttribOnly
#sblim.wbem.cimxmlParser.strictEmbObjTypes=true
Logged In: YES
user_id=1617521
Originator: YES
No. I do not change the properties file at all.
Logged In: YES
user_id=1215427
Originator: NO
Hello -
I ran this bug by the developer who added the code which your proposed patch affects for bug 1848607 - Strict EmbeddedObject types. Here is his response:
=======================
Let's see the response:
[indication.response snipped]
First of all it is interesting that the <VALUE> element doesn't have a </VALUE> closing pair....
2nd, see a comment below from the Strict EmbeddedObject types patch:
/*
* In case of strict parsing Object means CIMClass, Instance means CIMInstance.
* Pegasus 2.7.0 seems to handle it this way.
*/
So it is the intended behaviour to throw an Exception for this input. It is not a bug. Changing the sblim.wbem.cimxmlParser.strictEmbObjTypes into false should change this as you mentioned.
3rd point that this EmbeddedObject and EmbeddedInstance stuff is not exactly defined. I always tried to align the implementation to the latest available Pegasus. It would be good to clarify with the Pegasus team, that what means what in this area and both side should keep the agreement.
It sometimes happend during my testes that CIM client was able to parse an Embedded Object sent by Pegasus, but Pegasus replied with an error message for the same style of Embedded Object.
=======================
Comments? Suggestions?
Thanks
Logged In: YES
user_id=1215482
Originator: NO
In response to the second point of the previous comment, where it says
/*
* In case of strict parsing Object means CIMClass, Instance means
CIMInstance.
* Pegasus 2.7.0 seems to handle it this way.
*/
Lifecycle indications are modelled in the CIM Schema using the CIM_InstIndication class. And this class always contains the source instance of an indication as a property of type EmbeddedObject, rather than as EmbeddedInstance. So for indications the "embedded instances" are always represented as objects.
Logged In: YES
user_id=1215427
Originator: NO
The attached patch concerns me a bit because it allows all elements that are embedded objects to have values which are either a class or instance, and that seems to go against the idea of strict parsing as mentioned in the comment - "Object means CIMClass, Instance means CIMInstance." Now Robert mentions that this logic doesn't hold true for indications, so can't we just add a special check for indications only or is that not possible/feasible?
Logged In: YES
user_id=1215482
Originator: NO
Where, except for the comment in the source code, is stated that "Object means CIMClass"?
Here is an excerpt from the CIMXML Operations over HTTP specification:
3.1.11 EmbeddedObject
...
If the qualifier EMBEDDEDOBJECT is defined for the method, parameter, or property, the EmbeddedObject attribute MUST BE attached to the corresponding property in any instance, PARAMVALUE, or RETURNVALUE with the value "object".
3.2.5.4. PROPERTY
...
1. A property that is defined in MOF as an embeddedObject with the inclusion of the EmbeddedObject qualifier on the property MUST be defined using the type "object". The value MUST be a valid INSTANCE element, defining a single CIM Instance of a CIM Class or a valid CLASS element.
Therefore I do not agree that this is a special case for indications.
Logged In: YES
user_id=1215427
Originator: NO
It's just that this patch seems to go against what was done for bug 1848607 - Strict EmbeddedObject types:
"Pegasus2.7.0 accepts only Class value as EmbeddedObject. Previously at jsr48-client side it was assumed that EmbeddedObjects can be both Instances and Classes. Due to it the client doesn't change the type of valueless EmbeddedObject CIMElements (the string type is kept).
If EmbeddedObject always means Class for the CIMOM, mapping the type of valueless EmbeddedObject CIMElements is trivial."
Logged In: YES
user_id=1215427
Originator: NO
After discussing things over with a former Pegasus developer, I think we reached a reasonable conclusion with regard to this issue.
Here are a couple quotes from the developer:
1) "So, I guess your question is what to do about strict parsing in the CIM Client? It seems to me like it should be removed, and if that causes a problem with earlier versions of Pegasus, then a bug should be written against Pegasus for that."
2) "By valueless embedded objects, do you mean those with a NULL string? I'm not sure why you would ever see one of those -- it seems they should be invalid. Is there an application for that? ie. a case where null embedded objects are valid?"
Not sure what the answer is to that last question, but the developer who added strict parsing to the CIM Client encountered while testing the interoperability between the client and Pegasus. However, because strict parsing is there to make an assumption when a valueless embedded object is encountered, it should not be applied to embedded objects with values.
Patch against 2.0.5
Logged In: YES
user_id=1215427
Originator: NO
File Added: 1944875-patch.txt
Logged In: YES
user_id=1215427
Originator: NO
Patch sent for community review. During a 2 week period any exploiter may comment on the patch, request changes or turn it down completely (with good reason). For the time being the patch is part of the "Experimental" branch in CVS.
Logged In: YES
user_id=1215427
Originator: NO
The community review is completed and we received no substantial critisism. Therefore the patch has been approved and merged into the "HEAD" branch. The next release will pick it up.
Logged In: YES
user_id=1215427
Originator: NO
The patch was picked up by release 2.0.6 and will be closed.