Tomcat 6 + XML/Annotation injection

[bill.burke]

Had a short IM talk with Remy. He pointed me here to their annotation processing:

https://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/org/apache/catalina/util/AnnotationProcessor.java

Remy, this approach won't work in a JBoss environment:

1) Although it doesn't necessarily need to do the injection, JBoss needs enough information to populate the ENC. This metadata should not require an additional, jboss specific XML deployment descriptor (it doesn't in EJB3 land).

2) Related to point #1, JSPs are deployed on the fly. JBoss would need a callback so that it could populate the appropriate ENC entries so that injection could happen.

What I think is needed here is that JBoss needs to be told what classes are possibly injectable before instances of these classes are instantiated so that it can populate the ENC. I don't think a pointer to the XML metadata is needed as the JBoss Deployer will already have it parsed.

IMO, I'd prefer a pluggable SPI where Tomcat's servlet instance construction could be totally overridable so that app servers like JBoss can handle injection and even provide their own pluggable proprietary injection annotations and/or XML injection metadata.

Bill

[rmaucher]

There is another equivalent class for Jasper:
https://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/org/apache/jasper/runtime/AnnotationProcessor.java

[starksm64]

I would like to see a new non-jmx deployment model that parsed the web.xml and then had a callout to allow for agumentation of this as well as more control for better integration. Both the webservice layer and portal are having to tweak the web deployment to integrate their services today.

[bill.burke]

Ok, i've gotten Tomcat 6 to run on JBoss 5 with some minor changes (didn't run testsuite though). I do have some concerns though:

* in org.apache.catalina.startup.WebAnnotationsSet the loadApplicationServletAnnoations was throwing a NullPointerException because wrapper.getServletClass() was returning null. I just put a if/null/return check and the jmx-console seemed to work.

* Since I'm heading into this totally blind, it would be cool if I could get some preliminary advice/pointers on how Tomcat6 and Tomat5 integration are different and any specific issues of reusing the same Tomcat5 JBoss integration codebase/config/etc... I guess getting the testsuite to run would be a good starting point.

* Finally, I've started to look at how to integrate the annotation processing. My idea is to turn the Tomcat6 AnnotationProcessor into an interface and JBoss overrides this interface. I'm digging around a bit and the best way I could see so far of overriding the implementation of this would be to put a setter method on StandardContext so that JBoss could allocate an instance of an AnnotationProcessor. Please let me know if there is a better way.

Thanks.

[starksm64]

I don't see that there has been any integration work done for tomcat6 in jboss-head. The build is still pulling in 5.5.17. What I want to do is either redo the catalina bootstrap code to drop the jmx/digester requirement or write a new one for jboss.

[anil.saldhana]

I don't see that there has been any integration work done for tomcat6 in jboss-head. The build is still pulling in 5.5.17. What I want to do is either redo the catalina bootstrap code to drop the jmx/digester requirement or write a new one for jboss.

When is this integration supposed to happen?

[rmaucher]

Ok, i've gotten Tomcat 6 to run on JBoss 5 with some minor changes (didn't run testsuite though). I do have some concerns though:

* in org.apache.catalina.startup.WebAnnotationsSet the loadApplicationServletAnnoations was throwing a NullPointerException because wrapper.getServletClass() was returning null. I just put a if/null/return check and the jmx-console seemed to work.

* Since I'm heading into this totally blind, it would be cool if I could get some preliminary advice/pointers on how Tomcat6 and Tomat5 integration are different and any specific issues of reusing the same Tomcat5 JBoss integration codebase/config/etc... I guess getting the testsuite to run would be a good starting point.

* Finally, I've started to look at how to integrate the annotation processing. My idea is to turn the Tomcat6 AnnotationProcessor into an interface and JBoss overrides this interface. I'm digging around a bit and the best way I could see so far of overriding the implementation of this would be to put a setter method on StandardContext so that JBoss could allocate an instance of an AnnotationProcessor. Please let me know if there is a better way.

Thanks.

* I think it's ok for certain wrappers to not have classes at this point (JSP files, maybe), so I'll add a null check.

* Tomcat 6 is the same as Tomcat 5.5 at this point. Nothing needs to change in the integration code right now.

