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 Sat, 17 Feb 2007 04:59:18 GMT
Thanks for the info David. At times it's not obvious to me which annotations 
have already been implemented as part of other projects and which require 
Geronimo implementation changes. So I've been keeping track of them on the wiki 
below. The ones with a red-X or green-Checkmark in the far-right-hand column are 
those that I'm assuming will require Geronimo changes. I'm working on the 
JSR-250 set now so if you if you have a chance to review and/or verify my 
assumptions that would be helpful to me.

http://cwiki.apache.org/confluence/display/GMOxDEV/Java+EE+5+Annotations

Thanks,
Tim McConnell


David Blevins wrote:
> 
> 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
>>>>
>>
> 
> 

Mime
View raw message