Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (herse.apache.org: domain of david.blevins@visi.com
 designates 208.42.156.2 as permitted sender)
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <45D54059.9020705@gmail.com>
References: <45BC409B.4080205@gmail.com>
 <2746BE6A-CB28-4A72-84C5-960B07B4411C@visi.com> <45C6A25C.3050405@gmail.com>
 <390B073C-A2DE-4231-83B3-C1C220739485@visi.com>
 <FB2D8370-CF3C-48A6-8428-64673B630B30@iq80.com> <45C96F76.7000200@gmail.com>
 <45D54059.9020705@gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <413376D5-958E-44DA-BE29-E5E5E282DD87@visi.com>
Content-Transfer-Encoding: 7bit
From: David Blevins <david.blevins@visi.com>
Subject: Re: ClassFinder questions/problems -- annotation processing
Date: Fri, 16 Feb 2007 14:12:51 -0800
To: dev@geronimo.apache.org


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