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 dependencies. Jarek On 2/7/07, David Jencks <[EMAIL PROTECTED]> 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
