You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Raymond Feng <en...@gmail.com> on 2010/06/24 20:55:33 UTC
Tuscany SCA property validation related issues
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.)
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.
If we agree, I can relax the code to fix these issues.
Thanks,
Raymond
________________________________________________________________
Raymond Feng
rfeng@apache.org
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
________________________________________________________________
Re: Tuscany SCA property validation related issues
Posted by ant elder <an...@gmail.com>.
On Thu, Jun 24, 2010 at 7:55 PM, Raymond Feng <en...@gmail.com> 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.)
> 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.
> If we agree, I can relax the code to fix these issues.
Sounds ok to me.
...ant
Re: Tuscany SCA property validation related issues
Posted by Simon Laws <si...@googlemail.com>.
Hi Raymond
Comments/questions in-line
On Thu, Jun 24, 2010 at 7:55 PM, Raymond Feng <en...@gmail.com> 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.)
You mean that Tuscany doesn't support the @type or @element annotations?
> 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.
Which JAXB annotations in this case?
This validation
> seems to be too much and we should be able to just check the type
> compatibility by the QName.
Won't we still want to validate that what the user has typed into the
composite file matches the expected type? I feel like I'm missing what
you mean by "this validation" in this case.
> If we agree, I can relax the code to fix these issues.
> Thanks,
> Raymond
> ________________________________________________________________
> Raymond Feng
> rfeng@apache.org
> 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
> ________________________________________________________________
>
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Tuscany SCA property validation related issues
Posted by Simon Nash <na...@apache.org>.
See comments inline.
Simon
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.)
>
Tuscany should allow both the type and element attributes to be
omitted, in which case the property value in the component definition
should be checked for validity against the property type in the
implementation's componentType. For example, a componentType
property type of xsd:int with a component definition value of "xyz"
should produce a validation error.
> 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.
>
In this case there will be no xsd file physically in the contribution
because the schema type is implied by the JAXB Java-to-XSD mapping of
the Java type definition for Customer. The property type QName should be
checked to make sure it matches a mapped schema type, and the property
value should be validated against this mapped schema type.
Simon
> If we agree, I can relax the code to fix these issues.
>
> Thanks,
> Raymond
> /________________________________________________________________
> Raymond Feng
> rfeng@apache.org <ma...@apache.org>
> /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
> /
> ________________________________________________________________/
>
Re: Tuscany SCA property validation related issues
Posted by Simon Laws <si...@googlemail.com>.
On Mon, Jun 28, 2010 at 10:08 PM, Raymond Feng <en...@gmail.com> wrote:
> Hi,
> It turns out to be two questions:
> 1) When the SCA composite references user-defined (not in the SCA or tuscany
> namespace) XSD types or elements, do we need to enable schema validation?
> 2) If yes, how does Tuscany find the corresponding XSDs from the SCA
> contributions and use them together with SCA/Tuscany XSDs to validate the
> composite XML document?
> We should try to bring up itest/properties again. It should be able to cover
> the scenarios I'm talking about.
+1
> Thanks,
> Raymond
> ________________________________________________________________
> Raymond Feng
> rfeng@apache.org
> 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 28, 2010, at 2:36 AM, Simon Laws wrote:
>
Simon
Re: Tuscany SCA property validation related issues
Posted by Raymond Feng <en...@gmail.com>.
Hi,
It turns out to be two questions:
1) When the SCA composite references user-defined (not in the SCA or tuscany namespace) XSD types or elements, do we need to enable schema validation?
2) If yes, how does Tuscany find the corresponding XSDs from the SCA contributions and use them together with SCA/Tuscany XSDs to validate the composite XML document?
We should try to bring up itest/properties again. It should be able to cover the scenarios I'm talking about.
Thanks,
Raymond
________________________________________________________________
Raymond Feng
rfeng@apache.org
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 28, 2010, at 2:36 AM, Simon Laws wrote:
> On Sat, Jun 26, 2010 at 2:29 PM, Simon Nash <na...@apache.org> wrote:
>> See comments inline.
>>
>> Simon
>>
>> Raymond Feng wrote:
>>>
>>> Please see my comments inline.
>>>
>>> Thanks,
>>> Raymond
>>> /________________________________________________________________ Raymond
>>> Feng
>>> rfeng@apache.org <ma...@apache.org>
>>> /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.
>>
>>>
>> Without this, how would an error in the component definition's property
>> value be detected? Would it be detected at runtime when the property
>> is injected? If so, I'm not sure why it is significantly more work to
>> run the code that does this check when the composite is started.
>>
>>> 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).
>>
>>>
>> It would be simpler for the Tuscany runtime implementation, but more
>> difficult and error-prone for the user. This doesn't seem like the
>> right trade-off.
>>
>>> 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.
>>
>> Instead of this, how about adding a "validate" phase that runs after
>> all artifacts from all contributions have been loaded? Any artifacts
>> that need to do validation can run their validation code in this phase.
>> The validation code for components would be able to do XSD checking using
>> XSDs that have already been loaded.
>>
>> Simon
>>>
>>>
>>>>
>>>>> Thanks,
>>>>> Raymond
>>>>> /________________________________________________________________
>>>>> Raymond Feng
>>>>> rfeng@apache.org <ma...@apache.org> <ma...@apache.org>
>>>>> /Apache Tuscany PMC member and committer: tuscany.apache.org
>>>>> <http://tuscany.apache.org>
>>>>> Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
>>>>> <http://www.tuscanyinaction.com>
>>>>> Personal Web Site: www.enjoyjava.com <http://www.enjoyjava.com>
>>>>> /
>>>>> ________________________________________________________________/
>>>>
>>>
>>
>>
>
> Hi Raymond
>
> I'm still not getting precisely what the issue is here. I was under
> the impression that we already scanned for XSD in a contribution and
> indexed against namespace but clearly this doesn't work properly of
> not properly enough for your scenario. Are there test cases that you
> can point at that demonstrate the problem(s)?
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Tuscany SCA property validation related issues
Posted by Simon Laws <si...@googlemail.com>.
On Sat, Jun 26, 2010 at 2:29 PM, Simon Nash <na...@apache.org> wrote:
> See comments inline.
>
> Simon
>
> Raymond Feng wrote:
>>
>> Please see my comments inline.
>>
>> Thanks,
>> Raymond
>> /________________________________________________________________ Raymond
>> Feng
>> rfeng@apache.org <ma...@apache.org>
>> /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.
>
>>
> Without this, how would an error in the component definition's property
> value be detected? Would it be detected at runtime when the property
> is injected? If so, I'm not sure why it is significantly more work to
> run the code that does this check when the composite is started.
>
>> 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).
>
>>
> It would be simpler for the Tuscany runtime implementation, but more
> difficult and error-prone for the user. This doesn't seem like the
> right trade-off.
>
>> 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.
>
> Instead of this, how about adding a "validate" phase that runs after
> all artifacts from all contributions have been loaded? Any artifacts
> that need to do validation can run their validation code in this phase.
> The validation code for components would be able to do XSD checking using
> XSDs that have already been loaded.
>
> Simon
>>
>>
>>>
>>>> Thanks,
>>>> Raymond
>>>> /________________________________________________________________
>>>> Raymond Feng
>>>> rfeng@apache.org <ma...@apache.org> <ma...@apache.org>
>>>> /Apache Tuscany PMC member and committer: tuscany.apache.org
>>>> <http://tuscany.apache.org>
>>>> Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
>>>> <http://www.tuscanyinaction.com>
>>>> Personal Web Site: www.enjoyjava.com <http://www.enjoyjava.com>
>>>> /
>>>> ________________________________________________________________/
>>>
>>
>
>
Hi Raymond
I'm still not getting precisely what the issue is here. I was under
the impression that we already scanned for XSD in a contribution and
indexed against namespace but clearly this doesn't work properly of
not properly enough for your scenario. Are there test cases that you
can point at that demonstrate the problem(s)?
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Tuscany SCA property validation related issues
Posted by Simon Nash <na...@apache.org>.
See comments inline.
Simon
Raymond Feng wrote:
> Please see my comments inline.
>
> Thanks,
> Raymond
> /________________________________________________________________
> Raymond Feng
> rfeng@apache.org <ma...@apache.org>
> /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.
>
Without this, how would an error in the component definition's property
value be detected? Would it be detected at runtime when the property
is injected? If so, I'm not sure why it is significantly more work to
run the code that does this check when the composite is started.
> 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).
>
It would be simpler for the Tuscany runtime implementation, but more
difficult and error-prone for the user. This doesn't seem like the
right trade-off.
> 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.
>
Instead of this, how about adding a "validate" phase that runs after
all artifacts from all contributions have been loaded? Any artifacts
that need to do validation can run their validation code in this phase.
The validation code for components would be able to do XSD checking using
XSDs that have already been loaded.
Simon
>
>
>>
>>> Thanks,
>>> Raymond
>>> /________________________________________________________________
>>> Raymond Feng
>>> rfeng@apache.org <ma...@apache.org> <ma...@apache.org>
>>> /Apache Tuscany PMC member and committer: tuscany.apache.org
>>> <http://tuscany.apache.org>
>>> Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
>>> <http://www.tuscanyinaction.com>
>>> Personal Web Site: www.enjoyjava.com <http://www.enjoyjava.com>
>>> /
>>> ________________________________________________________________/
>>
>
Re: Tuscany SCA property validation related issues
Posted by Raymond Feng <en...@gmail.com>.
Please see my comments inline.
Thanks,
Raymond
________________________________________________________________
Raymond Feng
rfeng@apache.org
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
>> rfeng@apache.org <ma...@apache.org>
>> /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
>> /
>> ________________________________________________________________/
>
Re: Tuscany SCA property validation related issues
Posted by Mike Edwards <mi...@gmail.com>.
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
> rfeng@apache.org <ma...@apache.org>
> /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
> /
> ________________________________________________________________/
>