OK - let me just think this through out loud (Makefiles and EMACS at the
ready):
For my own development space, I'm putting "system" stuff (the JDK classes,
the JSDK classes, JDBC) into wrapper.classpath, and everything else sits in
a servlet zone with autoload turned on.
An obvious question arises: for actual deployment, why not just turn off
autoload and leave everything else as is (modulo path changes)?
Reason 1: if the zones are private, classes cannot be shared. (But private
zones are a different issue: one could argue for a single zone and just use
CVS to control deployment by different developers.)
Reason 2: one could subvert the server by writing
http://server/servlets/com.package.classname as a URL for classes which
aren't servlets. (This is ugly but probably benign - it's an argument that a
servlet zone should only contain non-abstract servlet subclasses.)
Having said that, I'm having a hard time coming up with a reason for pushing
stuff into the real classpath rather than just disabling autoloading in a
servlet zone. I suspect I'm missing something...
> -----Original Message-----
> I use pretty much the same organization -- JDK system classes, JDBC
> drivers,
> and all that kind of stuff are put on the system class path (with the
> wrapper.classpath setting), and all my classes are in zone repositories.
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
