> -----Original Message----- > From: Chris gokey [mailto:cgokey@;gcmd.nasa.gov] > Sent: Tuesday, November 05, 2002 9:25 AM > To: 'Tomcat Users List' > Subject: RE: Tomcat and CLASSPATH > > > Thanks Justin. Yes, I think you understand me correctly. I > think the > easiest way to handle a problem like this is for Tomcat to provide > something > in WEB-INF/web.xml that would let me specify a external classpath > outside of the WEB-INF directory. These classes would only be loaded > ONLY for this webapp :)
Since the servlet spec defines the web.xml, this would violate the spec, so don't expect it soon. You could send your comments to the servlet spec team for the 2.4 spec that is now being discussed(reviewed?). also note that you wouldn't be able to build a war if jars are located in other places. > Until then, I think, maybe I'll > figure out Ant > and see if it can > help with some of the housekeeping regarding keeping Tomcat's codebase > up to date whenever things change in the main codebase. But, there is > something about the idea of redundant files exiting on the > same machine > in two difference places that I don't like... > though not ideal, this is your best option. Also remember that you have the source, so you can extend WebAppClassLoader.java if you wish. Charlie > Thanks, > Chris > > > -----Original Message----- > > From: tomcat-user-return-40065- > > [EMAIL PROTECTED] > [mailto:tomcat-user-return- > > [EMAIL PROTECTED]] On Behalf Of > Justin > > Ruthenbeck > > Sent: Monday, November 04, 2002 7:21 PM > > To: Tomcat Users List > > Subject: RE: Tomcat and CLASSPATH > > > > > > Ahh... so (if I read this correctly), you've got your application > always > > installed on a system in a certain directory structure that is > independent > > of Tomcat. Then there's some element that is a web application that > some > > clients get/activate. You want to keep all your stuff together and > > optionally install Tomcat and run the webapp from the location you > > installed to. At least in essence, is this close? > > > > If so, then I see the advantage during deployment of > modifying Tomcat > to > > point to some external directory for resources. Depending > on the way > your > > app is organized (and how much you may be able to change that), your > other > > option is to define the docbase of your context (and the > root context) > to > > point somewhere other than the webapps directory it points at by > default - > > - > > there are caveats to that depending on the version you're using. > You'll > > still have problems in that J2EE mandates the whole WEB-INF/* > directory > > structure, but you can probably massage things into place > without too > much > > cross-pollination. I think this addresses what was, once > upon a time, > > your > > original question. :) > > > > justin > > > > > > At 03:28 PM 11/4/2002, you wrote: > > > > >Hi Justin. > > > > > >Thanks for your response. > > > > > >I'm not suggesting that Tomcat should be started up with > some type of > > >global classpath, rather I'm suggesting that the > applications context > > >for retrieving it classes does not necessarily need to be in > > >WEB-INF/classes and WEB-INF/lib. Instead, why not specify the > location > > >for where it gathers its classes from WEB-INF/web.xml (atleast as a > > >third option.) [and only for that context, it isn't a > global web.xml] > > > > > >We package multiple versions of our software, some which is shipped > with > > >Tomcat and some not.. So for those applications, it would > be nice to > > >have one place where classes reside and if we package it > with Tomcat, > > >then that web.xml just points to where our classes reside. > By having > > >our java sources compiled directly to Jakarta-tomcat sort > of couples > the > > >two a little more closely than we'd like. That is the > reason why we > are > > >forced to copy files now. > > > > > >Chris > > > > > > > For simple applications in development, you're right -- there is > no > > > > technical roadblack that prevents you from comingling > your source > and > > > > compiled classes, modifying Tomcat's classpath so that > the default > > > > classloader finds them, and running your app. However, > no one (or > > >very > > > > few) do this because > > > > > > > > (1) it's more complicated than compiling your classes > directly to > > > > WEB-INF/classes, > > > > (2) deploying, versioning, and managing such a setup, especially > once > > >you > > > > inevitably introduce multiple webapps, would be a collossal > nightmare, > > >and > > > > perhaps most importantly > > > > (3) running each webapp in its own classloader (it > classes loaded > from > > > > WEB-INF/classes) allows Tomcat to manage that application > > >independently -- > > > > for developers that means redeploying the application without > > >restarting > > > > the server to catch changes that are made. > > > > > > > > Unless you have some overwhelming reason to sidestep this, I'd > suggest > > > > separating your source and compiled classes, using the > directories > as > > > > intended, and -- especially if this is a commercial project -- > using > > >Ant > > > > to > > > > do all of the above. > > > > > > > > (And if you do see a reason otherwise, I'd love to hear it!) :) > > > > > > > > justin > > > > > > > > > > > > At 02:21 PM 11/4/2002, you wrote: > > > > >Consider you have a package structure: > > > > > > > > > >com.xyz.clients (/home/jdoe/java/src/com/xyz/client) > > > > >com.xyz.server (/home/jdoe/java/src/com/xyz/server) > > > > >com.xyz.util (/home/jdoe/java/src/com/xyz/util) > > > > > > > > > >Suppose you wanted to compile all these packages. > Where would you > > >direct > > > > >the output of the generated classes after > compiliation? In order > for > > > > >your Tomcat web application to be able to use the com.xyz.util > > >classes > > > > >they need to be either copied to WEB-INF/classes or > your compiler > > >needs > > > > >to generate them and put them their right? > > > > > > > > > >Currently, we have the complier place the .class files with the > > > > >packages. So, if we want to make them available to Tomcat, we > would > > > > >have to copy them to Tomcat's WEB-INF directory. If > Tomcat would > let > > >us > > > > >point our classpath to /home/jdoe/java/src then that step would > be > > > > >unnecessary. It seems that I'm missing something > rather obvious > from > > > > >your answers.. :) > > > > > > > > > >Chris > > > > > > -- > > To unsubscribe, e-mail: <mailto:tomcat-user- > > [EMAIL PROTECTED]> > > For additional commands, e-mail: <mailto:tomcat-user- > > [EMAIL PROTECTED]> > > > > > -- > To unsubscribe, e-mail: <mailto:tomcat-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org> -- To unsubscribe, e-mail: <mailto:tomcat-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org>
