Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (hermes.apache.org: domain of david.blevins@visi.com
 designates 208.42.156.9 as permitted sender)
In-Reply-To: <457FCD9E.90001@webtide.com>
References: <FF99A2E2-7A79-4983-9EDA-96AFA2E662DF@yahoo.com>
 <DA20821A-9CBC-4806-B6D8-07C3332ADC59@visi.com>
 <A711C27F-E9AB-4A6A-8342-2F1DB903DA5E@yahoo.com>
 <6D8B611B-1E70-4FC2-9DA5-02BC78305E2D@visi.com>
 <9AC18097-FAF6-4874-A7DA-FB61674025EE@visi.com> <457FCD9E.90001@webtide.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <293C35B8-35BB-49AC-98CB-15697C96A6DD@visi.com>
Cc: Jan Bartel <janb@mortbay.com>
Content-Transfer-Encoding: 7bit
From: David Blevins <david.blevins@visi.com>
Subject: Re: Annotation processing
Date: Fri, 15 Dec 2006 11:19:31 -0800
To: dev@geronimo.apache.org


On Dec 13, 2006, at 1:53 AM, Greg Wilkins wrote:

> David Blevins wrote:
>>
>> I took a quick look at Jetty and Tomcat source.  Tomcat has some
>> complete looking code for injection via JNDI, except it seems it only
>> supports using annotations as the source of injection data,  
>> nothing for
>> xml as the source.
>>
>> http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/ 
>> catalina/util/DefaultAnnotationProcessor.java?view=markup
>>
>>
>> Jetty doesn't seem to have anything in this area.  I looked for any
>> references to javax.annotation and didn't find any.  Greg, any  
>> thoughts
>> on what your plans are in this area?
>
> Jan,
>
> any thoughts on what your plans are in this area?
>
> ...
>
> We do plan to support this, but it is rather painful and
> intrusive to do.     The injecting the resources is not the problem
> it is finding them that is an issue.   It appears that we must
> get more involved in the classloading to find which classes should
> be scanned for annotations.  The code I have seen for this has
> hacky special cases of jar not to scan etc etc.

I made xbean-finder's ClassFinder for exactly this purpose. It uses  
ASM to introspect the classes for annotations as opposed to  
reflection avoiding the security issues that would associated with  
loading each and every class looking for annotations.

http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder/src/ 
test/java/org/apache/xbean/finder/ClassFinderTest.java

Here's a good thread to give a quick read: http://mail- 
archives.apache.org/mod_mbox/geronimo-xbean-dev/200610.mbox/% 
3c6C2C4FB8-25E4-4B94-923F-33C778664784@visi.com%3e

With it you can search:

  1.  A classloader, excluding any parent classloader if you wish
  2.  A set of URLs (var args... so one to many)
  3.  A set of Classes (also var args, so one or many)

> So what we hope to provide is a mechanism to inject
> (this should be done shortly) and a pluggable mechanism
> for discovery of annotations.  We will have our own simple
> implementation, but ideally the integration with geronimo would share
> the scanning that would be occurring for EJB3 etc. etc.

For the injection, we use xbean-reflect, which Dain created and I've  
hacked on a bit to do field and private injection.

Here's an example of how we use it to do JNDI-based injection (sans  
exception handling for brevity):

             ObjectRecipe objectRecipe = new ObjectRecipe(beanClass);
             objectRecipe.allow(Option.FIELD_INJECTION);
             objectRecipe.allow(Option.PRIVATE_PROPERTIES);
             objectRecipe.allow(Option.IGNORE_MISSING_PROPERTIES);

             javax.naming.Context ctx = deploymentInfo.getJndiEnc();
             for (Injection injection : deploymentInfo.getInjections 
()) {
                 String jndiName = injection.getJndiName();
                  Object object = ctx.lookup("java:comp/env/" +  
jndiName);
                  objectRecipe.setProperty(injection.getName(), new  
StaticRecipe(object));
             }

             objectRecipe.setProperty("sessionContext", new  
StaticRecipe(createSessionContext()));

             bean = objectRecipe.create(beanClass.getClassLoader());


Note that the objectRecipe also has methods like setFieldProperty and  
setMethodProperty that allow you be more specific on where the data  
should go (field vs setter).  The default when using the plain  
setProperty when Option.FIELD_INJECTION is enabled is to first look  
for a setter then to look for a field.

-David