On 08/03/2012 20:10, David Wahler wrote:
> On Thu, Mar 8, 2012 at 1:59 PM, Mark Thomas <ma...@apache.org> wrote:
>> There is no way you compiled an application that uses
>> javax.annotation.Resource against the Servlet 2.4 / Java EE 1.4 API. If
>> you try that you'll get an error.
> 
> As I said, javax.annotation.Resource is included with J2SE 6 (as
> specified in JSR-250, "Common Annotations for the Java(tm) Platform").
> 
> http://docs.oracle.com/javase/6/docs/api/javax/annotation/Resource.html
> 
> So the code I posted compiles just fine under Java 6 with the Tomcat 5.5 APIs.

Sorry, I had missed that someone in their infinite wisdom decided to
move classes from JavaEE to JavaSE. That is certainly a recipe for a
screw-up.

Looking at the JavaSE 6 Javadoc it refers to containers everywhere which
suggests to me that this should have stayed in the JavaEE space since
the concept of a container is very much a JavaEE concept. Unfortunately,
that genie can't be put back in the bottle.

This changes my analysis but not the end result. Behaviour of those
JavaSE language features are undefined in Servlet 2.4 since they didn't
exist when it was written. Reading the JavaSE 6 javadoc certainly
suggests that they should be processed. On the other hand, from a
Servlet spec point of view they weren't introduced until 2.5. I could
construct an argument to do either. Given that not processing them is
going to be very messy, I don't see the Tomcat code changing.

Returning to an earlier point, if you want to write a 2.4 web
application and be sure that that is what you have, then you really need
to make sure that is compiles against JavaEE 1.4 using Java 1.4. That
doesn't have to be your standard build environment but it should
probably be a CI test somewhere.

Mark

>> If you compile against a later API, claim to use an older API and then
>> run on a container that supports the later API then you should expect
>> some odd behaviour and that is exactly what you got. Tomcat is never
>> going to add the necessary checking to prevent this because of the
>> overhead it adds to fix what is a build time issue.
> 
> Fair enough.
> 
> Thanks,
> -- David
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to