Please see my comments inline.
Thanks,
Raymond
________________________________________________________________
Raymond Feng
[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
________________________________________________________________
On Jun 25, 2010, at 3:44 AM, Mike Edwards wrote:
> 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.
I looked into more details. The root problem in my case is that the current
code doesn't set the XSD type for the componentType property if it's a complex
type during introspection. As a result, the component property gets a null
type. I'm adding a fix for that.
>
>> 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.
I buy some of your points. There are a few cases:
1) The contributions doesn't contain the user XSD files needed for validation.
For example, we have JAXB annotated classes.
2) The contributions do contain the user XSDS.
For case 1, I'm not sure if we really want to do Java2XSD to reverse engineer
the XSDs for validation.
For case 2, Tuscany might have to do some serious changes:
a) Before the schema validation happens, we need to know all the XSDs in SCA
contributions 1st following the import/export. (A simpler way is to require
users to add xsi:schemaLocation into the composite file).
b) Today we load the artifacts within the contribution one by one. Before all
of the contributions are processed, we don't have the complete knowledge of all
XSDs.
c) We might to have to introduce a "describe" phase as the1st stage of the
contribution processing in order to find XSDs by the namespace:
* Get a list of artifacts for a contribution (ContributionScanner)
* Describe the artifacts of interest. For example, for an XSD artifact,
we'll figure out the TNS of the schema. For a composite or BPEL process, we'll
identify the QName.
* Start with the deployable composites, we'll find the referenced artifacts
with the knowledge we have from the "describe" phase. We'll load the artifact
if it's not fully loaded.
>
>> 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
>> /
>> ________________________________________________________________/
>
