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 tim.mcconne@gmail.com
 designates 66.249.82.225 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=FYS3VRIwQHAUAizCdudrjcZMReEGH02xTDD0HzIGn66eV1ptC1PRes2smYbACqFru98SwEcgGgiKbSWZQqK92HkaMXZmJoAjjXY3cORZv6jKOxPyxMkwetbtNpwCK7dAfMaWvPTGjGkMIBQ4m7PMVR+3UrL44lUczW6fa7CS95o=
Message-ID: <45DA7E6B.5000107@gmail.com>
Date: Mon, 19 Feb 2007 23:51:55 -0500
From: Tim McConnell <tim.mcconne@gmail.com>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: ClassFinder questions/problems -- annotation processing
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> <413376D5-958E-44DA-BE29-E5E5E282DD87@visi.com>
 <45D68BA6.8090203@gmail.com> <E6B8FFDD-FDCE-4FD4-87A9-23EE84F91309@yahoo.com>
In-Reply-To: <E6B8FFDD-FDCE-4FD4-87A9-23EE84F91309@yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi David, I haven't applied your patch yet but will do that first thing in the 
morning--I've been looking at all the Naming Builders. So based on the current 
set of Naming Builders we have in Geronimo it looks like we should have to 
support the following references via annotations:

ejb-ref
ejb-local-ref
env-entry
message-destination
message-destination-ref
persistence-context-ref
persistence-unit-ref
resource-ref
resource-env-ref
service-ref
security-role
security-role-ref

So tomorrow, I'll continue updating the pertinent module builders with methods 
to update their DD and will augment more of the annotations supported. I think 
we'll still need to encapsulate some of the DD-->XML translation code to prevent 
duplicate code in the module builders, but a static helper class might be ideal 
for that. I'll get you another patch sometime tomorrow so you can review. Thanks 
for your help today....


Thanks,
Tim McConnell


David Jencks wrote:
> I think the only annotations geronimo itself has to pay attention to are:
> 
> javax.annotation.Resource(s)
> javax.annotation.security.* (maybe)
> javax.ejb.EJB(s)
> javax.persistence.PersistenceContext(s)
> javax.persistence.PersistenceUnit(s)
> javax.xml.ws.WebServiceRef(s)
> 
> there are some more I'm really not sure of but probably are taken care 
> of by the jaxws impl:
> javax.xml.ws.WebEndpoint
> javax.xml.ws.WebServiceClient
> javax.xml.ws.WebServiceProvider
> 
> These last might require the appropriate sub-builder (web service 
> builder) to receive a ClassFinder from whatever's calling them.
> 
> I've mostly thought about how this interacts with NamingBuilders rather 
> than other stuff like the web service builders.
> 
> I'm not sure I understand what you are proposing, but I thought about 
> this and think we can do it fairly easily within the framework of 
> pluggable naming builders while also allowing the default environments 
> to be added to the environment correctly.
> 
> Some observations on who knows what and thus who should do what:
> 
> the module builder knows which parts of the ear are accessible to the 
> module, so it should construct a ClassFinder reflecting this access.  
> This can only be done after copying files out of the source into the car 
> location.  If we can construct a classloader that reaches into an 
> unpacked ear that would be ideal, we wouldn't have to copy the j2ee app 
> at all then.
> 
> As part of this the module builder has to find all the 
> component-declaring annotations and reflect that in the ClassFinder if 
> appropriate (this is ejbs only, right? Or WebEndpoint as well?)
> 
> the naming builders each know what kind of (non-component-declaring) 
> annotations are relevant so they should look for them in the ClassFinder 
> provided by the module builder.
> 
> Only the module builder understands the schema for the spec dd, so it 
> has to add the xml for the annotations into the dd to make it 
> metadata-complete.  So the naming builders have to return the found 
> annotations in some form the module builder can deal with.
> 
> A classloader that includes the contributions of the naming builders 
> should only be needed by the naming builder itself when it's 
> constructing the reference.  It might not be needed even then.
> 
> --------------------
> 
> So here's how I see the interaction of the module builders and the 
> naming builders:
> 
> ModuleBuilder.createModule doesn't call naming builders.
> 
> ModuleBuilder.installModule copies stuff into the target and constructs 
> a ClassFinder, then calls NamingBuilder.buildEnvironment with the 
> ClassFinder.  It stuffs whatever is returned back into the spec dd at 
> the appropriate location.  The NamingBuilders add stuff to the 
> environment, so after this we can construct a real classloader.
> 
> NamingBuilder.buidEnvironment looks at the xml and extracts whatever 
> annotations are relevant for it and returns them: if also adds stuff to 
> the environment if appropriate (typically if it found something in the 
> xml or annotations)
> 
> ModuleBuilder.initContext calls NamingBuilder.initContext (although this 
> seems a bit fishy to me)
> 
> ModuleBuilder.addGBeans calls NamingBuilder.buildNaming which actually 
> constructs the references and stuffs them in a map at the appropriate 
> location.
> 
> 
> 
> I think it might be appropriate for the naming builder to make a list of 
> _all_ the stuff it will need to deal with including from the original dd 
> and return that: we can pass that in to the initContext and buildNaming 
> methods so it doesn't have to look at the xml again.
> 
> 
> -----------------
> The really nasty part of the spec here appears to me to be the extreme 
> overloading of the @Resource annotation.  I think they should have gone 
> the rest of the way and said ejb and web service refs were also 
> resources.  What I outlined above provides no good way to check that all 
> the annotations are handled by some NamingBuilder.  This might be OK.  
> An alternative might be to have the ModuleBuilder extract all the 
> possibly relevant annotations and have the NamingBuilders remove the 
> ones they process.   If there's anything left at the end, something 
> didn't get processed.  At the moment I'm not too worried by the 
> possibility that something didn't get processed.
> 
> -----------------
> 
> At least the AbstractWebModuleBuilder is going to need to look at the 
> security annotations.  I think the same ClassFinder that the 
> NamingBuilders use would work for this.  We probably want to stash it in 
> the Module so it can be used whenever necessary.
> 
> I just started looking at this annotation stuff recently so it's 
> entirely possible I missed the boat  completely.... don't be shy about 
> letting me know :-)
> 
> thanks
> david jencks
> 
> 
> 
> On Feb 16, 2007, at 8:59 PM, Tim McConnell wrote:
> 
>> 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
>>>>>>
>>>>
> 
>