geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: xmlbeans usage in Geronimo -- upgrading to xbeans 2.0?
Date Fri, 08 Jul 2005 21:05:47 GMT

On Jul 8, 2005, at 1:51 PM, Kenneth Tam wrote:

>> I've been attempting to maintain a port to xmlbeans 2 for about 6
>> months and have been getting very tired of objections to installing  
>> it.
>>  I'm now afraid that this has resulted in xmlbeans 2 being released
>> with some bugs that will make using it difficult.
> I'm grovelling the dev list archive and the only discussion (if you
> can call it that :) I can find is this:
> Ie, just your msg -- if there's any archived discussion on this, or
> replies to your msg, I'm not finding them.

IIRC there was some encouragement and some requests to wait... anyway  
there's not much we can do now.
>> The inclusion of xmlbeans in the root classloader should be
>> unnecessary.  IIRC it was needed because we didnt' have a single
>> version of the QName class: now that we do it should no longer be
>> necessary.
> Is there a brief overview of "how geronimo uses classloaders"
> somewhere?  I can't find anything on the wiki.

I don't know :-)  Briefly, geronimo is "all gbeans" which are loaded in  
groups called Configurations.  Each configuration has a classloader,  
and (except for the "root" configuration) a parent configuration, which  
is also the parent classloader.
>> The intention is that xmlbeans and xmlbeans generated classes should
>> only be used in  the builders, and not needed in the runtime system.
>> If this is no longer the case, we have some work to do:-)
> When you say "only used in the builders", do you mean "only used at
> build time"?  (I'm unclear on what the term "builders" means in this
> context).  This suggests that the runtime system never loads
> xmlbeans-generated schema classes, which strikes me as odd.. for
> example, aren't J2EE DDs manipulated using generated xmlbeans schema
> classes?

The builders convert various input, such as J2EE artifacts + geronimo  
plans, to stored configurations.  After this conversion, no xml is  
present so no xml processing is needed.  For the running geronimo  
server, the builders are in a separate, optional, configuration  
(org/apache/geronimo/RuntimeDeployer, plan is in  
j2ee-runtime-deployer-plan.xml).  Applications normally have  
org/apache/geronimo/Server as their parent configuration/classloader.   
We should be able to move the xmlbeans dependency into the  
RuntimeDeployer configuration, leaving the app's classloader  

I'm going to experiment with this a bit this afternoon.
> (excuse me if this is all sounding totally clueless, I've just started
> looking at the Geronimo codebase)
>> If we can
>> maintain this separation there should be no problem in using any
>> version of xmlbeans in an application, since the builder classloaders
>> using xmlbeans and the application classloaders using xmlbeans would  
>> be
>> unrelated.
>> If you want to help sort this out, your work would be extremely  
>> welcome.
> My main interest is in getting to the point where applications can use
> xmlbeans v2.  If it turns out that this means geronimo's "native"
> usage of xmlbeans also needs to be upgraded, that would be
> unfortunate, but not surprising -- besides any issues in Geronimo, I
> am not sure what limitations xmlbeans itself has wrt concurrent usage
> of v1 and v2.

I doubt it would work: I believe most of the classes have the same  

david jencks

> thanks,
> ken

View raw message