[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AW: [sdo] ISSUE 5 and ISSUE 22: Discussion of JAXB
Hi Blaise,
Lots of interesting stuff. In a way, the proposal is
not far from the "project/cast" methods I proposed here: http://www.oasis-open.org/apps/org/workgroup/sdo/download.php/27905/SDO3%20Java%20Projections.ppt.
See slides 29 and 30. You've added JAXB intelligence. Do you see
other special contexts, eg, JPAHelperContext or DomHelperContext? If I
understand you, you'd be against anything like a PlainPojoHelperContext,
right?
Over the year, I've personally become less convinced of the
wrapping approach, as opposed to providing some kind of optimized data transfer.
What do you see as the advantage of wrapping over some kind of convert
operation? Instead of wrapping the POJOs, I could mashal them in JAXB, and
load them using XMLHelper. Does wrapping give me something here I could
not get through such a mechanism (modulus performance)? And of
course because of the second point below, the getters and setters could become
significantly more expensive, offsetting the gains made in avoiding a conversion
step.
There is a third approach, and that is for the framework to
weave the POJO classes, so that "new Customer()", or at least
ObjectFactory.createCustomer() returns an object that already implements
DataObject. It seems to me this is a straightforward extension of JPAs
approach. In our JPA integration, you turn on this bytecode enhancement
with a flag in persistence.xml. Do you think it would be possible to get
to this level of integration with JAXB?
Either way, I have some questions to the
details:
Why is the call to XSDHelper.define() necessary?
Couldn't the metadata be introspected from the POJOs (ala
generateSchema())? Isn't there a danger of the XSD being out of sync with
the classes (similar to your comment regarding the @schemaLoc
annotation?
Does DataObject customerDO = hc.wrap(customer);
always return the same DataObject? It's maybe a implementation
detail, but does wrap create the DataObjects lazilly or all at once?
If you do it lazilly, you need to maintain a map from the POJO object to the
DataObject wrapper, right? Otherwise as we navigate around, we could wind
up with the same POJO having 2 DataObject wrappers. And such a map raises
a bunch of ugly lifecycle issues. This is where I thought something like a
binder could come come in handy, as a way of putting the lifecycle in the hands
of the client.
What happens if a wrapped POJO is modified?
Obviously, calls to DataObject.get() would see the changes, but what about
things like change tracking, containers, and bi-directional properties, that, in
SDO happen implicitly when a setter is called? Are you "weaving" the byte
code of the JAXB POJO?
Is there any way to start with a DataObject, and generate a
JAXB from it? Ie, can I unwrap something that hasn't been wrapped?
When I create a DataObject using DataFactory.create(), does it automatically
create an underlying POJO?
Regarding the StAX and JAXB dependencies.
I guess it will be 2010 before any SDO 3 implementations are released as
products... I imagine by that time pretty much everyone will be on JSE
6. Maybe we should consider raising the minimum compatible JSE to JSE
6. What do you think?
You mention that customers
have expections about the XML representation of POJOs. What about POJOs
that are not organized into a containment structure? Eg, my
example:
class
School {
List<Student> getStudents() {...}
List<Course> getCourse() {...}
}
class Course {
School getSchool() {...}
List<Student>
getStudents() {...}
}
class Student
{
School getSchool() {...}
List<Course> getCourses() {..}
}
what do your customers
expect from the XML representation of School? AFAIK, the programmer has to
specify the XML containment structure as part of the model, He must annotate
give the object ID properties, and he must use @XmlID to indicate
non-containment. I don't think SDO is competing with JAXB if it specifies
a mechanism through which such graphs can be marshalled to XML. SDO 3
offers 2 such mechanisms: the graph could be placed inside an container
with orphan properties, and the containment structure (or alternate structures)
can be imposed on the model through the project method. Offering this kind
of fuctionality is one reason to include an SDO-POJO binding in SDO
3.
Best
Regards,
Ron
Von: Blaise Doughan [mailto:blaise.doughan@oracle.com] Gesendet: Freitag, 23. Januar 2009 17:02 An: Barack, Ron Cc: sdo@lists.oasis-open.org Betreff: Re: [sdo] ISSUE 5 and ISSUE 22: Discussion of JAXB I'm glad you raised this email thread. Integration with JAXB (POJOs) is also an important use case to Oracle and in particular the EclipseLink SDO implementation. Both SDO and JAXB have an XML schema representation of their metadata. For us this is the join point between these two technologies. EclipseLink DataObjects are capable of wrapping POJOs, actions applied to the DataObjects (set/unset/detach/etc.) are automatically applied to the underlying POJO. I have included some code below to demonstrate: // JAXB - Create the JAXB Context JAXBContext jaxbContext = JAXBContext.newInstance("com.example.customer"); // SDO - Create the JAXB aware HelperContext HelperContext hc = new JAXBHelperConext(jaxbContext); hc.getXSDHelper().define(customerXSD); // SDO - Wrap the POJO in a DataObject Customer customer = new Customer(); customer.setLastName("Doe"); DataObject customerDO = hc.wrap(customer); // SDO - Create and modify DataObjects customerDO.getString("last-name"); // returns "Doe" customerDO.setString("first-name", "Jane"); DataObject addressDO customerDO.create("address"); addressDO.setString("street", "123 Any Street"); // SDO - Unwrap the POJOs // Note: customer == hc.unwrap(customerDO) Customer customer2 = (Customer) hc.unwrap(customerDO); I would prefer to not invent a POJO to SDO binding. Our customers have expectations about the XML representation of POJOs. As JAXB is included in Java SE 6, I imagine many people share these expectations. If Java objects save to XML one way, the act of wrapping them in (or converting them to) DataObjects should not change the XML representation. Of course if users choose to make use of concepts such as ChangeSummary then the XML representation begins to diverge but in predictable and explainable ways. For us it is imperative that SDO provides a compatible value add to Java EE, and not become a competitor to any of its technologies. Other Points:
Barack, Ron wrote: 7C3EF93EEBC6EB4A8B4470853DE86566564AD6@dewdfe18.wdf.sap.corp type="cite"> |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]