[jira] Commented: (TUSCANY-1949) import.sdo element is not resolved if it follows a property element
[ https://issues.apache.org/jira/browse/TUSCANY-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12568066#action_12568066 ] Simon Laws commented on TUSCANY-1949: - There looks like there is a fix required here to property processing. Having said that do we need to support import.sdo at all now? In the case of interfaces with static SDO typed parameters the runtime will scan contributions looking for SDO factories. In the case of dynamic SDO typed parameters it's a little more tricky as the runtime doesn't know what to look for. Could we rely on an init method on a service implementation to provide the mapping programatically rather than having a Tuscany specific extension of the assembly model . import.sdo element is not resolved if it follows a property element --- Key: TUSCANY-1949 URL: https://issues.apache.org/jira/browse/TUSCANY-1949 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-1.0 Reporter: Greg Dritschler Priority: Minor Fix For: Java-SCA-Next I have an SCA composite that uses both a property element and an import.sdo element. If the property element appears before the import.sdo element as shown below, then the application fails during execution when it tries to create an SDO. composite ... component ... property name=p type=xsd:stringXYZZY/property /component dbsdo:import.sdo .../ /composite If I reorder the elements as shown below then the application works. composite ... dbsdo:import.sdo .../ component ... property name=p type=xsd:stringXYZZY/property /component /composite I found the problem in CompositeProcessor. When a property element is found, it calls a method readPropertyValue. This method consumes the property end element so CompositeProcessor won't see it. Since CompositeProcessor does not see the property end element, it does not clear the property method variable. Then when it processes the import.sdo element, it sees the property variable is non-null and mistakenly associates the import.sdo extension with the property instead of with the composite. I was able to work around the problem by clearing the property variable after the readPropertyValue call as shown below. (There are actually two such calls, one for component level and one for composite level, and I cleared it in both cases.) // Read the property value Document value = readPropertyValue(property.getXSDElement(), property.getXSDType(), reader); property.setValue(value); composite.getProperties().add(property); property = null; // **WORKAROUND** -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1949) import.sdo element is not resolved if it follows a property element
[
https://issues.apache.org/jira/browse/TUSCANY-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12555995#action_12555995
]
Greg Dritschler commented on TUSCANY-1949:
--
Can property elements have extension elements? If not maybe the correct
solution is to remove the code that tries to associate extensions with
properties?
// Add the extension element to the current
// element
if (callback != null) {
callback.getExtensions().add(extension);
} else if (contract != null) {
contract.getExtensions().add(extension);
} else if (property != null) {
property.getExtensions().add(extension);
} else if (component != null) {
component.getExtensions().add(extension);
} else {
composite.getExtensions().add(extension);
}
import.sdo element is not resolved if it follows a property element
---
Key: TUSCANY-1949
URL: https://issues.apache.org/jira/browse/TUSCANY-1949
Project: Tuscany
Issue Type: Bug
Components: Java SCA Assembly Model
Affects Versions: Java-SCA-1.0
Reporter: Greg Dritschler
Priority: Minor
I have an SCA composite that uses both a property element and an import.sdo
element. If the property element appears before the import.sdo element as
shown below, then the application fails during execution when it tries to
create an SDO.
composite ...
component ...
property name=p type=xsd:stringXYZZY/property
/component
dbsdo:import.sdo .../
/composite
If I reorder the elements as shown below then the application works.
composite ...
dbsdo:import.sdo .../
component ...
property name=p type=xsd:stringXYZZY/property
/component
/composite
I found the problem in CompositeProcessor. When a property element is found,
it calls a method readPropertyValue. This method consumes the property end
element so CompositeProcessor won't see it. Since CompositeProcessor does
not see the property end element, it does not clear the property method
variable. Then when it processes the import.sdo element, it sees the
property variable is non-null and mistakenly associates the import.sdo
extension with the property instead of with the composite.
I was able to work around the problem by clearing the property variable after
the readPropertyValue call as shown below. (There are actually two such
calls, one for component level and one for composite level, and I cleared it
in both cases.)
// Read the property value
Document value =
readPropertyValue(property.getXSDElement(), property.getXSDType(), reader);
property.setValue(value);
composite.getProperties().add(property);
property = null; // **WORKAROUND**
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
