You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Kenneth Tam <ke...@gmail.com> on 2005/07/08 19:39:01 UTC

xmlbeans usage in Geronimo -- upgrading to xbeans 2.0?

Hi folks,

I'm exploring the ability to use various versions of xmlbeans with
Geronimo.  In particular, I'm interested in being able to deploy a
J2EE app/module (say, a WAR) that depends on a specific version of
xmlbeans (which it provides, say in WEB-INF/lib).  Looking at this one
use case leads me to a number of questions..

I see v1 of xbeans being used in what appears to me (without deeper
knowledge) to be the system classloader of the server.  It seems the
natural usages of xbeans in Geronimo would be for general processing
of xml configuration files (J2EE DDs, Geronimo-specific config, etc),
as well as for xml processing in the J2EE webservices stack.

Has there been provision made in Geronimo's usage of xbeans for the
concurrent usage of multiple versions?  I see
http://issues.apache.org/jira/browse/GERONIMO-382, which suggests that
there has been some concern about how xbeans is classloaded, but that
particular JIRA issue is very narrow.

Is anyone already exploring upgrading the version of xbeans used by
Geronimo to v2?  I'm beginning to play with it, but context would be
much appreciated.  For starters, it appears that there is some CGLIB
munging of xbeans compiled schema classes (this is based on a stack
trace I saw simply by replacing xbeans v1 with v2 at runtime) -- that
seems pretty scary.  The xbeans folks I've talked to tell me that the
compat level they were shooting for is source-level, ie they expect
clients to recompile their schemas using the new version of xbeans..
I'm working on that now.

thanks,
ken

Re: xmlbeans usage in Geronimo -- upgrading to xbeans 2.0?

Posted by David Jencks <dj...@gluecode.com>.
On Jul 8, 2005, at 2:05 PM, David Jencks wrote:

>
> On Jul 8, 2005, at 1:51 PM, Kenneth Tam wrote:
>>
<big snip>
>> 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 
> xmlbeans-free.
>
> I'm going to experiment with this a bit this afternoon.

For once, all went smoothly and xmlbeans are now a normal dependency of 
the builders, not something in the root classloader.  So, you should be 
able to use any version of xmlbeans in an app without interference.  
This should be in the soon-to-be-released M4 as well as svn.  Please 
let us know how it works.

thanks
david jencks

>>
>> (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 
> names.
>
> thanks
> david jencks
>
>
>
>>
>> thanks,
>> ken
>>
>


Re: xmlbeans usage in Geronimo -- upgrading to xbeans 2.0?

Posted by David Jencks <da...@yahoo.com>.
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:
>
> http://nagoya.apache.org/eyebrowse/ReadMsg? 
> listName=dev@geronimo.apache.org&msgNo=11169
>
> 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  
xmlbeans-free.

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  
names.

thanks
david jencks



>
> thanks,
> ken
>


Re: xmlbeans usage in Geronimo -- upgrading to xbeans 2.0?

Posted by Kenneth Tam <ke...@gmail.com>.
> 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:

http://nagoya.apache.org/eyebrowse/ReadMsg?listName=dev@geronimo.apache.org&msgNo=11169

Ie, just your msg -- if there's any archived discussion on this, or
replies to your msg, I'm not finding them.

> 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.

> 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?

(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.

thanks,
ken

Re: xmlbeans usage in Geronimo -- upgrading to xbeans 2.0?

Posted by David Jencks <da...@yahoo.com>.
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.

Some problems have crept in in my latest update, and I haven't been 
able to figure out how to solve them.  The symptoms I see are that I 
get different binary xsb files generated depending on whether I build 
one module at a time or all at once with a multiproject build.  
Depending on which generated classes I get classes from imported 
namespaces work, or don't.

I'm not sure how to proceed.  I could post a patch to a jira issue, or 
create a geronimo branch.  However there are openejb changes as well, 
and dealing with a cvs branch seems awfully painful.

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.

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:-)  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.

thanks
david jencks



On Jul 8, 2005, at 10:39 AM, Kenneth Tam wrote:

> Hi folks,
>
> I'm exploring the ability to use various versions of xmlbeans with
> Geronimo.  In particular, I'm interested in being able to deploy a
> J2EE app/module (say, a WAR) that depends on a specific version of
> xmlbeans (which it provides, say in WEB-INF/lib).  Looking at this one
> use case leads me to a number of questions..
>
> I see v1 of xbeans being used in what appears to me (without deeper
> knowledge) to be the system classloader of the server.  It seems the
> natural usages of xbeans in Geronimo would be for general processing
> of xml configuration files (J2EE DDs, Geronimo-specific config, etc),
> as well as for xml processing in the J2EE webservices stack.
>
> Has there been provision made in Geronimo's usage of xbeans for the
> concurrent usage of multiple versions?  I see
> http://issues.apache.org/jira/browse/GERONIMO-382, which suggests that
> there has been some concern about how xbeans is classloaded, but that
> particular JIRA issue is very narrow.
>
> Is anyone already exploring upgrading the version of xbeans used by
> Geronimo to v2?  I'm beginning to play with it, but context would be
> much appreciated.  For starters, it appears that there is some CGLIB
> munging of xbeans compiled schema classes (this is based on a stack
> trace I saw simply by replacing xbeans v1 with v2 at runtime) -- that
> seems pretty scary.  The xbeans folks I've talked to tell me that the
> compat level they were shooting for is source-level, ie they expect
> clients to recompile their schemas using the new version of xbeans..
> I'm working on that now.
>
> thanks,
> ken
>