geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: NamingBuilder.buildEnvironment(...) broken
Date Wed, 07 Feb 2007 18:10:35 GMT
On Feb 7, 2007, at 8:13 AM, David Jencks wrote:

> On Feb 6, 2007, at 6:38 PM, Dain Sundstrom wrote:
>> This is really for David Jencks since I think he is the only one  
>> that understands this code....
>> In the createModule phase of deployment, the code must build the  
>> Geronimo environment object so we can create a class loader.  Most  
>> of the data for this object comes from the geronimo-*.xml  
>> deployment plan, but the naming builders can add additional  
>> dependencies to the environment.  Basically, the naming builders  
>> inspect the specDD and vendorDD to see if either is using a naming  
>> ref that the builder handles, and if so the builder adds the  
>> dependencies the application will need to use that reference object.
>> The problem is in JEE5 reference objects are defined in class  
>> annotations, and to read these annotations you need a class  
>> loader, and to get a class loader you need an environment object,  
>> and to get the environment object you need to process the  
>> references in the annotations.  As you can see we have a chicken  
>> and egg problem.
> I thought david blevins wrote something in xbean to use asm to find  
> these annotations explicitly to avoid loading the classes in a  
> class loader??

It uses a class loader, but doesn't load classes.  It uses the class  
loader getResource methods to find jars and to load the byte code for  

>> I suggest that in the short time (while Jencks figures out how to  
>> modify the builders for Jee5), we hard code the naming builders to  
>> always add their dependencies.
>> What do you think?
> If we actually need a classloader that's a reasonable short term  
> solution.

That is currently a requirement.  I'll add the hack (and some comments).

> If we actually do need a classloader then we should be able to  
> construct one that will work from the environment BEFORE we run any  
> naming builders.  The naming builders should only be adding server  
> components that the app should not be expecting to be in its  
> classpath automatically.


> I thought the plan was to first scan all the classes for  
> annotations and turn them into xml, and then process the xml as at  
> present.  Where in the deployment lifecycle do you expect these  
> steps to happen, or do you have a different idea?

That is kind of what we do in openejb, but it is integrated into the  
deployment cycle which needs the class loader.


View raw message