* Although you didn't understand me, what I was proposing was to make the class non static, so either a regular class that has to be overriden, or if you really want it an interface.

[starksm64]

I don't see that there has been any integration work done for tomcat6 in jboss-head. The build is still pulling in 5.5.17. What I want to do is either redo the catalina bootstrap code to drop the jmx/digester requirement or write a new one for jboss.

When is this integration supposed to happen?

Soon. There are several issues to coordinate:
- The javaee5 stuff Bill is trying to get working
- The jsf 1.2 stuff Stan is working on
- Just updating to tomcat6 in head
- Pojoification of the integration layer. This has the lowest priority as we should just get javaee5 features working before doing this, and its going to depend on the jboss5 virtual deployment layer anyway.

[bill.burke]

I don't see that there has been any integration work done for tomcat6 in jboss-head. The build is still pulling in 5.5.17. What I want to do is either redo the catalina bootstrap code to drop the jmx/digester requirement or write a new one for jboss.

That's because I haven't committed anything yet!

Will redo after upgrade to TC6 as well as javaee5 shit is done.

[bill.burke]

* I think it's ok for certain wrappers to not have classes at this point (JSP files, maybe), so I'll add a null check.

* Tomcat 6 is the same as Tomcat 5.5 at this point. Nothing needs to change in the integration code right now.

Hope it stays that way for awhile at least. I did notice that some of the catalina-management.jar and tomcat-util.jar stuff was missing from the TC6 build I did.

* Although you didn't understand me, what I was proposing was to make the class non static, so either a regular class that has to be overriden, or if you really want it an interface.

interface is always best. You didn't answer my other question though. What is the best way to plug in this interface? Through the StandardContext class? I'd like it to be plugged in on a per-deployment basis as I will need to do processing of annotations to set up the ENC properly.

[anil.saldhana]

- Just updating to tomcat6 in head

We should this at the earliest to capture integration issues across all the layers.

[rmaucher]

* I think it's ok for certain wrappers to not have classes at this point (JSP files, maybe), so I'll add a null check.

* Tomcat 6 is the same as Tomcat 5.5 at this point. Nothing needs to change in the integration code right now.

Hope it stays that way for awhile at least. I did notice that some of the catalina-management.jar and tomcat-util.jar stuff was missing from the TC6 build I did.

* Although you didn't understand me, what I was proposing was to make the class non static, so either a regular class that has to be overriden, or if you really want it an interface.

interface is always best. You didn't answer my other question though. What is the best way to plug in this interface? Through the StandardContext class? I'd like it to be plugged in on a per-deployment basis as I will need to do processing of annotations to set up the ENC properly.

Yes, I was planning to use a field in the StandardContext class.

About the JARs missing, I didn't port the manager webapp (but it's the same) and the other JAR is replaced with tomcat-coyote.jar.

[bill.burke]

* I think it's ok for certain wrappers to not have classes at this point (JSP files, maybe), so I'll add a null check.

* Tomcat 6 is the same as Tomcat 5.5 at this point. Nothing needs to change in the integration code right now.

Hope it stays that way for awhile at least. I did notice that some of the catalina-management.jar and tomcat-util.jar stuff was missing from the TC6 build I did.

* Although you didn't understand me, what I was proposing was to make the class non static, so either a regular class that has to be overriden, or if you really want it an interface.

interface is always best. You didn't answer my other question though. What is the best way to plug in this interface? Through the StandardContext class? I'd like it to be plugged in on a per-deployment basis as I will need to do processing of annotations to set up the ENC properly.

Yes, I was planning to use a field in the StandardContext class.

I am working on this now. Is it ok if I do this work and forward you the changes? I may need other integration points too or a different API, not absolutely sure yet. I need to prototype, although I have a pretty good idea.

About the JARs missing, I didn't port the manager webapp (but it's the same) and the other JAR is replaced with tomcat-coyote.jar.

There was one utility class that was missing that was in tomcat-util.jar. I'll get back to you on that.

Bill

[bill.burke]

- Just updating to tomcat6 in head

We should this at the earliest to capture integration issues across all the layers.

Next week sometime it will be in.