geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <>
Subject Re: ClassFinder questions/problems -- annotation processing
Date Fri, 16 Feb 2007 22:12:51 GMT

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.


> 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

View raw message