geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim McConnell <tim.mcco...@gmail.com>
Subject Re: ClassFinder questions/problems -- annotation processing
Date Fri, 16 Feb 2007 05:25:45 GMT
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).

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 ??

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
>>
> 

Mime
View raw message