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>
/
________________________________________________________________/
