3 Replies Latest reply on Sep 14, 2009 5:45 AM by rmaucher

Servlet 3.0 annotation processing requirements

rmaucher Sep 7, 2009 3:09 PM

Servlet 3.0 defines new annotations to declare and map servlet, filters, etc. Nothing very unusual there, the annotated classes have to be found and that's it.

However, there are also some more exotic requirements. Two main items: the descriptors define a JAR processing order, and another feature requires finding a set of classes.

a) Per JAR annotation scanning. Due to the fact that the order impacts
annotations, the deployer should produce a set of attachements keyed by
JAR name for web annotations (like what happens for the web fragments,
so that way I can merge the fragment metadata for a given jar, then
merge the annotation metadata, then move to the next jar in the order).

b) The ServletContainerInitializer feature. I have no idea how to handle
the @HandlesTypes annotation (reminder: the annotation contains a list
of classes, and I need to build a set of Class that are in the webapp
that implment, extend, or are annotated by any item in the list of
classes).

Thanks.

1. Re: Servlet 3.0 annotation processing requirements

rmaucher Sep 8, 2009 6:37 AM (in response to rmaucher)

c) The access control annotations were added to Servlet 3.0, and classes that extend HttpServlet can have these annotations as method level annotations (on doGet, doPost, etc; actually all the doXXX methods defined in HttpServlet).
Actions
2. Re: Servlet 3.0 annotation processing requirements

alesj Sep 10, 2009 11:40 AM (in response to rmaucher)

"remy.maucherat@jboss.com" wrote:

a) Per JAR annotation scanning. Due to the fact that the order impacts
annotations, the deployer should produce a set of attachements keyed by
JAR name for web annotations (like what happens for the web fragments,
so that way I can merge the fragment metadata for a given jar, then
merge the annotation metadata, then move to the next jar in the order).

This one doesn't look hard to do.
As we do deployer per all deployment units.
Meaning all you need to do is create 2 new deployers:
* one that would collect the fragment info
* the second one that would apply it

"remy.maucherat@jboss.com" wrote:

b) The ServletContainerInitializer feature. I have no idea how to handle
the @HandlesTypes annotation (reminder: the annotation contains a list
of classes, and I need to build a set of Class that are in the webapp
that implment, extend, or are annotated by any item in the list of
classes).

Yeah, this one sounds pita. Another performance bottleneck on the horizon.

I see 3 ways of doing this:
* part of generic scanning (== preparing info for any resource); hence only a single scan
* on-demand checking (+ some caching); can be done now, but it's slow
* another new Jesper's Papaki project for class info (need to check if this could be part of Reflect)

"remy.maucherat@jboss.com" wrote:

c) The access control annotations were added to Servlet 3.0, and classes that extend HttpServlet can have these annotations as method level annotations (on doGet, doPost, etc; actually all the doXXX methods defined in HttpServlet).

Easy. Simple AnnotationEnv usage.
Actions
3. Re: Servlet 3.0 annotation processing requirements

rmaucher Sep 14, 2009 5:45 AM (in response to rmaucher)

"alesj" wrote:
"remy.maucherat@jboss.com" wrote:

a) Per JAR annotation scanning. Due to the fact that the order impacts
annotations, the deployer should produce a set of attachements keyed by
JAR name for web annotations (like what happens for the web fragments,
so that way I can merge the fragment metadata for a given jar, then
merge the annotation metadata, then move to the next jar in the order).

This one doesn't look hard to do.
As we do deployer per all deployment units.
Meaning all you need to do is create 2 new deployers:
* one that would collect the fragment info
* the second one that would apply it

I am doing the fragment merging in MergedJBossWebMetaDataDeployer. However, I don't see any annotation meta data keyed per jar at the moment ;) I think I could use a hand there.

"alesj" wrote:

"remy.maucherat@jboss.com" wrote:

b) The ServletContainerInitializer feature. I have no idea how to handle
the @HandlesTypes annotation (reminder: the annotation contains a list
of classes, and I need to build a set of Class that are in the webapp
that implment, extend, or are annotated by any item in the list of
classes).

Yeah, this one sounds pita. Another performance bottleneck on the horizon.

I see 3 ways of doing this:
* part of generic scanning (== preparing info for any resource); hence only a single scan
* on-demand checking (+ some caching); can be done now, but it's slow
* another new Jesper's Papaki project for class info (need to check if this could be part of Reflect)

I am in complete agreement that HandlesTypes is the biggest Servlet 3.0 issue. Since a scan is already done somewhere, it's probably best for speed if it can also handle the HandlesTypes requirement. I don't know if the first or third option would work best here though.

That feature is designed for things like easy webservices integration.

"alesj" wrote:

"remy.maucherat@jboss.com" wrote:

c) The access control annotations were added to Servlet 3.0, and classes that extend HttpServlet can have these annotations as method level annotations (on doGet, doPost, etc; actually all the doXXX methods defined in HttpServlet).

Easy. Simple AnnotationEnv usage.

Hum, ok. I could use some help too. My question could be if I should continue using the current stuff. There is the AnnotationMetaDataDeployer, which uses a creator from the metadata-web project. This could be extended, but Alexey told me to not touch it, since this was dead stuff. So I'm totally confused.

This is far less urgent than item a). At the moment, Catalina processes these annotations just fine.
Actions

Go to original post