OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-j message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [sca-j] ISSUE-168: Conversion rules for property values are notspecified - proposal



Dave,

Thanks for doing this.

Comments:

a) primitive types
b) types that are unannotated classes

I suggest that the wording needs to be generalized to cover all of these.  I think that what is needed is
to say that any field/setter/constructor parameter annotated with @Property has its type mapped from its
Java type to an XML type, using the JAXB 2.1 rules. This encompasses "valid JAXB annotated" classes
but also all the other unannotated and primitive cases.

So, if the class(es) contain JAXB annotations and the XSD contains <jaxb:xxx> extensions that imply something
outside the default mapping, what do we do?  Throw an exception?

I note that the requirement for the type of the <component> <property> to match the type of the equivalent
<componentType> <property> is a normative requirement of the SCA Assembly spec:

ASM50036:

The property type specified for the property element of a component MUST be compatible with the type of the property
with the same @name declared in the component type of the implementation used by the component.  If no type is
declared in the component property element, the type of the property declared in the componentType of the implementation
MUST be used.


So, is there a need for this new normative statement in the Java CAA spec?


I also note that for specific implementation types like POJO, it is possible to have properties in the componentType which
derive from Java fields/setters which are NOT annotated with @Property - however, it is the responsibility of the specs for
those impl types to define the type mapping for such properties

Suggested wording (addesses

"The @Property annotation is used to denote a Java class field, a setter method, or a constructor parameter that is used
to inject an SCA property value. The type of the property injected, which can be a simple Java type or a complex Java type,
is defined by the type of the Java class field or the type of the input parameter of the setter method or constructor.
The SCA runtime MUST map the Java type of a field, setter method or constructor parameter annotated with @Property
to an XSD type in the componentType, according to the mapping defined in the JAXB 2.1 specification [JAXB-21]
a property value specified [JCAxxxxx]. When the SCA runtime injects a property value,  it MUST perform the conversion
of the XML defined property value to a Java value using the mapping defined by the JAXB 2.1 specification [JAXB-21]
with XML schema validation enabled. [JCAxxxxx]"


This addresses a couple of the points above...


Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
Email:  mike_edwards@uk.ibm.com



From: David Booz <booz@us.ibm.com>
To: sca-j@lists.oasis-open.org
Date: 16/11/2009 22:27
Subject: [sca-j] ISSUE-168: Conversion rules for property values are not specified - proposal





Hi folks,

This should give you something to think about. Attached is a proposed resolution for Issue 168 [1]. As far as I can tell, there are two important points for us to consider.

When converting an XML property value to a JAXB annotated type:
(a) JAXB allows for validation of the XML to be on or off. My proposal says validation must be on. Remember we're talking about property values here, not messages between components.
(b) JAXB allows for custom bindings of XML schema to Java. My proposal says that the runtime must use the default schema to Java binding.

See sections 2.1.5 and 4.2.2. I'm not opposed to moving the 2.1.5 text to the @Property annotation section.

(See attached file: sca-javacaa-1.1-spec-cd03-rev1+Issue168.doc)


[1]
http://www.osoa.org/jira/browse/JAVA-168

Dave Booz
STSM, BPM and SCA Architecture
Co-Chair OASIS SCA-Policy TC and SCA-J TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:booz@us.ibm.com
[attachment "sca-javacaa-1.1-spec-cd03-rev1+Issue168.doc" deleted by Mike Edwards/UK/IBM] ---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php







Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU








[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]