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
class.
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.
Sure.
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.
-dain
