geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jarek Gawor" <>
Subject Re: NamingBuilder.buildEnvironment(...) broken
Date Wed, 07 Feb 2007 18:41:39 GMT
I think I'm pretty much in the same boat. Here are two cases I have:

1) In WebServiceContainer.findWebServices()  (which is called when
ModueBuilder.createModule() is called) I need to discover all classes
in the module that are annotated with @WebService or
@WebServiceProvider annotation.

2) In ServiceRefNamingBuilder during buildEnvironment() I need to
discover the type of reference it is (JAX-RPC or JAX-WS) and based on
this type add in the right environment. So for that I need to the
classloader to actually load the class to be able to do
class.isAssignableFrom() type of stuff.

For now, for 1) I guess I could use David Blevins' hack if it is
factored out nicely somewhere, and for 2) I can hardcode the
ServiceRefNamingBuilder to always add both JAX-RPC and JAX-WS


On 2/7/07, 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??
> >
> > 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.
> 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?
> thanks
> david jencks
> >
> > -dain

View raw message