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

Dave,

Thanks for doing this.

Comments:

2.1.5 talks about "valid JAXB annotated
class" and so avoids saying anything about:

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.

I am not sure I understand the logic
of forcing the XML schema to Java mapping to be the default one.

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?

The MUST NOT requirement is really a
case in which the componentType of the implementation does 

not match the configuration of the component using the implementation.

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 am of the opinion that the material
that is in 2.1.5 should be in section 10.20 on "@Property"

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:  

From:
David Booz <>

To:


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:[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