Embedded tomcat and classpath
I'm trying to embed tomcat 4.1.30 into another application and keep running into annoying classloader problems. Unfortunately, I can't assume that I have control over the host application's classpath. :( Here's what I've created: TomcatStarter.class: This class contains a setup() method that creates the tomcat Embedded object and sets up the host, context, and such. Obviously it has direct references to classes in the tomcat jars. TomcatWrapper.class: This class extends Thread and contains a main() method for instantiating and running the thread. The constructor sets the thread's contextClassLoader to be a URLClassLoader containing all of the Tomcat jar files. The run() method uses getContextClassLoader().loadClass(TomcatStarter) to create the tomcat starter. This decouples the Wrapper from the Starter so that the wrapper does not need to load any tomcat jars in order to run tomcat. If I run TomcatWrapper.main() and set the classpath on the command line to contain all of the Tomcat server/lib and common/lib jars, then it runs fine. I can access the configured contexts. This is good, but not quite what I need since I don't want to change the startup classpath. If I run TomcatWrapper.main() and leave off the tomcat jars from the classpath, then I can create the embedded tomcat, but I get an error when it runs (see exception trace below). The exception appears to indicate that the WebappClassLoader can't find jasper-compiler.jar in common/lib, even though it is available through the thread's contextClassLoader (I tested this by running loadClass(org.apache.jasper.servlet.JspServlet) on the contextClassLoader). Is it not possible to set tomcat's classpath using a thread's contextClassLoader()? Am I required to change the classpath of hte host application to run an embedded tomcat? --Wart javax.servlet.ServletException: Wrapper cannot find servlet class org.apache.jasper.servlet.JspServlet or a class it depends on at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:891) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:823) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3427) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3628) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)at org.apache.catalina.core.StandardHost.start(StandardHost.java:754) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:363) at org.apache.catalina.startup.Embedded.start(Embedded.java:994) at edu.caltech.hep.wart.ml.TomcatStarter.run(TomcatStarter.java:71) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at edu.caltech.hep.wart.ml.TomcatWrapper.run(TomcatWrapper.java:131) - Root Cause - java.lang.ClassNotFoundException: org.apache.jasper.servlet.JspServlet at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1443) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1289) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:885) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:823) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3427) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3628) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)at org.apache.catalina.core.StandardHost.start(StandardHost.java:754) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:363) at org.apache.catalina.startup.Embedded.start(Embedded.java:994) at edu.caltech.hep.wart.ml.TomcatStarter.run(TomcatStarter.java:71) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at edu.caltech.hep.wart.ml.TomcatWrapper.run(TomcatWrapper.java:131) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Embedded Tomcat and Classpath issues.
Hello, I have an application that has Tomcat embedded, running Xindice. I would like to start Tomcat when my application starts which works just fine if Tomcat jars are the only jars specified on the VM classpath. However I also need to have Xindice jars on the classpath since my application uses Xindice, through Tomcat. Is it possible to tell Tomcat to ignore the System classpath when starting? I think this would solve my problem. The problem seems to be that including Xindice jars on the classpath, so my application can use them, invalidates the jars that are in webapps for Xindice. Thanks Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat-4.1.18 Classpath Problems
Hi ! I've got some classpathproblems using Linux java full version 1.4.1_01-b01 16228 [main] ERROR server.JkMain - Can't create apr java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory at org.apache.jk.apr.AprImpl.clinit(AprImpl.java:340) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:140) at org.apache.jk.server.JkMain.newHandler(JkMain.java:556) at org.apache.jk.server.JkMain.start(JkMain.java:341) ... Other parts (other han AprImpl) are able to use the Tomcat FileLoger, they create log files for example catalina.out or localhost_DATE.txt only AprImpl has Problems with the logging. If one puts Putting log4j-1.2.7.jar into $CATALINA_HOME/common/lib gives the following exception: Exception during startup processing java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203) Caused by: java.lang.NoClassDefFoundError: org/apache/log4j/Layout at org.apache.commons.logging.impl.Log4jFactory.getInstance(Log4jFactory.java:153) at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:285) at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:409) at org.apache.commons.digester.Digester.init(Digester.java:345) at org.apache.catalina.startup.Catalina.createStartDigester(Catalina.java:280) at org.apache.catalina.startup.Catalina.start(Catalina.java:441) at org.apache.catalina.startup.Catalina.execute(Catalina.java:400) at org.apache.catalina.startup.Catalina.process(Catalina.java:180) ... 5 more Putting log4j-1.2.7.jar into $JAVA_HOME/jre/lib/ext seems to work fine. :-(( It seems to be a Classloader Problem any Ideas ? thanks andi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat-4.1.18 Classpath Problems
Hi ! I've got some classpathproblems using Linux java full version 1.4.1_01-b01 16228 [main] ERROR server.JkMain - Can't create apr java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory at org.apache.jk.apr.AprImpl.clinit(AprImpl.java:340) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:140) at org.apache.jk.server.JkMain.newHandler(JkMain.java:556) at org.apache.jk.server.JkMain.start(JkMain.java:341) ... Other parts (other han AprImpl) are able to use the Tomcat FileLoger, they create log files for example catalina.out or localhost_DATE.txt only AprImpl has Problems with the logging. If one puts Putting log4j-1.2.7.jar into $CATALINA_HOME/common/lib gives the following exception: Exception during startup processing java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203) Caused by: java.lang.NoClassDefFoundError: org/apache/log4j/Layout at org.apache.commons.logging.impl.Log4jFactory.getInstance(Log4jFactory.java:153) at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:285) at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:409) at org.apache.commons.digester.Digester.init(Digester.java:345) at org.apache.catalina.startup.Catalina.createStartDigester(Catalina.java:280) at org.apache.catalina.startup.Catalina.start(Catalina.java:441) at org.apache.catalina.startup.Catalina.execute(Catalina.java:400) at org.apache.catalina.startup.Catalina.process(Catalina.java:180) ... 5 more Putting log4j-1.2.7.jar into $JAVA_HOME/jre/lib/ext seems to work fine. :-(( It seems to be a Classloader Problem any Ideas ? thanks andi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat-4.1.18 Classpath Problems
I'm not sure exactly what the problem is, but I suspect it is a commons-logging problem. To avoid this, don't use commons-logging. You see very few bug reports like this for log4j stand-alone. So, use Log4j directly and you will have fewer headaches. Also see http://qos.ch/logging/thinkAgain.html Jake At 07:26 AM 2/13/2003 +0100, you wrote: Hi ! I've got some classpathproblems using Linux java full version 1.4.1_01-b01 16228 [main] ERROR server.JkMain - Can't create apr java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory at org.apache.jk.apr.AprImpl.clinit(AprImpl.java:340) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:140) at org.apache.jk.server.JkMain.newHandler(JkMain.java:556) at org.apache.jk.server.JkMain.start(JkMain.java:341) ... Other parts (other han AprImpl) are able to use the Tomcat FileLoger, they create log files for example catalina.out or localhost_DATE.txt only AprImpl has Problems with the logging. If one puts Putting log4j-1.2.7.jar into $CATALINA_HOME/common/lib gives the following exception: Exception during startup processing java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203) Caused by: java.lang.NoClassDefFoundError: org/apache/log4j/Layout at org.apache.commons.logging.impl.Log4jFactory.getInstance(Log4jFactory.java:153) at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:285) at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:409) at org.apache.commons.digester.Digester.init(Digester.java:345) at org.apache.catalina.startup.Catalina.createStartDigester(Catalina.java:280) at org.apache.catalina.startup.Catalina.start(Catalina.java:441) at org.apache.catalina.startup.Catalina.execute(Catalina.java:400) at org.apache.catalina.startup.Catalina.process(Catalina.java:180) ... 5 more Putting log4j-1.2.7.jar into $JAVA_HOME/jre/lib/ext seems to work fine. :-(( It seems to be a Classloader Problem any Ideas ? thanks andi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat and CLASSPATH
We have following reqirements: - each site can have a different version of a tool - many sites share the same vesion of the tool - a site may change the needed version of a tool - a site may replace a tool by a different one (switch from postgres to firebird) We have a setup like this: /usr/local/tool-a-v1/lib/toola.jar /usr/local/tool-a-v2/lib/toola.jar /usr/local/tool-a-v3/lib/toola.jar /usr/local/tool-b-v1/lib/toolb.jar /usr/local/tool-b-v2/lib/toolb.jar /www/online/www.site-a /www/online/www.site-b ... /www/online/www.site-z Currently we use jserv and gnujsp. jserv has the concept of repositories. The repositories are added by jserv to the internal classpath. We use the repositories to connect a site with the tools it needs. So it's very easy to change the versions of the tool or to replace the tool. Now to tomcat: Without linking we would have to copy the libraries into the tomcat directory structure for each site. With copying I see two disadvantages for us: - We would have several copies of the same libraries. Although disk space get cheaper, this is something that disturbs me (May be caused by the fact that my first hard disk had less space than a modern grafic card or handheld has memory: 40MB) - We loose the 'natural' information which version of the library we use in specific site. - If we would have to replace a version of a tool by a patched version, we could just replace the central file, now we have to copy this file to all instances that use this version. With linking the libraries we could solve both disadvantages for us. -Original Message- From: Turner, John [mailto:JTurner;AAS.com] Sent: Monday, November 04, 2002 5:39 PM To: 'Tomcat Users List' Subject: RE: Tomcat and CLASSPATH We don't use symbolic links. Everything is under Tomcat's directory tree. What is the advantage to using symbolic links or an external classpath? I'm not seeing what advantage you would get. -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
RE: Tomcat and CLASSPATH
Thanks for the response. My point is simply that the files have to reside _somewhere_, correct? So if they have to reside _somewhere_, they might as well reside in the structure intended for them. The act of putting them in location A vs. location B is exactly the same, only the destination is different. The rest is housekeeping, and in my mind, it makes more sense to write a housekeeping tool (or use a build/deploy tool) than it does to circumvent an intentional design. The only other problem is duplicates, as you pointed out, but again, that's housekeeping. As long as you know who/what has which file, the fact that there are two copies of the file is pretty irrelevant from a practical viewpoint. John -Original Message- From: Ralph Einfeldt [mailto:ralph.einfeldt;uptime-isc.de] Sent: Tuesday, November 05, 2002 4:29 AM To: Tomcat Users List Subject: RE: Tomcat and CLASSPATH We have following reqirements: - each site can have a different version of a tool - many sites share the same vesion of the tool - a site may change the needed version of a tool - a site may replace a tool by a different one (switch from postgres to firebird) We have a setup like this: /usr/local/tool-a-v1/lib/toola.jar /usr/local/tool-a-v2/lib/toola.jar /usr/local/tool-a-v3/lib/toola.jar /usr/local/tool-b-v1/lib/toolb.jar /usr/local/tool-b-v2/lib/toolb.jar /www/online/www.site-a /www/online/www.site-b ... /www/online/www.site-z Currently we use jserv and gnujsp. jserv has the concept of repositories. The repositories are added by jserv to the internal classpath. We use the repositories to connect a site with the tools it needs. So it's very easy to change the versions of the tool or to replace the tool. Now to tomcat: Without linking we would have to copy the libraries into the tomcat directory structure for each site. With copying I see two disadvantages for us: - We would have several copies of the same libraries. Although disk space get cheaper, this is something that disturbs me (May be caused by the fact that my first hard disk had less space than a modern grafic card or handheld has memory: 40MB) - We loose the 'natural' information which version of the library we use in specific site. - If we would have to replace a version of a tool by a patched version, we could just replace the central file, now we have to copy this file to all instances that use this version. With linking the libraries we could solve both disadvantages for us. -Original Message- From: Turner, John [mailto:JTurner;AAS.com] Sent: Monday, November 04, 2002 5:39 PM To: 'Tomcat Users List' Subject: RE: Tomcat and CLASSPATH We don't use symbolic links. Everything is under Tomcat's directory tree. What is the advantage to using symbolic links or an external classpath? I'm not seeing what advantage you would get. -- 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
RE: Tomcat and CLASSPATH
Yes it is housekeeping, and we already have scripts that can do the housekeeping. As we have in the past moved from linking to the repositories, we have already a list of jar files that are needed outside of the container, and a script that creates the repository entries. Still I see some disadvantages. - I feel more comfortable if I can see directly which version of a library is used instead on relying on external reference. (I have seen to many people ignoring the rules and copying something manually without updating the reference.) - Although disk space is cheap, it's not for free. And there are other space requirements that aren't cheap at all (backup drive + tapes) Currently the libraries that are used for our sites have a size of roughly 4-5MB. If you have to copy this for each site it can get a quite big number. Depending on your business model, that can be a deciding difference. (The smaller the volume of the content and the more sites you have, the more painfull this number gets) -Original Message- From: Turner, John [mailto:JTurner;AAS.com] Sent: Tuesday, November 05, 2002 2:06 PM To: 'Tomcat Users List' Subject: RE: Tomcat and CLASSPATH Thanks for the response. My point is simply that the files have to reside _somewhere_, correct? So if they have to reside _somewhere_, they might as well reside in the structure intended for them. The act of putting them in location A vs. location B is exactly the same, only the destination is different. The rest is housekeeping, and in my mind, it makes more sense to write a housekeeping tool (or use a build/deploy tool) than it does to circumvent an intentional design. The only other problem is duplicates, as you pointed out, but again, that's housekeeping. As long as you know who/what has which file, the fact that there are two copies of the file is pretty irrelevant from a practical viewpoint. John -Original Message- From: Ralph Einfeldt [mailto:ralph.einfeldt;uptime-isc.de] Sent: Tuesday, November 05, 2002 4:29 AM To: Tomcat Users List Subject: RE: Tomcat and CLASSPATH We have following reqirements: - each site can have a different version of a tool - many sites share the same vesion of the tool - a site may change the needed version of a tool - a site may replace a tool by a different one (switch from postgres to firebird) We have a setup like this: /usr/local/tool-a-v1/lib/toola.jar /usr/local/tool-a-v2/lib/toola.jar /usr/local/tool-a-v3/lib/toola.jar /usr/local/tool-b-v1/lib/toolb.jar /usr/local/tool-b-v2/lib/toolb.jar /www/online/www.site-a /www/online/www.site-b ... /www/online/www.site-z Currently we use jserv and gnujsp. jserv has the concept of repositories. The repositories are added by jserv to the internal classpath. We use the repositories to connect a site with the tools it needs. So it's very easy to change the versions of the tool or to replace the tool. Now to tomcat: Without linking we would have to copy the libraries into the tomcat directory structure for each site. With copying I see two disadvantages for us: - We would have several copies of the same libraries. Although disk space get cheaper, this is something that disturbs me (May be caused by the fact that my first hard disk had less space than a modern grafic card or handheld has memory: 40MB) - We loose the 'natural' information which version of the library we use in specific site. - If we would have to replace a version of a tool by a patched version, we could just replace the central file, now we have to copy this file to all instances that use this version. With linking the libraries we could solve both disadvantages for us. -Original Message- From: Turner, John [mailto:JTurner;AAS.com] Sent: Monday, November 04, 2002 5:39 PM To: 'Tomcat Users List' Subject: RE: Tomcat and CLASSPATH We don't use symbolic links. Everything is under Tomcat's directory tree. What is the advantage to using symbolic links or an external classpath? I'm not seeing what advantage you would get. -- 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 -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
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 :) 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
RE: Tomcat and CLASSPATH
-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
RE: Tomcat and CLASSPATH
I wouldn't mind a 'common-file-separate-instance' directory where each application (as allowed in some manner(web.xml?)) could load *separate instances* of a jar/class file that resides in the same loaction. This would avoid the duplication of such libraries that should not share instances. I have not yet looked at servlet spec 2.4, so it may already be there. Charlie -Original Message- From: Ralph Einfeldt [mailto:ralph.einfeldt;uptime-isc.de] Sent: Tuesday, November 05, 2002 8:51 AM To: Tomcat Users List Subject: RE: Tomcat and CLASSPATH Yes it is housekeeping, and we already have scripts that can do the housekeeping. As we have in the past moved from linking to the repositories, we have already a list of jar files that are needed outside of the container, and a script that creates the repository entries. Still I see some disadvantages. - I feel more comfortable if I can see directly which version of a library is used instead on relying on external reference. (I have seen to many people ignoring the rules and copying something manually without updating the reference.) - Although disk space is cheap, it's not for free. And there are other space requirements that aren't cheap at all (backup drive + tapes) Currently the libraries that are used for our sites have a size of roughly 4-5MB. If you have to copy this for each site it can get a quite big number. Depending on your business model, that can be a deciding difference. (The smaller the volume of the content and the more sites you have, the more painfull this number gets) -Original Message- From: Turner, John [mailto:JTurner;AAS.com] Sent: Tuesday, November 05, 2002 2:06 PM To: 'Tomcat Users List' Subject: RE: Tomcat and CLASSPATH Thanks for the response. My point is simply that the files have to reside _somewhere_, correct? So if they have to reside _somewhere_, they might as well reside in the structure intended for them. The act of putting them in location A vs. location B is exactly the same, only the destination is different. The rest is housekeeping, and in my mind, it makes more sense to write a housekeeping tool (or use a build/deploy tool) than it does to circumvent an intentional design. The only other problem is duplicates, as you pointed out, but again, that's housekeeping. As long as you know who/what has which file, the fact that there are two copies of the file is pretty irrelevant from a practical viewpoint. John -Original Message- From: Ralph Einfeldt [mailto:ralph.einfeldt;uptime-isc.de] Sent: Tuesday, November 05, 2002 4:29 AM To: Tomcat Users List Subject: RE: Tomcat and CLASSPATH We have following reqirements: - each site can have a different version of a tool - many sites share the same vesion of the tool - a site may change the needed version of a tool - a site may replace a tool by a different one (switch from postgres to firebird) We have a setup like this: /usr/local/tool-a-v1/lib/toola.jar /usr/local/tool-a-v2/lib/toola.jar /usr/local/tool-a-v3/lib/toola.jar /usr/local/tool-b-v1/lib/toolb.jar /usr/local/tool-b-v2/lib/toolb.jar /www/online/www.site-a /www/online/www.site-b ... /www/online/www.site-z Currently we use jserv and gnujsp. jserv has the concept of repositories. The repositories are added by jserv to the internal classpath. We use the repositories to connect a site with the tools it needs. So it's very easy to change the versions of the tool or to replace the tool. Now to tomcat: Without linking we would have to copy the libraries into the tomcat directory structure for each site. With copying I see two disadvantages for us: - We would have several copies of the same libraries. Although disk space get cheaper, this is something that disturbs me (May be caused by the fact that my first hard disk had less space than a modern grafic card or handheld has memory: 40MB) - We loose the 'natural' information which version of the library we use in specific site. - If we would have to replace a version of a tool by a patched version, we could just replace the central file, now we have to copy this file to all instances that use this version. With linking the libraries we could solve both disadvantages for us. -Original Message- From: Turner, John [mailto:JTurner;AAS.com] Sent: Monday, November 04, 2002 5:39 PM To: 'Tomcat Users List' Subject: RE: Tomcat and CLASSPATH We don't use symbolic links. Everything is under Tomcat's directory tree. What is the advantage to using symbolic links or an external classpath? I'm not seeing what advantage you would get
RE: Tomcat and CLASSPATH
And in general, symbolic links from an application space running as root is generally a bad idea. John -Original Message- From: Andreas Probst [mailto:andpro77;gmx.net] Sent: Saturday, November 02, 2002 10:48 AM To: Tomcat Users List Subject: Re: Tomcat and CLASSPATH Hi Chris, you could set your classpath in the tomcat startup script. But this is not recommended. There were messages a few days ago explaining this. Besides, it might not always be desirable that Tomcat knows when classes change... Andreas On 2 Nov 2002 at 7:52, Chris gokey wrote: Under UNIX it was very convenient for us to create a symbolic link from our WEB-INF/lib and WEB-INF/classes directory to the respective directories in our package that contained our jars and to the base directory of our package structure (for the purpose of setting up the CLASSPATH). But unfortunately this approach is not platform independent and won't work under windows. Is my only alternative to copy all these files to WEB-INF? The advantage of symbolically linking is that any time these classes changed, Tomcat would automatically know about it. Is there another way to tell Tomcat where my claases are? Possibly specify the CLASSPATH in my web.xml file? Thanks, Chris -- 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
RE: Tomcat and CLASSPATH
We never run Tomcat as root so this is not an issue. So what is the general pattern? To add to your Ant build script to create a jar of your application and place it in WEB-INF whenever the classes change? This is fine for small applications but for development, but for very large apps, it seems like pointing it to your general classes would be much easier. Or is it possible for Ant to do incremental changes to a jar file? Chris -Original Message- From: tomcat-user-return-39993- [EMAIL PROTECTED] [mailto:tomcat-user-return- [EMAIL PROTECTED]] On Behalf Of Turner, John Sent: Monday, November 04, 2002 8:08 AM To: 'Tomcat Users List' Subject: RE: Tomcat and CLASSPATH And in general, symbolic links from an application space running as root is generally a bad idea. John -Original Message- From: Andreas Probst [mailto:andpro77;gmx.net] Sent: Saturday, November 02, 2002 10:48 AM To: Tomcat Users List Subject: Re: Tomcat and CLASSPATH Hi Chris, you could set your classpath in the tomcat startup script. But this is not recommended. There were messages a few days ago explaining this. Besides, it might not always be desirable that Tomcat knows when classes change... Andreas On 2 Nov 2002 at 7:52, Chris gokey wrote: Under UNIX it was very convenient for us to create a symbolic link from our WEB-INF/lib and WEB-INF/classes directory to the respective directories in our package that contained our jars and to the base directory of our package structure (for the purpose of setting up the CLASSPATH). But unfortunately this approach is not platform independent and won't work under windows. Is my only alternative to copy all these files to WEB-INF? The advantage of symbolically linking is that any time these classes changed, Tomcat would automatically know about it. Is there another way to tell Tomcat where my claases are? Possibly specify the CLASSPATH in my web.xml file? Thanks, Chris -- 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- [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
RE: Tomcat and CLASSPATH
can't you just have ant copy the modified classes(or jar) to WEB-INF? -Original Message- From: Chris gokey [mailto:cgokey;gcmd.nasa.gov] Sent: Monday, November 04, 2002 10:34 AM To: 'Tomcat Users List' Subject: RE: Tomcat and CLASSPATH We never run Tomcat as root so this is not an issue. So what is the general pattern? To add to your Ant build script to create a jar of your application and place it in WEB-INF whenever the classes change? This is fine for small applications but for development, but for very large apps, it seems like pointing it to your general classes would be much easier. Or is it possible for Ant to do incremental changes to a jar file? Chris -Original Message- From: tomcat-user-return-39993- [EMAIL PROTECTED] [mailto:tomcat-user-return- [EMAIL PROTECTED]] On Behalf Of Turner, John Sent: Monday, November 04, 2002 8:08 AM To: 'Tomcat Users List' Subject: RE: Tomcat and CLASSPATH And in general, symbolic links from an application space running as root is generally a bad idea. John -Original Message- From: Andreas Probst [mailto:andpro77;gmx.net] Sent: Saturday, November 02, 2002 10:48 AM To: Tomcat Users List Subject: Re: Tomcat and CLASSPATH Hi Chris, you could set your classpath in the tomcat startup script. But this is not recommended. There were messages a few days ago explaining this. Besides, it might not always be desirable that Tomcat knows when classes change... Andreas On 2 Nov 2002 at 7:52, Chris gokey wrote: Under UNIX it was very convenient for us to create a symbolic link from our WEB-INF/lib and WEB-INF/classes directory to the respective directories in our package that contained our jars and to the base directory of our package structure (for the purpose of setting up the CLASSPATH). But unfortunately this approach is not platform independent and won't work under windows. Is my only alternative to copy all these files to WEB-INF? The advantage of symbolically linking is that any time these classes changed, Tomcat would automatically know about it. Is there another way to tell Tomcat where my claases are? Possibly specify the CLASSPATH in my web.xml file? Thanks, Chris -- 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- [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
RE: Tomcat and CLASSPATH
That's actually what I was referring to by the building an incremental jar. Maybe that isn't the right term, but I meant as the classes change it will automatically update the jar with only the changed classes. Of course copying the changed class files to WEB-INF/classes would work too. I just do not know enough about Ant to know if it can capture the classes that have changed and copy them. Still seems like it would be nice to be able to specify an external classpath in the web.inf file.. thus, you wouldn't need two copies of your classes and jars on the same machine. What does everyone else do? Just have a script that does a straight copy? Chris -Original Message- From: tomcat-user-return-40012- [EMAIL PROTECTED] [mailto:tomcat-user-return- [EMAIL PROTECTED]] On Behalf Of Cox, Charlie Sent: Monday, November 04, 2002 10:40 AM To: 'Tomcat Users List' Subject: RE: Tomcat and CLASSPATH can't you just have ant copy the modified classes(or jar) to WEB-INF? -Original Message- From: Chris gokey [mailto:cgokey;gcmd.nasa.gov] Sent: Monday, November 04, 2002 10:34 AM To: 'Tomcat Users List' Subject: RE: Tomcat and CLASSPATH We never run Tomcat as root so this is not an issue. So what is the general pattern? To add to your Ant build script to create a jar of your application and place it in WEB-INF whenever the classes change? This is fine for small applications but for development, but for very large apps, it seems like pointing it to your general classes would be much easier. Or is it possible for Ant to do incremental changes to a jar file? Chris -Original Message- From: tomcat-user-return-39993- [EMAIL PROTECTED] [mailto:tomcat-user-return- [EMAIL PROTECTED]] On Behalf Of Turner, John Sent: Monday, November 04, 2002 8:08 AM To: 'Tomcat Users List' Subject: RE: Tomcat and CLASSPATH And in general, symbolic links from an application space running as root is generally a bad idea. John -Original Message- From: Andreas Probst [mailto:andpro77;gmx.net] Sent: Saturday, November 02, 2002 10:48 AM To: Tomcat Users List Subject: Re: Tomcat and CLASSPATH Hi Chris, you could set your classpath in the tomcat startup script. But this is not recommended. There were messages a few days ago explaining this. Besides, it might not always be desirable that Tomcat knows when classes change... Andreas On 2 Nov 2002 at 7:52, Chris gokey wrote: Under UNIX it was very convenient for us to create a symbolic link from our WEB-INF/lib and WEB-INF/classes directory to the respective directories in our package that contained our jars and to the base directory of our package structure (for the purpose of setting up the CLASSPATH). But unfortunately this approach is not platform independent and won't work under windows. Is my only alternative to copy all these files to WEB-INF? The advantage of symbolically linking is that any time these classes changed, Tomcat would automatically know about it. Is there another way to tell Tomcat where my claases are? Possibly specify the CLASSPATH in my web.xml file? Thanks, Chris -- 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- [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- [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
RE: Tomcat and CLASSPATH
We don't use symbolic links. Everything is under Tomcat's directory tree. What is the advantage to using symbolic links or an external classpath? I'm not seeing what advantage you would get. John -Original Message- From: Chris gokey [mailto:cgokey;gcmd.nasa.gov] Sent: Monday, November 04, 2002 11:30 AM To: 'Tomcat Users List' Subject: RE: Tomcat and CLASSPATH That's actually what I was referring to by the building an incremental jar. Maybe that isn't the right term, but I meant as the classes change it will automatically update the jar with only the changed classes. Of course copying the changed class files to WEB-INF/classes would work too. I just do not know enough about Ant to know if it can capture the classes that have changed and copy them. Still seems like it would be nice to be able to specify an external classpath in the web.inf file.. thus, you wouldn't need two copies of your classes and jars on the same machine. What does everyone else do? Just have a script that does a straight copy? Chris -Original Message- From: tomcat-user-return-40012- [EMAIL PROTECTED] [mailto:tomcat-user-return- [EMAIL PROTECTED]] On Behalf Of Cox, Charlie Sent: Monday, November 04, 2002 10:40 AM To: 'Tomcat Users List' Subject: RE: Tomcat and CLASSPATH can't you just have ant copy the modified classes(or jar) to WEB-INF? -Original Message- From: Chris gokey [mailto:cgokey;gcmd.nasa.gov] Sent: Monday, November 04, 2002 10:34 AM To: 'Tomcat Users List' Subject: RE: Tomcat and CLASSPATH We never run Tomcat as root so this is not an issue. So what is the general pattern? To add to your Ant build script to create a jar of your application and place it in WEB-INF whenever the classes change? This is fine for small applications but for development, but for very large apps, it seems like pointing it to your general classes would be much easier. Or is it possible for Ant to do incremental changes to a jar file? Chris -Original Message- From: tomcat-user-return-39993- [EMAIL PROTECTED] [mailto:tomcat-user-return- [EMAIL PROTECTED]] On Behalf Of Turner, John Sent: Monday, November 04, 2002 8:08 AM To: 'Tomcat Users List' Subject: RE: Tomcat and CLASSPATH And in general, symbolic links from an application space running as root is generally a bad idea. John -Original Message- From: Andreas Probst [mailto:andpro77;gmx.net] Sent: Saturday, November 02, 2002 10:48 AM To: Tomcat Users List Subject: Re: Tomcat and CLASSPATH Hi Chris, you could set your classpath in the tomcat startup script. But this is not recommended. There were messages a few days ago explaining this. Besides, it might not always be desirable that Tomcat knows when classes change... Andreas On 2 Nov 2002 at 7:52, Chris gokey wrote: Under UNIX it was very convenient for us to create a symbolic link from our WEB-INF/lib and WEB-INF/classes directory to the respective directories in our package that contained our jars and to the base directory of our package structure (for the purpose of setting up the CLASSPATH). But unfortunately this approach is not platform independent and won't work under windows. Is my only alternative to copy all these files to WEB-INF? The advantage of symbolically linking is that any time these classes changed, Tomcat would automatically know about it. Is there another way to tell Tomcat where my claases are? Possibly specify the CLASSPATH in my web.xml file? Thanks, Chris -- 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- [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- [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
RE: Tomcat and CLASSPATH
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 -Original Message- From: tomcat-user-return-40023- [EMAIL PROTECTED] [mailto:tomcat-user-return- [EMAIL PROTECTED]] On Behalf Of Turner, John Sent: Monday, November 04, 2002 11:39 AM To: 'Tomcat Users List' Subject: RE: Tomcat and CLASSPATH We don't use symbolic links. Everything is under Tomcat's directory tree. What is the advantage to using symbolic links or an external classpath? I'm not seeing what advantage you would get. John -Original Message- From: Chris gokey [mailto:cgokey;gcmd.nasa.gov] Sent: Monday, November 04, 2002 11:30 AM To: 'Tomcat Users List' Subject: RE: Tomcat and CLASSPATH That's actually what I was referring to by the building an incremental jar. Maybe that isn't the right term, but I meant as the classes change it will automatically update the jar with only the changed classes. Of course copying the changed class files to WEB-INF/classes would work too. I just do not know enough about Ant to know if it can capture the classes that have changed and copy them. Still seems like it would be nice to be able to specify an external classpath in the web.inf file.. thus, you wouldn't need two copies of your classes and jars on the same machine. What does everyone else do? Just have a script that does a straight copy? Chris -Original Message- From: tomcat-user-return-40012- [EMAIL PROTECTED] [mailto:tomcat-user-return- [EMAIL PROTECTED]] On Behalf Of Cox, Charlie Sent: Monday, November 04, 2002 10:40 AM To: 'Tomcat Users List' Subject: RE: Tomcat and CLASSPATH can't you just have ant copy the modified classes(or jar) to WEB-INF? -Original Message- From: Chris gokey [mailto:cgokey;gcmd.nasa.gov] Sent: Monday, November 04, 2002 10:34 AM To: 'Tomcat Users List' Subject: RE: Tomcat and CLASSPATH We never run Tomcat as root so this is not an issue. So what is the general pattern? To add to your Ant build script to create a jar of your application and place it in WEB-INF whenever the classes change? This is fine for small applications but for development, but for very large apps, it seems like pointing it to your general classes would be much easier. Or is it possible for Ant to do incremental changes to a jar file? Chris -Original Message- From: tomcat-user-return-39993- [EMAIL PROTECTED] [mailto:tomcat-user-return- [EMAIL PROTECTED]] On Behalf Of Turner, John Sent: Monday, November 04, 2002 8:08 AM To: 'Tomcat Users List' Subject: RE: Tomcat and CLASSPATH And in general, symbolic links from an application space running as root is generally a bad idea. John -Original Message- From: Andreas Probst [mailto:andpro77;gmx.net] Sent: Saturday, November 02, 2002 10:48 AM To: Tomcat Users List Subject: Re: Tomcat and CLASSPATH Hi Chris, you could set your classpath in the tomcat startup script. But this is not recommended. There were messages a few days ago explaining this. Besides, it might not always be desirable that Tomcat knows when classes change... Andreas On 2 Nov 2002 at 7:52, Chris gokey wrote: Under UNIX it was very convenient for us to create a symbolic link from our WEB-INF/lib and WEB-INF/classes directory to the respective directories in our package that contained our jars and to the base directory of our package structure (for the purpose of setting up the CLASSPATH). But unfortunately this approach is not platform independent and won't work under windows. Is my only alternative to copy all these files to WEB-INF? The advantage of symbolically linking is that any time these classes changed, Tomcat would automatically know about
RE: Tomcat and CLASSPATH
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 -Original Message- From: tomcat-user-return-40023- [EMAIL PROTECTED] [mailto:tomcat-user-return- [EMAIL PROTECTED]] On Behalf Of Turner, John Sent: Monday, November 04, 2002 11:39 AM To: 'Tomcat Users List' Subject: RE: Tomcat and CLASSPATH We don't use symbolic links. Everything is under Tomcat's directory tree. What is the advantage to using symbolic links or an external classpath? I'm not seeing what advantage you would get. John -Original Message- From: Chris gokey [mailto:cgokey;gcmd.nasa.gov] Sent: Monday, November 04, 2002 11:30 AM To: 'Tomcat Users List' Subject: RE: Tomcat and CLASSPATH That's actually what I was referring to by the building an incremental jar. Maybe that isn't the right term, but I meant as the classes change it will automatically update the jar with only the changed classes. Of course copying the changed class files to WEB-INF/classes would work too. I just do not know enough about Ant to know if it can capture the classes that have changed and copy them. Still seems like it would be nice to be able to specify an external classpath in the web.inf file.. thus, you wouldn't need two copies of your classes and jars on the same machine. What does everyone else do? Just have a script that does a straight copy? Chris -Original Message- From: tomcat-user-return-40012- [EMAIL PROTECTED] [mailto:tomcat-user-return- [EMAIL PROTECTED]] On Behalf Of Cox, Charlie Sent: Monday, November 04, 2002 10:40 AM To: 'Tomcat Users List' Subject: RE: Tomcat and CLASSPATH can't you just have ant copy the modified classes(or jar) to WEB-INF? -Original Message- From: Chris gokey [mailto:cgokey;gcmd.nasa.gov] Sent: Monday, November 04, 2002 10:34 AM To: 'Tomcat Users List' Subject: RE: Tomcat and CLASSPATH We never run Tomcat as root so this is not an issue. So what is the general pattern? To add to your Ant build script to create a jar of your application and place it in WEB-INF whenever the classes change? This is fine for small applications but for development, but for very large apps, it seems like pointing it to your general classes would be much easier. Or is it possible for Ant to do incremental changes to a jar file? Chris -Original Message- From: tomcat-user-return-39993- [EMAIL PROTECTED] [mailto:tomcat-user-return- [EMAIL PROTECTED]] On Behalf Of Turner, John Sent: Monday, November 04, 2002 8:08 AM To: 'Tomcat Users List' Subject: RE: Tomcat and CLASSPATH And in general, symbolic links from an application space running as root is generally a bad idea. John -Original Message- From: Andreas Probst
RE: Tomcat and CLASSPATH
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 -Original Message- From: tomcat-user-return-40023- [EMAIL PROTECTED] [mailto:tomcat-user-return- [EMAIL PROTECTED]] On Behalf Of Turner, John Sent: Monday, November 04, 2002 11:39 AM To: 'Tomcat Users List' Subject: RE: Tomcat and CLASSPATH We don't use symbolic links. Everything is under Tomcat's directory tree. What is the advantage to using symbolic links or an external classpath? I'm not seeing what advantage you would get. John -Original Message- From: Chris gokey [mailto:cgokey;gcmd.nasa.gov] Sent: Monday, November 04, 2002 11:30 AM To: 'Tomcat Users List' Subject: RE: Tomcat and CLASSPATH That's actually what I was referring to by the building an incremental jar. Maybe that isn't the right term, but I meant as the classes change it will automatically update the jar with only the changed classes. Of course copying the changed class files to WEB-INF/classes would work too. I just do not know enough about Ant to know if it can capture the classes that have changed and copy them. Still seems like it would be nice to be able to specify an external classpath in the web.inf file.. thus, you wouldn't need two copies of your classes and jars on the same machine. What does everyone else do? Just have a script that does a straight copy? Chris -Original Message- From: tomcat-user-return-40012- [EMAIL PROTECTED] [mailto:tomcat-user-return- [EMAIL PROTECTED]] On Behalf Of Cox, Charlie Sent: Monday, November 04, 2002 10:40 AM To: 'Tomcat Users List' Subject: RE: Tomcat and CLASSPATH can't you just have ant copy the modified classes(or jar) to WEB-INF? -Original Message- From: Chris gokey [mailto:cgokey;gcmd.nasa.gov] Sent: Monday, November 04, 2002 10:34 AM
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-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
Tomcat and CLASSPATH
Under UNIX it was very convenient for us to create a symbolic link from our WEB-INF/lib and WEB-INF/classes directory to the respective directories in our package that contained our jars and to the base directory of our package structure (for the purpose of setting up the CLASSPATH). But unfortunately this approach is not platform independent and won't work under windows. Is my only alternative to copy all these files to WEB-INF? The advantage of symbolically linking is that any time these classes changed, Tomcat would automatically know about it. Is there another way to tell Tomcat where my claases are? Possibly specify the CLASSPATH in my web.xml file? Thanks, Chris -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
Re: Tomcat and CLASSPATH
Hi Chris, you could set your classpath in the tomcat startup script. But this is not recommended. There were messages a few days ago explaining this. Besides, it might not always be desirable that Tomcat knows when classes change... Andreas On 2 Nov 2002 at 7:52, Chris gokey wrote: Under UNIX it was very convenient for us to create a symbolic link from our WEB-INF/lib and WEB-INF/classes directory to the respective directories in our package that contained our jars and to the base directory of our package structure (for the purpose of setting up the CLASSPATH). But unfortunately this approach is not platform independent and won't work under windows. Is my only alternative to copy all these files to WEB-INF? The advantage of symbolically linking is that any time these classes changed, Tomcat would automatically know about it. Is there another way to tell Tomcat where my claases are? Possibly specify the CLASSPATH in my web.xml file? Thanks, Chris -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
Tomcat 4.03 Classpath
Hi; I just upgraded to Tomcat 4.03. I've got jsps running.except for when they call java classes. I get a 500 error complaining about not being able to find the classes. My CLASSPATH echos fine.(its pointing to classes not src ) I checked through the docs looking for changes in how 4.03 handles java classes versus how 3.02 does. I couldn't find anything. Can anyone point me to a FAQ that might handle this issue? Also where can I find startup options to use with startup.sh ? Thanks in advance Steve -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 4.03 Classpath
what version was you on before ?? -Original Message- From: Steve Russell [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 25, 2002 4:18 PM To: Tomcat Users List Subject: Tomcat 4.03 Classpath Hi; I just upgraded to Tomcat 4.03. I've got jsps running.except for when they call java classes. I get a 500 error complaining about not being able to find the classes. My CLASSPATH echos fine.(its pointing to classes not src ) I checked through the docs looking for changes in how 4.03 handles java classes versus how 3.02 does. I couldn't find anything. Can anyone point me to a FAQ that might handle this issue? Also where can I find startup options to use with startup.sh ? Thanks in advance Steve -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 4.03 Classpath
I had the same thing(I think). It was something like can't find class org.apache.catalina.PrintWriter or org.apache.catalina.Vector solution was to import java.io.PrintWriter I was going from 3.2.4 to 4.0.4 Hope this helps, Dave -Original Message- From: Ron Day [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 25, 2002 4:23 PM To: Tomcat Users List Subject: RE: Tomcat 4.03 Classpath what version was you on before ?? -Original Message- From: Steve Russell [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 25, 2002 4:18 PM To: Tomcat Users List Subject: Tomcat 4.03 Classpath Hi; I just upgraded to Tomcat 4.03. I've got jsps running.except for when they call java classes. I get a 500 error complaining about not being able to find the classes. My CLASSPATH echos fine.(its pointing to classes not src ) I checked through the docs looking for changes in how 4.03 handles java classes versus how 3.02 does. I couldn't find anything. Can anyone point me to a FAQ that might handle this issue? Also where can I find startup options to use with startup.sh ? Thanks in advance Steve -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 4.03 Classpath
Nope. Tomcat 4.03 is complaining about not being able to find my homemade project classes. When I was on Tomcat 3.2 I just set my systems CLASSPATH to point to these .class directories, as they are now. Steve Durham David Cntr 805CSS/SCBE wrote: I had the same thing(I think). It was something like can't find class org.apache.catalina.PrintWriter or org.apache.catalina.Vector solution was to import java.io.PrintWriter I was going from 3.2.4 to 4.0.4 Hope this helps, Dave -Original Message- From: Ron Day [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 25, 2002 4:23 PM To: Tomcat Users List Subject: RE: Tomcat 4.03 Classpath what version was you on before ?? -Original Message- From: Steve Russell [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 25, 2002 4:18 PM To: Tomcat Users List Subject: Tomcat 4.03 Classpath Hi; I just upgraded to Tomcat 4.03. I've got jsps running.except for when they call java classes. I get a 500 error complaining about not being able to find the classes. My CLASSPATH echos fine.(its pointing to classes not src ) I checked through the docs looking for changes in how 4.03 handles java classes versus how 3.02 does. I couldn't find anything. Can anyone point me to a FAQ that might handle this issue? Also where can I find startup options to use with startup.sh ? Thanks in advance Steve -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 4.03 Classpath
Tomcat 3.2 Ron Day wrote: what version was you on before ?? -Original Message- From: Steve Russell [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 25, 2002 4:18 PM To: Tomcat Users List Subject: Tomcat 4.03 Classpath Hi; I just upgraded to Tomcat 4.03. I've got jsps running.except for when they call java classes. I get a 500 error complaining about not being able to find the classes. My CLASSPATH echos fine.(its pointing to classes not src ) I checked through the docs looking for changes in how 4.03 handles java classes versus how 3.02 does. I couldn't find anything. Can anyone point me to a FAQ that might handle this issue? Also where can I find startup options to use with startup.sh ? Thanks in advance Steve -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 4.03 Classpath
Tomcat 4.0 and above strictly enforces the Servlet 2.2 WebApp directory structure (3.0 + did not). Inside your webapp folder you put JSP's,html etc. You also need a folder called WEB-INF (spelling and case important). Inside here are two folders classes and lib, and your web.xml if you have one. You put your class files in the classes folder (in full package structure). And I strongly suggest you use a package. Tomcat does not do well with the default packge. Ron -Original Message- From: Steve Russell [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 25, 2002 4:40 PM To: Tomcat Users List Subject: Re: Tomcat 4.03 Classpath Tomcat 3.2 Ron Day wrote: what version was you on before ?? -Original Message- From: Steve Russell [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 25, 2002 4:18 PM To: Tomcat Users List Subject: Tomcat 4.03 Classpath Hi; I just upgraded to Tomcat 4.03. I've got jsps running.except for when they call java classes. I get a 500 error complaining about not being able to find the classes. My CLASSPATH echos fine.(its pointing to classes not src ) I checked through the docs looking for changes in how 4.03 handles java classes versus how 3.02 does. I couldn't find anything. Can anyone point me to a FAQ that might handle this issue? Also where can I find startup options to use with startup.sh ? Thanks in advance Steve -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 4.03 Classpath
Optionally you can try to import YourClass if you don't want it inside a package, but you're probably better off putting the class into a package. Dave -Original Message- From: Ron Day [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 25, 2002 4:51 PM To: Tomcat Users List Subject: RE: Tomcat 4.03 Classpath Tomcat 4.0 and above strictly enforces the Servlet 2.2 WebApp directory structure (3.0 + did not). Inside your webapp folder you put JSP's,html etc. You also need a folder called WEB-INF (spelling and case important). Inside here are two folders classes and lib, and your web.xml if you have one. You put your class files in the classes folder (in full package structure). And I strongly suggest you use a package. Tomcat does not do well with the default packge. Ron -Original Message- From: Steve Russell [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 25, 2002 4:40 PM To: Tomcat Users List Subject: Re: Tomcat 4.03 Classpath Tomcat 3.2 Ron Day wrote: what version was you on before ?? -Original Message- From: Steve Russell [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 25, 2002 4:18 PM To: Tomcat Users List Subject: Tomcat 4.03 Classpath Hi; I just upgraded to Tomcat 4.03. I've got jsps running.except for when they call java classes. I get a 500 error complaining about not being able to find the classes. My CLASSPATH echos fine.(its pointing to classes not src ) I checked through the docs looking for changes in how 4.03 handles java classes versus how 3.02 does. I couldn't find anything. Can anyone point me to a FAQ that might handle this issue? Also where can I find startup options to use with startup.sh ? Thanks in advance Steve -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 4.03 Classpath
Ron Day wrote: Tomcat 4.0 and above strictly enforces the Servlet 2.2 WebApp directory structure (3.0 + did not). Inside your webapp folder you put JSP's,html etc. You also need a folder called WEB-INF (spelling and case important). Inside here are two folders classes and lib, and your web.xml if you have one. You put your class files in the classes folder (in full package structure). And I strongly suggest you use a package. Tomcat does not do well with the default packge. In other words it will not look for my classes unless it is in the specified architecture. CLASSPATH is ignored. Thanks, that is what I needed to know. I have packages. I just have to rearrange where they are being put in my project. I read the docs, but I was hoping to avoid that. Now I know I can't Steve -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 4.03 Classpath
you need to import either way... -Original Message- From: Durham David Cntr 805CSS/SCBE [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 25, 2002 4:52 PM To: Tomcat Users List Subject: RE: Tomcat 4.03 Classpath Optionally you can try to import YourClass if you don't want it inside a package, but you're probably better off putting the class into a package. Dave -Original Message- From: Ron Day [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 25, 2002 4:51 PM To: Tomcat Users List Subject: RE: Tomcat 4.03 Classpath Tomcat 4.0 and above strictly enforces the Servlet 2.2 WebApp directory structure (3.0 + did not). Inside your webapp folder you put JSP's,html etc. You also need a folder called WEB-INF (spelling and case important). Inside here are two folders classes and lib, and your web.xml if you have one. You put your class files in the classes folder (in full package structure). And I strongly suggest you use a package. Tomcat does not do well with the default packge. Ron -Original Message- From: Steve Russell [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 25, 2002 4:40 PM To: Tomcat Users List Subject: Re: Tomcat 4.03 Classpath Tomcat 3.2 Ron Day wrote: what version was you on before ?? -Original Message- From: Steve Russell [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 25, 2002 4:18 PM To: Tomcat Users List Subject: Tomcat 4.03 Classpath Hi; I just upgraded to Tomcat 4.03. I've got jsps running.except for when they call java classes. I get a 500 error complaining about not being able to find the classes. My CLASSPATH echos fine.(its pointing to classes not src ) I checked through the docs looking for changes in how 4.03 handles java classes versus how 3.02 does. I couldn't find anything. Can anyone point me to a FAQ that might handle this issue? Also where can I find startup options to use with startup.sh ? Thanks in advance Steve -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 4.03 Classpath
Yeah, but you would be importing my.package.MyClass instead of MyClass -Original Message- From: Ron Day [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 25, 2002 4:56 PM To: Tomcat Users List Subject: RE: Tomcat 4.03 Classpath you need to import either way... -Original Message- From: Durham David Cntr 805CSS/SCBE [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 25, 2002 4:52 PM To: Tomcat Users List Subject: RE: Tomcat 4.03 Classpath Optionally you can try to import YourClass if you don't want it inside a package, but you're probably better off putting the class into a package. Dave -Original Message- From: Ron Day [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 25, 2002 4:51 PM To: Tomcat Users List Subject: RE: Tomcat 4.03 Classpath Tomcat 4.0 and above strictly enforces the Servlet 2.2 WebApp directory structure (3.0 + did not). Inside your webapp folder you put JSP's,html etc. You also need a folder called WEB-INF (spelling and case important). Inside here are two folders classes and lib, and your web.xml if you have one. You put your class files in the classes folder (in full package structure). And I strongly suggest you use a package. Tomcat does not do well with the default packge. Ron -Original Message- From: Steve Russell [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 25, 2002 4:40 PM To: Tomcat Users List Subject: Re: Tomcat 4.03 Classpath Tomcat 3.2 Ron Day wrote: what version was you on before ?? -Original Message- From: Steve Russell [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 25, 2002 4:18 PM To: Tomcat Users List Subject: Tomcat 4.03 Classpath Hi; I just upgraded to Tomcat 4.03. I've got jsps running.except for when they call java classes. I get a 500 error complaining about not being able to find the classes. My CLASSPATH echos fine.(its pointing to classes not src ) I checked through the docs looking for changes in how 4.03 handles java classes versus how 3.02 does. I couldn't find anything. Can anyone point me to a FAQ that might handle this issue? Also where can I find startup options to use with startup.sh ? Thanks in advance Steve -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tomcat 4.0.1 CLASSPATH problem
Hi I need an xml file in my classpath.If I put it in the WEB-INF/classes directory of my web application tomcat doesn't add it in classpath (or it it not visible to my application) And when I put it in the common/classes dir of tomcat installation it is visible to my application. The problem is I have multiple application sharing same apache and tomcat installation. Every application has it's own xml file. So I can not put them in common/classes directory. Can anybody please help me out. dt __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 4.0.1 CLASSPATH problem
try putting file under WEB-INF/ directly instead of WEB-INF/classes CT. -Original Message- From: Deepak Tiwari [mailto:[EMAIL PROTECTED]] Sent: Thursday, 6 June 2002 2:26 PM To: [EMAIL PROTECTED] Subject: Tomcat 4.0.1 CLASSPATH problem Hi I need an xml file in my classpath.If I put it in the WEB-INF/classes directory of my web application tomcat doesn't add it in classpath (or it it not visible to my application) And when I put it in the common/classes dir of tomcat installation it is visible to my application. The problem is I have multiple application sharing same apache and tomcat installation. Every application has it's own xml file. So I can not put them in common/classes directory. Can anybody please help me out. dt __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tomcat 3.3 classpath
Cheers for the earlier suggestion on the problems with using Saxon, I've now installed Tomcat 3.3 and that problem has disappeared. However: Tomcat is installed in d:\tomcat3.3. I want to reference some class files in d:\. I've tried editing the :staticClasspath part of tomcat.bat, putting the line set CLASSPATH=%CLASSPATH%;d:\ at the end, but this doesn't seem to resolve the problem...any thoughts? Cheers, Pete -- The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful.
RE: Tomcat 3.3 classpath
The :staticClasspath portion of tomcat.bat is executed only for the env and jspc actions, but not for start and the others. They use just: set CLASSPATH=%TOMCAT_INSTALL%\lib\tomcat.jar. However, adding classes via the CLASSPATH is more often than not, a source of problems. A lot depends on how those classes will be used and what other classes need to be visible to those classes. Here are the recommended methods for adding class files in order of preference (assuming you don't want to put them in a webapp's WEB-INF/classes directory): 1) Create a classes directory under lib/container, lib/common, or lib/apps as desired, and place the classes under there. The classes directory will be included in the corresponding classloader. This method hasn't made it into the documentation yet. 2) Specify your classpath entry in one of the following Java System properties: org.apache.tomcat.common.classpath - Common classloader org.apache.tomcat.apps.classpath- Apps classloader. On NT and Win2k, you can use the TOMCAT_OPTS environment variable to accomplish this, i.e. set TOMCAT_OPTS=-Dorg.apache.tomcat.apps.classpath=d:\ This won't work on Win98 because it doesn't like the '=' inside the environment variable value. You will need to add the -D... to the tomcat.bat command that executes java. 3) Modify the tomcat.bat to set the CLASSPATH differently. Hope this helps. Larry -Original Message- From: Hornsby Peter [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 24, 2001 4:36 AM To: '[EMAIL PROTECTED]' Subject: Tomcat 3.3 classpath Cheers for the earlier suggestion on the problems with using Saxon, I've now installed Tomcat 3.3 and that problem has disappeared. However: Tomcat is installed in d:\tomcat3.3. I want to reference some class files in d:\. I've tried editing the :staticClasspath part of tomcat.bat, putting the line set CLASSPATH=%CLASSPATH%;d:\ at the end, but this doesn't seem to resolve the problem...any thoughts? Cheers, Pete -- The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful.
Migration to Tomcat 3.2.1 Classpath errors using Weblogic 510
We are in the process of upgrading to Tomcat 3.2.1 from 3.1 and have experienced an issue with class loading which we did not see before. We started getting class not found exceptions while trying to do a naming lookup to a Weblogic 510 sp8 server. Under 3.1 this was not an issue. We placed the weblogic .jar files in our WEB-INF/lib dir and everything was groovy. Setting the classpath upon startup of tomcat seems to fix the problem on Windows 2000. However, doing so on Linux (RH 6.2) results in Class Cast exceptions which we do not see with Tomcat 3.1 against the same deployed code base. Anyone help or pointers are appreciated. Andrew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
