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 :) 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...
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>
