Re: Annotation processing

[Tim McConnell]

Hi David, what is this ASM acronym that you refer to below ??

David Blevins wrote:

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/[EMAIL PROTECTED]

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

--
Thanks,
Tim McConnell