[
https://issues.apache.org/jira/browse/TUSCANY-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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:string">XYZZY</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:string">XYZZY</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]
