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-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org>
