OT XML->Object tools, was: why not POJO's

[Dm...@toyota.com.au]

at a glance that looks similar to the jakarta digester framework
(http://jakarta.apache.org/commons/digester/) - am I missing something
there?

  _____  

From: Alexey Loubyansky [mailto:alex@jboss.org] 
Sent: Wednesday, 20 October 2004 6:11 PM
To: user@xmlbeans.apache.org
Subject: RE: why not POJO's


For pure POJO-based binding you can check out
http://www.jboss.org/wiki/Wiki.jsp?page=JBossXB. Still in alpha but at
least you can get the idea.
It's not as sophisticated as XMLBeans and, probably, has different goals.
We needed a common solution to read deployment descriptors and XML configs
in JBoss (compare this to what David is talking about).
 
alex


  _____  

From: Dmitri.Colebatch@toyota.com.au
[mailto:Dmitri.Colebatch@toyota.com.au] 
Sent: Wednesday, October 20, 2004 9:30 AM
To: user@xmlbeans.apache.org
Subject: RE: why not POJO's


If I could add a couple of thoughts...
 
1. I believe the hype about hibernate is not due to the fact that its
POJOs per se - but that it is a lightweight framework.  I believe that
XMLBeans is also a lightweight framework - just because it doesn't use
POJOs doesn't rule it out of that one.
 
2. I would _much_ prefer XMLBeans to Axis when it comes to using SOAP.
Axis requires (or at least did when it I last used it, which to be fair
was a few years ago) you to write your own serializers/deserializers for
your own classes.  Using XMLBeans this sort of stuff is a no brainer.   On
a side note you may be interested to browse the archives for discussions
of an XMLBeans based serializer for Axis.
 
If you want POJOs to contain your business logic, I would suggest using
XMLBeans objects as simple data holders and then have a bean containing
business logic that wraps an XMLBeans instance.
 
cheers
dim

  _____  

From: Hiller, Dean D (Dean) [mailto:dhiller@avaya.com] 
Sent: Wednesday, 20 October 2004 4:17 AM
To: user@xmlbeans.apache.org
Subject: RE: why not POJO's



Wow, great response.  Thankyou very much.  Some follow up
questions/thoughts.

 

That really makes sense that you might want to acess the xml sometimes.
Thanks for giving me that understanding.

 

Is there some way however to do that outside the beans?  Ie. Keep the POJO
with no imports of xml beans and possibly have a <POJO>Descriptor which
allows the more advanced mechanisms you talk about.  

 

Another way to achieve the more advanced features might be doing whatever
hibernate did(which I still have on my list of things to see how they did
it).  From what I understand, they subclass your POJO to achieve lazy
fetching.  I think they must do that all at startup though so they don't
affect the performance adversely.don't know.  There may be a solution in
there somewhere.

 

Anyways, is something like this possible.  We had to refactor something at
my company and rip castor out.  This happens once in a while and POJO's
make it a one step thing, remove the jar's and Descriptors and you are
done.  No need to change the POJO's as they are just that.

 

Is there something here that might be able to be leveraged in future
releases of xml beans?  Part of the huge hype about hibernate is that they
are just pojo's.  I think part of the hype about axis is the same
reason.they are just POJO's that marshal/unmarshal to/from SOAP.  

 

Thanks for the info and the good discussion,

Thanks,

dean

 


  _____  


From: David Remy [mailto:dremy@bea.com] 
Sent: Monday, October 18, 2004 5:33 PM
To: user@xmlbeans.apache.org
Subject: RE: why not POJO's

 

POJO's would be great and we would do it if we could.  The problem is
XMLBeans chose a design goal of supporting 100% xml schema and 100% xml
infoset.  There are a variety of features in either of these that need a
certain shape of classes to support these features.  It is possible to
subset XML Schema and XML Infoset and make POJOs but you will have problem
with various scenarios both in XML Schema support and XML Infoset support.
JAXB1 chose to subset the XML feature set and was able to generate POJOs.


 

If you are only using XML as an alternative to serializing java classes or
to hold/transfer relational data then you may be fine with some binding
tool that uses POJOs.  XMLBean's strength is in supporting all of XML and
XML Schema.  Whatever XML scenario you encounter you should be able to
address using XMLBeans.  This includes typed or untyped scenarios (xmlbean
v1 supports xmlcursor to untyped xml and xmlbeans v2 supports DOM and
XmlCursor).

 

The reality is that XML is not Java and if you try to subset it into what
fits into Java you will lose functionality.  XMLBeans is a tool that is
trying to assure you that you will be able to use all of the features of
XML making it as easy and java friendly as possible.  You can use XMLBeans
and have the confidence that you can work with any XML Schema or XML
Document you have now or run into in the future.  

 

There are multiple architectural issues that lead to not having POJOs
(although XMLBeans are intuitive to Javabean users).  Perhaps the foremost
is that XMLBeans generated classes are part of an overall XML Schema Type
system hierarchy in Java analagous to the defined XML Schema type system
(take a look at this diagram
http://xmlbeans.apache.org/docs/guide/conXMLBeansSupportBuiltInSchemaTypes
.html).  Not only does this allow a certain amount of symmetry and
elegance it makes some of the more esoteric XML Schema features more
logical and feasible.  In the XML Schema type system anyType is the uber
type and all other types descend from it.  In XMLBeans XmlObject
represents the anyType.  XMLBeans has a full set of built in types (for
example XmlPositiveInteger) that matches the corresponding XML Schema
Type, as well as having a natural java mapping whereever possible.
Similarly, the custom types you (or whoever defined the XML Schema you are
using) define and generate as XMLBeans also descend from XmlObject.  This
approach allows things such as restricting simple types and working with
facets possible and to fit into a logical framework.  

 

Another thing about XmlObjects is that they can be thought of as a fairly
thin layer over an underlying XML Store.  JAXB and other binding
approaches shred (unmarshal) the XML directly into java objects losing the
underlying XML Infoset (although potentially gaining some performance and
memory savings).  XMLBeans takes a different approach, the XML is
typically parsed into the XML Store and the XmlObjects (your XMLBeans) are
created on demand.  A major amount of the work represented in XMLBeans (on
par with Schema Compilation) is making a highly performant XML Store.
Having the XML store around has major benefits that help bridge the gap
between what Java can support in XML and cannot.  If you take a look at
the history of this list there are many circumstances where resorting to
accessing the underlying XML Store is required.  

 

Just as an aside although XMLBeans is known as a XML/Java binding model it
is also a full untyped XML access model.  In V1 the XMLCursor API was for
high speed access to the store (whether typed or untyped), in V2 there is
DOM and XmlCursor.  You can fully move between XmlObject, XmlCursor, and
DOM as your programming needs dictate.

 

There is much more to this discussion but to wrap I would say XMLBeans is
not about hiding XML from Java programmers.  It is about allowing Java
developers to harness XML and use all of its features.  It is about
blending XML and Java.   I believe this is the correct and responsible
thing to do.  How are you to know as a developer what the subset of
functionality that a particular XML tool provides?  Perhaps the technology
you choose gets you through V1 of your project but V2 comes along and you
need an XML feature that is not supported?  (I have heard personally of
this situation multiple times)  At an enterprise level XMLBeans is meant
to be a technology that can be adopted and support all of an enterprise's
existing and future XML Schemas and Documents.  

 

thanks for the comments and questions for dicussion.

rem

 


  _____  


From: Hiller, Dean D (Dean) [mailto:dhiller@avaya.com] 
Sent: Saturday, October 16, 2004 10:01 AM
To: user@xmlbeans.apache.org
Subject: why not POJO's

 

Why not generate POJO's?  It would be very nice if the beans had no
references to xmlbeans project, and instead there was some parallel
hierarchy that I never have to care about.  Have you used hibernate for
instance?  It is completely non-intrusive.  They are just POJO's from your
perspective.  It is just sooo much cleaner this way....so clean that
entity beans are being revisited in the EJB 3 spec. :-)

            I have used castor previously, but prefer to use either a JAXB
