Folks,
Comments inline...
Raymond Feng wrote:
Hi,
I ran into two problems related to SCA property validation.
Assuming we have the following:
a) The java component impl class
public class MyServiceImpl {
...
@Property
private String p1;
...}
By intropsection, we will have "p1" as a property (xsd:string).
b) The component definition
<component name="MyComponent">
<implementation.java class="test.MyServiceImpl"/>
<property name="p1" value="xyz"/>
</component>
This will be reported by Tuscany as an error in two places:
1) We check if the property element has either @type or @element. (From
the SCA assembly spec, if there is no type, it should use the one from
the componentType property. My understanding is that we can have none of
the attrs.)
Are you saying that the current code does not work if the property type is not specified on the
component <property/> ? I have a lot of composites in the OASIS test suites that don't have the
property type specified on the component <property/> element, and they seem to work OK.
Now if I change the property to be a JAXB complex type:
public class MyServiceImpl {
...
@Property
private Customer p1;
...}
<component name="MyComponent">
<implementation.java class="test.MyServiceImpl"/>
<property name="p1" type="customer:Customer"/ xmlns:customer="...">
</component>
2) We also try to find an XSD definition that matches the
customer:Customer type but I actually have that from the JAXB
annotations. This validation seems to be too much and we should be able
to just check the type compatibility by the QName.
Umm, let me see what you're saying here.
The user writes a composite that contains an explicit type and that type is from some XSD namespace
that the user knows about (certainly not the SCA namespace anyway), as shown in your example above.
You are saying that you DON'T want to validate that explicit type declaration - ie you don't want to
find the XSD definition to which it refers? Why not?
By stating the type explicitly, the user is saying, "this property is expected to be of that type".
Without resolving "that type" at the XML level, how is it possible to check that the type in the
componentType of the implementation actually matches? If they don't match, it is clearly an error.
If we agree, I can relax the code to fix these issues.
"relax the code" to remove some expected type checking does not sound right to
me.
Thanks,
Raymond
/________________________________________________________________
Raymond Feng
[email protected] <mailto:[email protected]>
/Apache Tuscany PMC member and committer: tuscany.apache.org
Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
Personal Web Site: www.enjoyjava.com
/
________________________________________________________________/
