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
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: sca-j@lists.oasis-open.org
- Date: Mon, 23 Nov 2009 12:39:40 +0000
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: 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]