On Sat, Jun 26, 2010 at 2:29 PM, Simon Nash <[email protected]> wrote: > See comments inline. > > Simon > > Raymond Feng wrote: >> >> Please see my comments inline. >> >> 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 >> / >> ________________________________________________________________/ >> >> 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 >>>> [email protected] <mailto:[email protected]> <mailto:[email protected]> >>>> /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
