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