+1 for james amendment (ie use a naming convention that gives us mashalling for
free - but no opinion on betwixt vs digester etc.)
+1 for pojos (well for doing something).
I'm happy to write/generate the classes for the webapp deployment
descriptor - but there is now a twisty little maze of schema dependancies
on the j2ee descriptors.
James Strachan wrote:
> +1
>
> with a minor change. If we're gonna be hand-coding POJOs ourselves then
> there's less reason to use XMLBeans - so I suggest we use something like
> betwixt rather than XMLBeans to do the parsing / converting to XML.
> Thats probably gonna be easier to use and have a smaller dependencies in
> terms of jars. Then we just need to follow some simple naming
> conventions in the POJOs to get the XML marshalling for free. e.g.
>
> public class WebApp {
>
> public void addServlet() {
> ...
> }
>
> public List getServlets() {
> ...
> }
>
> }
>
> public class Servlet {
> public String getName() {..}
> public void setName(String name) {...}
> }
>
>
>
>
> On Sunday, August 31, 2003, at 09:41 pm, Jeremy Boynes wrote:
>
>> At this time I think the biggest issue is the lack of decision. None of
>> the solutions seems, at this time, to be complete let alone perfect.
>> XMLBeans appears to offer the most complete solution long term but does
>> not seem to be ready now. Castor looks like a partial, short-term
>> solution, but may not work long-term and may have licensing issues
>> (Intalio).
>>
>> I suggest the following plan:
>>
>> * We define POJOs that represent the data objects but which are not
>> bound to XML
>> or to any usage model (e.g. DConfig). This provides us with an object
>> model
>> for the data everyone can use no matter which framework we end up
>> using. A
>> requirement for the framework is that it can populate the data into
>> and out
>> specializations of this object graph.
>>
>> * Each tool that needs this data model can specialize the behaviour of
>> this
>> object graph as needed - for example, DConfigBean impls might subclass
>> these
>> object and add support for the DConfigBean interface and change
>> notifications.
>>
>> * We define a simple, loader framework that can load an XML instance
>> document
>> into this object graph. This is load only, so does not need to deal
>> with any
>> modifications to the graph. It does no validation over and above that
>> supplied
>> by the underlying parser. This should be kept really simple as the
>> ultimate
>> intention is to throw it away. How this is done is not yet known -
>> digester
>> may be an option.
>>
>> * We look for a framework that provides load and store functionality
>> (including
>> schema validation of data during the store process) between XML
>> instance
>> documents and the POJO object graph. The most likely candidate here is
>> XMLBeans
>> as, eventually, it should be easy to modify it to get the exact
>> behaviour we
>> need.
>>
>> I would ask for a vote on this an an approach - please limit responses
>> to +1, 0 or -1 and why (we have had enough discussion of alternatives
>> for now).
>>
>> --
>> Jeremy
>>
>>> -----Original Message-----
>>> From: Aaron Mulder
>>> [mailto:ammulder@alumni.princeton.edu]
>>> Sent: Sunday, August 31, 2003 11:34 AM
>>> To: geronimo-dev@incubator.apache.org
>>> Subject: [XML Parsing]
>>>
>>>
>>> On Sun, 31 Aug 2003, Jeremy Boynes wrote:
>>>
>>>> ...
>>>> Where are we on XML parsing?
>>>
>>>
>>> I'd like to resolve that too. I've worked a bit with
>>> both Castor
>>> and XMLBeans on the deployment stuff, and here's what I've
>>> come up with:
>>>
>>> - Castor produces plain Java objects, with another layer of XML info
>>> objects that can be essentially ignored at runtime (they're used only
>>> under the covers)
>>>
>>> - XMLBeans produces richer objects, which know the name of
>>> the document they came from, support XPath queries, and so
>>> on, but also have a lot more in them than seems strictly
>>> necessary, and code is generated in at least one cryptic
>>> package other than the one(s) you're targeting.
>>>
>>> - Castor appears to depend on overriding the Xerces version
>>> in the JDK
>>> (for 1.4.2)
>>>
>>> - I can't get XMLBeans to actually load a document right now
>>> (due to some
>>> kind of missing file dependency?)
>>>
>>> - Castor has a smaller runtime library (over 1MB, but about
>>> 1/2 the size
>>> of XMLBeans)
>>>
>>> - XMLBeans is in the process of moving from BEA to Apache,
>>> but at last
>>> notice the source wasn't imported and the build script wasn't
>>> working. On
>>> the other hand the current download from BEA appears to be
>>> covered by a
>>> BSD license.
>>>
>>> - reportedly Castor won't generate object for the full J2EE
>>> schema, while
>>> XMLBeans will, and JAXB will (painfully) [from James]
>>>
>>> - I know nothing else about JAXB
>>>
>>> - Castor is currently integrated into the build scripts (for
>>> Twiddle and the Geronimo EJB DD schema), while XMLBeans isn't
>>> quite (the code is there but the scripts need to be tweaked a bit)
>>>
>>> I hope James will speak up, because I think he has more
>>> experience with JAXB and XMLBeans and the J2EE schema issue.
>>> I have a slight preference for Castor (since it and the beans
>>> it generates are both lighter weight), but I'm willing to go
>>> with XMLBeans if we can resolve the problem reading XML into
>>> objects and it's the only way to get the J2EE schema out (and
>>> the XPath feature seems likely to be pretty handy too).
>>>
>>> Bottom line, I'd like to be able to just make a
>>> decision and move
>>> forward.
>>>
>>> Aaron
>>>
>>>
>>
>>
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
>
|