| OK, that goal (a generic way to assert typing) sounds different than what the issue states (type support for SDO). I agree the problem space of the former is a lot larger and I wonder whether the SCA-J spec should try and tackle it as opposed to delegating to individual databindings.
There may be some advantages to a generic approach over using databinding-specific mechanisms but is it worth it? I don't think it is likely for generic typing metadata to enable databinding portability. Also, a good argument could be made that people would prefer to use the typing metadata associated with the databinding technology in use. For example, JAXB (and JAXB annotations) is more prevalent than SCA since it is in the JDK and people will be familiar with its set of annotations.
I may be missing something but it appears that the issue is with SDO (or any other databinding technology that does not support type assertions) and not really with SCA-J. Having SDO solve the problem would also make it more useful in contexts outside of SCA where the issue is likely to exist as well.
Jim
On Sep 16, 2009, at 1:30 PM, David Booz wrote: yes - and that TC has been incredibly resistant to the idea of any annotations. In fairness though, the whole of the problem space is a bit larger than SDO. There seems to be utility (IMHO) to having a databinding agnostic means for asserting type metadata. An SDO annotation would obviously be limited to SDO databindings.
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
<graycol.gif>Jim Marino ---09/16/2009 06:05:15 AM---Hi Dave, Has it been suggested to have SDO define an annotation or set of
<ecblank.gif>
From: | <ecblank.gif>
Jim Marino <jim.marino@gmail.com> | <ecblank.gif>
To: | <ecblank.gif>
OASIS Java <sca-j@lists.oasis-open.org> | <ecblank.gif>
Date: | <ecblank.gif>
09/16/2009 06:05 AM | <ecblank.gif>
Subject: | <ecblank.gif>
Re: [sca-j] ISSUE-179: Need type support for @Property when used with SDO |
Hi Dave, Has it been suggested to have SDO define an annotation or set of annotations to similar to JAXB instead of defining a generic SCA facility? Jim On Sep 15, 2009, at 7:06 PM, David Booz wrote: Comments below <dab> like this </dab>
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
<graycol.gif>Raymond Feng---09/14/2009 08:46:27 PM---Hi, Thanks for the clarification.
<ecblank.gif>
From: | <ecblank.gif>
Raymond Feng/Burlingame/IBM@IBMUS | <ecblank.gif>
To: | <ecblank.gif>
sca-j@lists.oasis-open.org | <ecblank.gif>
Date: | <ecblank.gif>
09/14/2009 08:46 PM | <ecblank.gif>
Subject: | <ecblank.gif>
Re: [sca-j] ISSUE-179: Need type support for @Property when used with SDO |
Hi,
Thanks for the clarification.
To determine the XML type behind a Java property, the following cases seem to be a natural order.
1) The property's Java type itself is self-described to the underlying databinding technology, for example, a generated static JAXB class or SDO class.
<dab> yes </dab>
2) The property is annotated in a databinding-specific mechanism, for example, using JAXB annotations such as XmlSchemaType or XmlJavaTypeAdapter. This can happen if the Java type is not a generated JAXB class, such as Object or an interface. <dab> yes </dab>
3) The property is annotated using SCA-defined annotations. The proposal will provide a solution if both 1 and 2 are not possible. (Some of the JAXB annotations are designed for similar purposes, but I'm not sure we should force SCA developers to use JAXB annotations for other databindings). <dab> exactly </dab>
4) No XML type is provided, the java type is mapped to xsd:anyType or not supported <dab> right </dab>
Does this proposal only apply to properties or do we want to generalize it for operation signatures (parameters and return types)? If it is for properties only, I would prefer to enhance @Property. Otherwise it makes sense to introduce something like @XMLType.
<dab> This is the first pro I mentioned below. It's important to observe that a similar Java to XML mapping problem occurs when trying to map Java methods (params and results) to WSDL. With the separate annotation approach (@XMLType as below), this problem could be solved (by allowing the annotation on method params and results). That leaves us with one databinding annotation for all situations. That's not a bad place to be. I've been in worse places.... </dab>
Thanks,
Raymond
Raymond Feng
Senior Software Engineer, Apache Tuscany PMC Member & Committer
IBM Bay Area Lab, 1001 E Hillsdale Blvd, Suite 400, Foster City, CA 94404, USA
E-mail: rfeng@us.ibm.com, Notes: Raymond Feng/Burlingame/IBM, Tel: 650-645-8117, T/L: 367-8117
Apache Tuscany: http://tuscany.apache.org
David Booz/Poughkeepsie/IBM@IBMUS wrote on 09/14/2009 11:56:23 AM:
> From:
>
> David Booz/Poughkeepsie/IBM@IBMUS
>
> To:
>
> sca-j@lists.oasis-open.org
>
> Date:
>
> 09/14/2009 11:57 AM
>
> Subject:
>
> Re: [sca-j] ISSUE-179: Need type support for @Property when used with SDO
>
> Raymond, since you missed the telecon today, I thought I'd update
> you on potential compromise proposal that we discussed. Simon N will
> correct me if I get anything wrong as we invented this on the fly.
>
> The current compromise proposal is to introduce a new SCA annotation
> (I'm proposing @XMLType below, but I don't really care about the
> name) to capture the schema (or element) typing info instead of
> capturing it on the property annotation itself.
>
> So, an example might look like this:
>
> package example;
>
> import org.oasis.annotation.Property;
> import org.osoa.sca.annotations.Service;
> import commonj.sdo.DataObject;
>
> @Service
> public class TypedComponentImpl {
>
> private static final String TYPE_PREFIX = "{http://example}";
> private static final String ELEMENT_NAME = TYPE_PREFIX + "thing";
> private static final String TYPE_NAME = TYPE_PREFIX + "AThingType";
>
> @Property
> @XMLType(type=TYPE_NAME)
> public DataObject dataObj1;
>
> ...
> }
>
> There are some advantages:
> 1) We could use it on parameters and return values. I need to
> explore this further. It's not something we discussed today on the call.
> 2) It is easy to say: "The @XMLType annotation MUST NOT be present
> when the @XmlJavaTypeAdapter annotation (or any other JAXB
> annotation that assert a schema type) is present.". The @Property
> approach I had earlier suffers from the problem that we will have to
> construct some complex rules in the spec to ensure that the
> @Property annotation with the new attributes specified doesn't
> collide with the presence of JAXB annotations. This new approach
> (@XMLType) doesn't have that problem because we can simply disallow both.
> 3) It's more modular - ok, this is a weak argument, because now an
> SDO programmer has to use two annotations and a JAXB guy probably
> only has to use one.
>
> Thoughts?
>
> FWIW, I still prefer my original proposal, but I'm trying to keep anopen mind.
>
>
> 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
>
> [image removed] Raymond Feng---09/14/2009 01:21:13 PM---Hi, I have a
> few comments/questions here.
>
> [image removed]
> From:
>
> [image removed]
> Raymond Feng/Burlingame/IBM
>
> [image removed]
> To:
>
> [image removed]
> Simon Nash <oasis@cjnash.com>
>
> [image removed]
> Cc:
>
> [image removed]
> David Booz/Poughkeepsie/IBM@IBMUS, sca-j@lists.oasis-open.org
>
> [image removed]
> Date:
>
> [image removed]
> 09/14/2009 01:21 PM
>
> [image removed]
> Subject:
>
> [image removed]
> Re: [sca-j] ISSUE-179: Need type support for @Property when used with SDO
>
>
>
> Hi,
>
> I have a few comments/questions here.
>
> 1) JAXB is part of JDK since version 1.6. Does sca-j spec mandate JDK 6?
>
> 2) It seems to me that you propose to use JAXB as the canonical
> databinding. If SDO or other databindings (such as DOM) is used,
> then the application developer is responsible for mapping it to
> JAXB. If an application developer is required to generate JAXB
> classes, why SDO is chosen in the first place?
>
> 3) I like Dave's original proposal better as it allows us to
> configure/customize the Java types with XML information in a
> databinding-agnostic way, when such metadata cannot be acquired by
> introspection. The SCA runtime can then use that in the databinding-
> specific typing system (such as JAXBContext or SDO HelperContext).
>
> Initially I also thought of adopting JAXB annotations such as
> XmlSchemaType, XmlAttribute, XmlElement, XmlAnyElement,
> XmlAnyAttribute to supply the XSD type/element/attribute for java
> types. But it seemed to be a bit strange that we use one databinding
> (JAXB) to describe another databinding.
>
> Thanks,
> Raymond
> Raymond Feng
> Senior Software Engineer, Apache Tuscany PMC Member & Committer
> IBM Bay Area Lab, 1001 E Hillsdale Blvd, Suite 400, Foster City, CA 94404, USA
> E-mail: rfeng@us.ibm.com, Notes: Raymond Feng/Burlingame/IBM, Tel:
> 650-645-8117, T/L: 367-8117
> Apache Tuscany: http://tuscany.apache.org
>
>
> Simon Nash <oasis@cjnash.com> wrote on 09/14/2009 07:30:34 AM:
>
> > From:
> >
> > Simon Nash <oasis@cjnash.com>
> >
> > To:
> >
> > David Booz/Poughkeepsie/IBM@IBMUS
> >
> > Cc:
> >
> > sca-j@lists.oasis-open.org
> >
> > Date:
> >
> > 09/14/2009 07:31 AM
> >
> > Subject:
> >
> > Re: [sca-j] ISSUE-179: Need type support for @Property when used with SDO
> >
> > Dave,
> > Responses inline below.
> >
> > Simon
> >
> > David Booz wrote:
> > > Hi Simon,
> > >
> > > Thanks for the research. Don't you think it would be quite odd if the
> > > spec required the use of JAXB emitters (this is what I find the most
> > > troubling) in order to use SDO with a specific schema type?
> > >
> > JAXB is built built into the JDK, so I'm not sure why it is burdensone
> > to run the JAXB emitters. The emitted class could be placed in a
> > separate Java package that clearly identifies it as an emitted
> > JAXB artifact and doesn't interfere with any classes in Java packages
> > used by the implementation.
> >
> > > My argument
> > > remains the same. We need a way to simplify the use of SDO as a
> > > databinding technology, enabling the developers to work with the minimal
> > > number of building blocks. While I agree that the @XmlJavaTypeAdapter
> > > seems to "work", it doesn't meet the requirement as something that would
> > > be intuitive to use because it introduces extra concepts that the
> > > developer doesn't really need. The simple extension that I've proposed
> > > provides an easily understandable integration point because the
> > > developer only has to deal with the SDO API and XML schema.
> > >
> > Support for @XmlJavaTypeAdapter is already mandated in SCA-J, and JAXB
> > is a standard part of the JDK. It seems very strange to me to invent
> > a new facility that duplicates existing capabilities that are included
> > in SCA-J and the JDK. IMO this is more confusing for developers than
> > explaining how they can use existing capabilities to do what they need.
> >
> > > The @XmlAnyElement seems like a reasonable approach for the mapping of
> > > SDO to <any/>, so I can probably live with it for those use cases that
> > > require <any/>. Are there any other JAXB annotations that would have to
> > > appear in the Java class in order to make this work?
> > >
> > No other annotations are needed.
> >
> > Simon
> >
> > > 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
> > >
> > > Inactive hide details for Simon Nash ---09/05/2009 07:46:03 AM---On
> > > Friday's call I took an action to see whether JAXB annotatiSimon Nash
> > > ---09/05/2009 07:46:03 AM---On Friday's call I took an action to see
> > > whether JAXB annotations can be used to override the defaul
> > >
> > >
> > > From:
> > > Simon Nash <oasis@cjnash.com>
> > >
> > > To:
> > > sca-j@lists.oasis-open.org
> > >
> > > Date:
> > > 09/05/2009 07:46 AM
> > >
> > > Subject:
> > > Re: [sca-j] ISSUE-179: Need type support for @Property when used with SDO
> > >
> > > ------------------------------------------------------------------------
> > >
> > >
> > >
> > > On Friday's call I took an action to see whether JAXB annotations can be
> > > used to override the default JAXB mapping from a Java property type
> > > to a schema type.
> > >
> > > The answer is that this can be done with the @XmlJavaTypeAdapter
> annotation.
> > > If there is a property whose Java type is the interface DataObject and it
> > > needs to be mapped to a specific schema type such as "address", the
> > > following
> > > steps are needed:
> > > 1. Create an xsd file for the "address" schema type.
> > > 2. Generate a Java class Address from this xsd file using JAXB.
> > > 3. Create a JAXB adapter class to specify the property mapping, for
> > > example:
> > > public class AddressAdapter extends XmlAdapter<Address, DataObject> {
> > > public DataObject unmarshal(Address value) {
> > > // If the SCA runtime will use the JAXB unmarshaller to convert
> > > // the property value to a Java object, this method needs to
> > > // contain code to create an instance of DataObject
> from an Address
> > > // object passed in by the JAXB unmarshaller. If the property
> > > // conversion will be done in some other way (e.g., by SDO), this
> > > // method can just return null.
> > > }
> > > public Address marshal(DataObject value) {
> > > return null; // SCA properties are never converted from
> Java to XML
> > > }
> > > }
> > > 4. Annotate the property whose Java type is DataObject with the
> > > annotation @XmlJavaTypeAdapter(AddressAdapter.class)
> > > A separate adapter class is required for every schema type that is a
> > > possible
> > > mapping target for the property.
> > >
> > > If the property needs to be mapped to a specific schema element instead of
> > > a schema type, the steps are the same except that an "address" schema
> > > element
> > > is used in step 1, and an additional annotation @XmlElement
> (name="address")
> > > is used on the property in step 4.
> > >
> > > If the property needs to be mapped to a schema <any> element,
> steps 1, 2 and
> > > 3 are not needed. In step 4, the annotation @XmlAnyElement is used on the
> > > property instead of @XmlJavaTypeAdapter.
> > >
> > > I have verified all of the above with some simple test code.
> > >
> > > Simon
> > >
> > > David Booz wrote:
> > > > http://www.osoa.org/jira/browse/JAVA-179
> > > >
> > > > 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
> > > >
> > > > Inactive hide details for David Booz---08/24/2009 04:16:58 PM---TARGET:
> > > > Java CAA CD03 and Java POJO CD01 DESCRIPTION:David Booz---08/24/2009
> > > > 04:16:58 PM---TARGET: Java CAA CD03 and Java POJO CD01 DESCRIPTION:
> > > >
> > > >
> > > > From:
> > > > David Booz/Poughkeepsie/IBM@IBMUS
> > > >
> > > > To:
> > > > sca-j@lists.oasis-open.org
> > > >
> > > > Date:
> > > > 08/24/2009 04:16 PM
> > > >
> > > > Subject:
> > > > [sca-j] NEW ISSUE: Need type support for @Property when used with SDO
> > > >
> > > >
> ------------------------------------------------------------------------
> > > >
> > > >
> > > >
> > > > TARGET: Java CAA CD03 and Java POJO CD01
> > > >
> > > > DESCRIPTION:
> > > > SDO DataObject can be mapped to any XML schema type, and therefore
> > > > literally <any> as well. There is no way to specify the concrete XML
> > > > type of a Java property who's Java type is SDO DataObject.
> > > >
> > > > PROPOSAL:
> > > > Will be attached to JIRA once the issue is logged.
> > > > Basically, the proposal will introduce two new attributes on @Property,
> > > > xmlType (for specifying the XML schema type) and xmlElement (for
> > > > specifying an XML global element that denotes the type). The new
> > > > attributes are mutually exclusive.
> > > >
> > > >
> > > > 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
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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
> > >
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > 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
> >
>
|