Making Creators declare supported annotation types

[alesj]

Is there a way that we could add additional information to the Creators used in AnnotationMetaDataDeployer,
getting the annotation types they are able to handle.

This would help with the performance when using my AltAnnotationMetaDataDeployer (GenericAnnotationDeployer),
since we would only pass-in the classes that contain at least one of creator's supported annotation.

The rest of the Creator's logic would remain the same,
it's just the amount of classes that they scan that's gonna be a lot smaller.

And the resources path matching is done at the right place,
classloading + VFS level, no need for the likes of AnnotatedClassFilter.

[starksm64]

The complete set of annotations for a given creator are spread out over many different Processor implementations. If the Processor interface had a getAnnotationTypes accessor returning the set of annotation classes it handles, we should be able to propagate this info up to the creator.

[alesj]

OK, I'll get Emanuel to do it. :-)

[emuckenhuber]

Okay, so far i've added the getAnnotationTypes and return the processed annotation(s), for each processor..

Furthmore i added:

public interface AnnotationContext
{
 Collection<Class<? extends Annotation>> getTypeAnnotations();
 Collection<Class<? extends Annotation>> getMethodAnnotations();
 Collection<Class<? extends Annotation>> getFieldAnnotations();
}

Which represents the set of annotations for each Creator...
e.g. the EjbJar30Creator would return @Statful, @Stateless and @MesageDriven as TypeAnnotation and null for Method and Field annotations.

Any further ideas / comments ?

[skajotde]

"emuckenhuber" wrote:
and null for Method and Field annotations.

Any further ideas / comments ?

Technical remark ;) Preferred way (by me and described in Effective Java) is to return always collections, empty or not emty instead of null ;)

http://java.sun.com/j2se/1.5.0/docs/api/java/util/Collections.html#EMPTY_LIST]Java 5 Collections#EMPTY_LIST

[skajotde]

sigh, handling links is broken in this forum on firefox (2.0, 3.0). It's correct link: http://java.sun.com/j2se/1.5.0/docs/api/java/util/Collections.html#EMPTY_LIST

[emuckenhuber]

"skajotde" wrote:

Technical remark ;) Preferred way (by me and described in Effective Java) is to return always collections, empty or not emty instead of null ;)

Hehe, actually i meant 'nothing' by saying null. Though i preferred EMPTY_SET for whatever reason ;-)

[skajotde]

"emuckenhuber" wrote:

Hehe, actually i meant 'nothing' by saying null. Though i preferred EMPTY_SET for whatever reason ;-)

ok ;) You know when null will appear in javadoc then api users will make unnecessary checks to null.

[alesj]

"emuckenhuber" wrote:

Which represents the set of annotations for each Creator...
e.g. the EjbJar30Creator would return @Statful, @Stateless and @MesageDriven as TypeAnnotation and null for Method and Field annotations.

Currently JBoss50Creator returns just this:

2008-07-30 19:55:50,468 TRACE [org.jboss.deployment.OptAnnotationMetaDataDeployer] (RMI TCP Connection(4)-127.0.0.1) Creator: org.jboss.metadata.annotation.creator.ejb.jboss.JBoss50Creator@b9fa3b, type annotations: [interface org.jboss.ejb3.annotation.Consumer, interface javax.ejb.Stateless, interface javax.ejb.MessageDriven, interface javax.ejb.Stateful, interface javax.ejb.ApplicationException, interface org.jboss.ejb3.annotation.Service]

which I think is not enough, e.g. missing @Local for local business interfaces.

[alesj]

Aha, and I saw that I'm not getting @Entity marked classes back either.

e.g. running Seam Booking example:

2008-07-30 17:17:31,625 TRACE [org.jboss.deployment.OptAnnotationMetaDataDeployer] (RMI TCP Connection(4)-127.0.0.1) Annotated classes [AbstractVFSDeploymentContext@22869899{vfszip:/C:/projects/jboss5/trunk/testsuite/output/lib/jboss-seam-booking.ear}, org.jboss.metadata.annotation.creator.ejb.jboss.JBoss50Creator@78049b]:

org.jboss.seam.example.booking.AuthenticatorAction,
org.jboss.seam.example.booking.BookingListAction,
org.jboss.seam.example.booking.ChangePasswordAction,
org.jboss.seam.example.booking.HotelBookingAction,
org.jboss.seam.example.booking.HotelSearchingAction,
org.jboss.seam.example.booking.RegisterAction,

org.jboss.seam.async.TimerServiceDispatcher,
org.jboss.seam.transaction.EjbSynchronizations,

org.jboss.seam.framework.EntityNotFoundException,
org.jboss.seam.security.AuthorizationException,
org.jboss.seam.security.NotLoggedInException]

[emuckenhuber]

"alesj" wrote:

which I think is not enough, e.g. missing @Local for local business interfaces.

Well yes and no :)
Basically the JBoss50Creator exposes just the annotation which are really needed to check.
e.g. if there is no @Stateless annotation then we won't create meta data for a SessionBean anyway and therefore a class with just @Local can be ignored.
That's also why JBoss50Creator does not return anything for Method and Field annotations.

Furthermore the processors get the superclasses and interfaces of the class themself. So there is no need to check that either.

[emuckenhuber]

"alesj" wrote:
Aha, and I saw that I'm not getting @Entity marked classes back either.

Yep, those does not need to be processed... That's part of the jpa-deployer (as far as i know :)