On Feb 15, 2007, at 9:25 PM, Tim McConnell wrote:
Hi David/Dain, I finally see what's going on here now--and it
really makes a lot of sense. I'm not so sure it's a bug with the
classloading process so much as it's just the way the current code
functions. I can't easily show a sequence diagram here but can
briefly explain. It appears the the "EarContext" for a deployed EAR
file is aggregated across successive calls from
EARConfigBuilder.buildConfiguration() to the installModule() method
on first the WebModuleBuilder class, and then second on the
EjbModuleBuilder class. This explains why ClassFinder was working
correctly in EjbRefBuilder (i.e. the deployed module's EarContext
had been fully aggregated) but failed for me in
AbstractWebModuleBuilder (i.e., the deployed module's EarContext
had not yet been fully aggregated).
That would explain a lot! Though, this does seem like an issue that
should be fixed. I know DJ isn't fond of some of the hacks we've had
to add in the builder process. Likely this may be the straw that
broke the camels back.
So, rather than fixing something that's not really broken in
AbstractWebModuleBuilder, the best solution in my view is to push
the Annotation processing out of the installModule processing of
the module builder(s) up into the configuration builder. This would
allow us to encapsulate the Annotation processing for deployed EJB
applications, Web applications, App Client applications, and
Connectors (not sure these would be annotated though) into a single
class: EARConfigBuilder. Additionally, it would guarantee that we
always have access to a fully aggregated EarContext, and thus a
fully populated classloader to pass to ClassFinder. And finally, I
think it would encapsulate most of the Geronimo annotation
processing except for Web Services. This approach is somewhat in
line with my original proposed plan for Annotation Processing for
Geronimo, it's just the conduit has changed somewhat. Do either of
you (or anyone else) have any thoughts, comments and/or concerns ??
That'd be fine for Web modules and App Clients -- there are no
Connector annotations and EJB annotations are taken care of by
OpenEJB. I know you keep wanting to do all the EJB-specific
annotations, but there's no real reuse there. Web modules and
Connectors pretty much both have the same stuff, which is really only
the five or so JSR-250 annotations plus these from javax.ejb: @EJB
(s), @PersistenceUnit, and @PersistenceContext.
You can cross the rest off your list: i.e. javax.ejb @Remote,
@RemoteHome, @Local, @LocalHome, @Stateless, @Stateful,
@MessageDriven, @PrePassivate, @PreActivate, @Init, @Remove,
@Timeout, etc. These are EJB specific and already implemented for
the most part.
-David
Thanks,
Tim McConnell
Tim McConnell wrote:
Hi Dain, What you suggest does make a lot of sense. But for the
stateless-calculator ear file (i.e., calculator-stateless-ear-2[1].
0-M2.ear) I would then expect to find the calculator-stateless-
ear-2[1].0-M2.jar file on one of the parent classloaders for the
WAR classloader in AbstractWebModuleBuilder. It's not, so I
suspect there is a bug somewhere as you suggest. I shall
investigate further tomorrow. Thanks for the pointer....
Dain Sundstrom wrote:
On Feb 6, 2007, at 12:49 PM, David Blevins wrote:
On Feb 4, 2007, at 7:19 PM, Tim McConnell wrote:
Hi again Dave, after your recommendation below to do all the
annotation discovery during the installModule phase of
deployment ClassFinder is working much better for me. I do
still have another scenario I'd appreciate some advice on. It
seems that when an EJB EAR file (with embedded JAR and WAR
files) gets deployed in Geronimo, there are two builders
invoked: e.g., TomcatModuleBuilder/AbstractWebModuleBuilder and
EJBModuleBuilder such that the embedded JAR file is not added
to the ClassPath/ClassLoader when the WAR is deployed (I assume
this is the way it should work since I haven't changed it--
yet). So, if there are annotations in the WAR class files
pointing to classes in the JAR file, we'll still encounter
NoClassDefException(s). I can just add the JAR files in the EAR
to the classpath of the WAR, which is what I've done to get
around the problem, but I'm not sure this is the best
alternative. Do you have any thoughts?? Thanks much
Those should be added automatically via the deployment system.
Very puzzling. Dain, did you see anything like this when you
did that hack for @EJB annotation support in Servlets?
Nope. The WAR class loader is a child of the EAR class loader so
the WAR should "see" all of the jars in the ear. If that is not
the case, then there is a bug.
-dain