compliant library or one that does just POJO's with a parallel hierarchy
kind of like BeanInfo classes.  

I personally would pick a POJO over JAXB compliance anyday just like I
would pick hibernate over entity beans anyday(and many people are).  I
would prefer both POJO, and JAXB compliance of course.  I think many in
the community might feel the same way as I see more and more jump on
hibernate and drop entity beans(picking a non-intruisive framework over
the intruisive one)

I know castor does something very close to POJO's, but they also tied just
a few methods that import castor stuff in their beans......I had one
situation where I had to get rid of castor and ripping out all the castor
specific imports was a pain...if only they were POJO's!!!  I personally
think it would be even harder looking at the generated code of xmlbeans.
Anyways, this is just one persons opinion.  Thought I would at least ask
why.  Thanks for any info and rational that I am not thinking about.

Thanks,

dean

 

#####################################################

DISCLAIMER: 
This email and any attachment may contain confidential information.
If you are not the intended recipient you are not authorized to copy
or disclose all or any part of it without the prior written consent
of Toyota.

Opinions expressed in this email and any attachment are those of the
sender and not necessarily the opinions of Toyota.
Please scan this email and any attachment for viruses.
Toyota does not accept any responsibility for problems
caused by viruses, whether it is Toyota's fault or not.
#####################################################


######################################################################
DISCLAIMER: 
This email and any attachment may contain confidential information.
If you are not the intended recipient you are not authorized to copy
or disclose all or any part of it without the prior written consent
of Toyota.

Opinions expressed in this email and any attachment are those of the
sender and not necessarily the opinions of Toyota.
Please scan this email and any attachment for viruses.
Toyota does not accept any responsibility for problems
caused by viruses, whether it is Toyota's fault or not.
######################################################################

unregister

[Rudi Vaum <ru...@vaum.net>]

unregister

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: user-help@xmlbeans.apache.org