geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <>
Subject Re: XMLBeans, a quick comment
Date Sat, 16 Aug 2003 14:01:28 GMT
On Saturday, August 16, 2003, at 12:56  pm, Jason Dillon wrote:
>> However the point of these beans is to act as the POJO API for 
>> working with the XML config files. So I don't see much value in using 
>> the beans without the XML config files. So I don't see this extra-jar 
>> dependency as a big issue. Even if you were not using an XML config 
>> file, the XPath & XSD validation is extremely useful too.
> I understand, though I would like to find a common binding framework 
> which the entire project could use.

I'm just focussing right now on 1 use case - to find an XML binding 
tool to handle all the various J2ee schemas. Today the only solution 
that works is XMLBeans

> Take for example if there was a WAR deployer which took one of these 
> objects (not a URL to an XML file or whatever), then you could 
> programatically install web-apps with out having to deal with XML at 
> all.

When would you ever use the WAR deployer without XML? i.e. the WAR 
deployer has to read the XML config files, so xmlbeans.jar would 
already be on the classpath.  The person programmatically installing a 
web-app wouldn't really need to worry about this dependency - since it 
would already be there. To compile the code to use the deployment beans 
you wouldn't have a dependency on xmlbeans.jar. Plus with XMLBeans its 
easy to validate that the beans really match the schema - whether your 
using an XML config file or not.

Like I've said several times already, XMLBeans solves the use case I've 
described just fine. I can't imagine a use case where anyone would use 
these beans without at least allowing for XML config files to be used 
(whether a developer uses them or not). So saving this 1 jar dependency 
doesn't seem very useful to me.

> It sounds like this is possible with XMLBeans, though it would still 
> be better IMO if it XML was not a dependency, so for embedded 
> solutions which do not need or want any XML processing we could drop 
> those dependencies to provide a smaller footprint.

Am not sure its that big a deal right now - adding 1 extra jar to the 
container (which Castor would anyways). Plus right now XMLBeans is the 
only tool that can actually do the job. Until someone else can find 
another tool that works, there is no choice :)


View raw message