Re: Barracuda and using Servlet 2.3 features?

At 11:47 AM 4/15/2003 +0200, you wrote:
>Hi,
>
>>Just wondering how important Servlet 2.2 compatibility is for everyone 
>>using Barracuda?
>
>I think we use 2.3, but I would like to remain compatible as long as this 
>doesn't mean we have introduce mayor workarounds.

I figure that the servlet 2.4 spec is already in proposed final draft and 
Tomcat 5, which implements the 2.4 spec, is already quite usable, although 
not yet an official release.  We've actually had the 2.3 stuff officially 
since Sept. 17th 2001 when Tomcat 4.0 was officially released.  We are now 
well into 2003 and I think there is a pretty darned good argument to make 
for going forward with the 2.3 spec as some major features were added which 
Barracuda could benefit from.  Servlet 2.4 will actually be more of an 
incremental release, merely building upon servlet 2.3, whereas servlet 2.3 
added major features over servlet 2.2.  We already use some 2.3 features 
such as the log4j servlet context listener, but that can be disabled by 
removing it from the web.xml and there is an alternative of using the plain 
servlet version of the log4j initializer.  There are other things such as 
servlet filters, however, that Barracuda could very much benefit from which 
have no real replacement except, of course, for the event model which does 
help to some degree in this area.  However it is not a full replacement.  I 
think we should just bite the bullet and make the move.

>>The current way of loading multiple event gateway xml files uses File IO 
>>and, therefore, is very sensitive to how the app is deployed.  It must be 
>>deployed as a directory or else things break.  This is why File IO should 
>>*never* be used within a web application, much less a framework for use 
>>within web applications.  Of course the current way benefits from the 
>>fact that it doesn't require support for servlet 2.3, only servlet 2.2.
>
>I'm not deep into these subjects - but for such cases, we use 
>ClassLoader.getResourceAsStream. This works always, in jars/wars as well 
>as in the file-system.

Sure, that is one of the mechanisms the current DefaultApplicationAssembler 
uses.  Actually, it first tries context.getResourceAsStream() to load a 
resource.  However, what I am talking about is an enhancement which allows 
us to load multiple event gateway configuration files, not just one.  The 
idea comes from something that, I believe, Kirk Daries implemented which 
allows multiple event gateway files to be loaded.  However, it uses File 
IO, so it doesn't work unless the app is served off the file system and not 
directly from a .war file.  This makes the mechanism much less 
portable.  As a rule, webapps should never access the file system directly 
other than the guaranteed temp dir provided by the servlet spec.

What the servlet 2.3 method context.getResourcePaths() allows for is a way 
to get the paths to multiple resources in a directory relative to the 
webapp (whether in an archive or on the file system).  The set of resources 
can then be iterated, checking each resource against a given pattern, and 
be loaded to an input stream via context.getResourceAsStream() just like 
normal.  This keeps Kirk's functionality while being perfectly 
portable.  It will run under any servlet 2.3 compliant engine regardless of 
how it is deployed.

That said, I saw Kirk's comments mentioning that we might be able to use 
reflection to figure out whether the servlet engine supports servlet 2.3 
and then use getResourcePaths() only if it is supported.  In that case, 
servlet 2.2 containers would be limited to loading a single event gateway 
config file while servlet 2.3 containers would enjoy the benefits of 
loading multiple event gateway config files.  That is certainly a 
possibility, but doesn't address other concerns of the move to servlet 
2.3.  If it is ultimately determined that we need to keep servlet 2.2 
compatibility for now, then we can do this, but I'd like to have an idea 
when we are going to make the full leap to servlet 2.3; in a 1/2 year, 1 
year, 2 years?  Maybe just the next release would be reasonable to keep 
servlet 2.2 compatibility?  We need to move on at some point and 
workarounds using reflection won't work for everything and they make the 
code unnecessarily messy.

Anyway, that's my $0.02

Jake


>Regards,
>Diez
>
>_______________________________________________
>Barracuda mailing list
>[email protected]
>http://barracudamvc.org/lists/listinfo/barracuda