Hi there,
I'm working on a project to facilitate checking deployed applications
using different embedded containers, so I was quite interested seeing
Sebastien Dionne's blog entry about the ServletAutoDeployer and the
GrizzlyWebServerDeployer
(
http://weblogs.java.net/blog/survivant/archive/2009/04/grizzlywebserve.html).
So, I thought it might be nice to add Grizzly to the list of supported
containers :).Looking at the other implementations and what one
usually needs, the usual requirements that I ask are: Being able to
set the port, the directory where the application is deployed, the
context name, some way of adding extra classpath for the container.
Why the extra classpath? Because when I want to test an application
under different containers, I want my application to include only the
libraries that are really required, and not the ones that are usually
included by the container itself, and different containers include
different libraries. For example in order to create a DataSource,
Tomcat requires a couple of jakarta libraries, while Jetty can use
C3P0. So, I don't want to bundle all those .jar files in my
WEB-INF/lib and I might not know at deploy time all the jars that
might end up being used, hence the need to add an "extra classpath"
that plays the role of lib or common/lib in some containers.
I think thats the only feature missing from the
GrizzlyWebServerDeployer to be able to use it.
I already have implementations for Jetty and Tomcat, while Resin and
GlassFish are "in the works" due to issues in their embedded
components.
The project is hosted here:
http://kenai.com/projects/wembed/pages/Home in case someone wants to
see what I mean. I'm already using it in some projects, but I'm still
working a bit on the documentation and facilitating reusability before
issuing the first official release.
Cheers,
D.