[PATCH] Provide a way to locate additional classes/jars outside Tomcat directory structure
Also filed as Bug 3368
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3368).
Tomcat 3.3 provides two system properties that can be used to add to the jar
files automatically added to apps and common ClassLoaders from Tomcat
directory structure. There are legitimate reasons why one might want to do
this:
- Many do not like adding application jars to an installed product's lib
- Symbolic links are not cross platform (and ant doesn't support symbolic
links and we still end up with application jars in Tomcat lib)
How about providing two similar properties in Catalina?
org.apache.catalina.common.classpath and
org.apache.catalina.shared.classpath? (Can't we all get along?)
-arun
--- catalina/src/share/org/apache/catalina/startup/Bootstrap.java-1.24 Sat
Sep 1 03:13:18 2001
+++ catalina/src/share/org/apache/catalina/startup/Bootstrap.java Sat
Sep 1 09:25:58 2001
@@ -71,6 +71,8 @@
import java.net.MalformedURLException;
import java.net.URL;
import java.util.ArrayList;
+import java.util.List;
+import java.util.StringTokenizer;
import org.apache.catalina.loader.Extension;
import org.apache.catalina.loader.StandardClassLoader;
@@ -223,6 +225,21 @@
/**
+name of configuration property to set (using the -D option at
+startup or via .properties file) to specify the classpath
+to be used by the ClassLoader common to both the servlet engine
+and all web applications. Specify this string as
+normal file paths separated by the path.seperator delimiter for
+the host platform. Example (unix):
+precode
+* org.apache.catalina.common.classpath =
/home/mypath/lib/mylib.jar: \
+* /home/mypath/classes/
+/code/pre
+*/
+public static final String CATALINA_COMMON_CLASSPATH_PROPERTY =
+org.apache.catalina.common.classpath;
+
+/**
* Construct and return the class loader to be used for loading
* of the shared system classes.
*
@@ -286,6 +303,8 @@
}
}
+ addClassPathToList(list,
System.getProperty(CATALINA_COMMON_CLASSPATH_PROPERTY));
+
// Construct the class loader itself
String array[] = (String[]) list.toArray(new String[list.size()]);
StandardClassLoader loader = new StandardClassLoader(array);
@@ -369,6 +388,21 @@
/**
+name of configuration property to set (using the -D option at
+startup or via .properties file) to specify the classpath
+to be used by the ClassLoader shared amongst all web
applications
+(but not by the servlet container). Specify this string as
+normal file paths separated by the path.seperator delimiter for
+the host platform. Example (unix):
+precode
+* org.apache.catalina.shared.classpath =
/home/mypath/lib/mylib.jar: \
+* /home/mypath/classes/
+/code/pre
+*/
+public static final String CATALINA_SHARED_CLASSPATH_PROPERTY =
+org.apache.catalina.shared.classpath;
+
+/**
* Construct and return the class loader to be used for shared
* extensions by web applications loaded with Catalina.
*
@@ -431,6 +465,8 @@
}
}
+ addClassPathToList(list,
System.getProperty(CATALINA_SHARED_CLASSPATH_PROPERTY));
+
// Construct the class loader itself
String array[] = (String[]) list.toArray(new String[list.size()]);
StandardClassLoader loader = new StandardClassLoader(array,
parent);
@@ -449,6 +485,38 @@
return (loader);
+}
+
+private static void addClassPathToList(List list, String classpath) {
+ if(classpath != null) {
+ StringTokenizer tokenizer = new StringTokenizer(classpath,
System.getProperty(path.separator));
+ while(tokenizer.hasMoreTokens()) {
+ String filename = tokenizer.nextToken();
+ File file = new File(filename);
+ if (file.exists() file.canRead()) {
+ try {
+ String canonicalPath = file.getCanonicalPath();
+ if(file.isDirectory()) {
+ // StandardClassLoader uses File.separator to
designate a directory
+ canonicalPath += File.separator;
+ }
+ URL url = new URL(file, null, canonicalPath);
+ if (debug = 1)
+ log( Adding + url.toString());
+ list.add(url.toString());
+ } catch (IOException e) {
+ System.out.println(Cannot create URL for +
+ filename);
+ e.printStackTrace(System.out);
+ System.exit(1);
+ }
+
RE: Sources in Binary Distributions
I don't generally throw in my $0.02 into a well worn thread and add to the noise , but there is another issue which I didn't see anyone bring up. Having source around helps you with debugging. And if that results in better bug reports, i.e., instead of it doesn't work and here is the stack trace, you get it doesn't work because you didn't check for null around this line of this file, it is probably worth it. Keep in mind that many of Tomcat users are competent Java developers. And we are not talking about the entire build system here. Just the basic .java files. Not even native components (which don't aid in this purpose). Sun's Java2 SDK includes the source (just the .java files) for I suspect the same reason. Personally, I download the source distribution only when there is a critical issue in Tomcat that we need resolved now, and patch and build with that fix. Source in the binary on the other hand is useful for many reasons even if you discount the first step towards getting people involved argument. A quick check of some aspect of servlet/JSP spec(without going through 100s of pages of PDF). Help quickly identify whether the issue is with Tomcat or your code. All on machines where you typically don't have the full development environment set up (when we are talking about JSP and not servlets). Of course, one can always download the source distribution. So, if you are set on saving folks a few seconds (or minutes) of download time at a slight cost for those of us who do find it invaluable, that's fine. -arun -Original Message- From: Rob S. [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 02, 2001 4:19 AM To: [EMAIL PROTECTED] Subject: RE: Sources in Binary Distributions I'd like to second that. I am currently not involved in any active development, but looking at sources contained in a binary dist is certainly the first step towards getting involved (its on my list (o: ) So you *expect* the /src dir in a binary dist? That's mind-blowing to me. If you're interested in TC development, your first thought isn't Time to go d/l the src distro it's Time to d/l the bin dist so I can check out the src ? I'm not making a huge stand here, I thought bringing up the suggestion was almost common sense. It's a bin dist, i.e. !(src included). I wouldn't expect it to be there shrug - r
RE: Sources in Binary Distributions
OK, Rob, you are the voice of the majority (I probably missed a vote on this topic where people told you so) and we are a few lazy developers wanting to avoid an extra download. Take the source out. -arun ps: For what it is worth, my argument was not leave src in there so that when I want to look at the source, i don't have to download a src dist as you put it, it was that having the Java source available to a debugger is a legetimate reason to include source in a binary distribution (you can leave it jar'd if you like, as Sun does with Java2 SDK). Let me go back to lurking and leave the business of posting to those of you who can post the same argument 10 times without reading what the other person is saying. -Original Message- From: Rob S. [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 02, 2001 9:39 AM To: [EMAIL PROTECTED] Subject: RE: Sources in Binary Distributions So what we have here is a minority of developers who look through the Tomcat source, versus the majority of people who have no interest in the /src dir. The argument is leave src in there so that when I want to look at the source, i don't have to download a src dist. For some reason, the keep it in there argument almost makes it sounds like the src is unavailable unless it's in the bin build. Personally, for all of the people that could care less about the source, I don't think it's asking much for people who want to look at the source to go and get it...? - r -Original Message- From: Loïc Lefèvre [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 02, 2001 12:10 PM To: [EMAIL PROTECTED] Subject: RE: Sources in Binary Distributions Absolutely agree with you! -Message d'origine- De : Arun Katkere [mailto:[EMAIL PROTECTED]] Envoyé : jeudi 2 août 2001 17:28 À : '[EMAIL PROTECTED]' Objet : RE: Sources in Binary Distributions I don't generally throw in my $0.02 into a well worn thread and add to the noise , but there is another issue which I didn't see anyone bring up. Having source around helps you with debugging. And if that results in better bug reports, i.e., instead of it doesn't work and here is the stack trace, you get it doesn't work because you didn't check for null around this line of this file, it is probably worth it. Keep in mind that many of Tomcat users are competent Java developers. And we are not talking about the entire build system here. Just the basic .java files. Not even native components (which don't aid in this purpose). Sun's Java2 SDK includes the source (just the .java files) for I suspect the same reason. Personally, I download the source distribution only when there is a critical issue in Tomcat that we need resolved now, and patch and build with that fix. Source in the binary on the other hand is useful for many reasons even if you discount the first step towards getting people involved argument. A quick check of some aspect of servlet/JSP spec(without going through 100s of pages of PDF). Help quickly identify whether the issue is with Tomcat or your code. All on machines where you typically don't have the full development environment set up (when we are talking about JSP and not servlets). Of course, one can always download the source distribution. So, if you are set on saving folks a few seconds (or minutes) of download time at a slight cost for those of us who do find it invaluable, that's fine. -arun -Original Message- From: Rob S. [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 02, 2001 4:19 AM To: [EMAIL PROTECTED] Subject: RE: Sources in Binary Distributions I'd like to second that. I am currently not involved in any active development, but looking at sources contained in a binary dist is certainly the first step towards getting involved (its on my list (o: ) So you *expect* the /src dir in a binary dist? That's mind-blowing to me. If you're interested in TC development, your first thought isn't Time to go d/l the src distro it's Time to d/l the bin dist so I can check out the src ? I'm not making a huge stand here, I thought bringing up the suggestion was almost common sense. It's a bin dist, i.e. !(src included). I wouldn't expect it to be there shrug - r
RE: ServerSocket not being closed properly.
In my experience (having started/stopped Tomcat engine programatically via
ContextManager API in a loop 100s of times), server socket is always closed
correctly. And looking at 3.2.2 beta 3 source code, both PoolTcpEndpoint and
SimpleTcpEndpoint close the server socket during shutdownEndpoint().
BTW, doesn't your doStop() below kill the VM because there is a
System.exit() in Ajp12ConnectionHandler shutdown?
-arun
ps: Each invocation leaves some threads running, which is bug 1418
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1418), resolved for 3.3
(not 3.2.2). There is also some memory leak which I haven't had a chance to
track down, yet.
-Original Message-
From: Brad Cox PhD [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 23, 2001 6:04 PM
To: [EMAIL PROTECTED]
Subject: ServerSocket not being closed properly.
At 7:06 PM -0500 04/23/2001, Marc Saegesser wrote:
I was just about to call the vote for the final release of
Tomcat 3.2.2
...
While you're at it, could you ensure that tomcat closes its server
socket instead of relying on the system to do it when the VM exits?
This is a long-standing problem that interferes with running tomcat
inside IBM's VisualAge, or (equivalently) building java GUIs for
starting and stopping the server.
Here's what I've been using in a GUI for starting and stopping tomcat.
private void doStart(String[] args)
{
org.apache.tomcat.startup.Tomcat.main(args);
}
private void doStop()
{
String[] stopArgs = new String[] { -stop };
org.apache.tomcat.startup.Tomcat.main(stopArgs);
}
The buttons work the first time they're used. The start buttons fails
the second times (either by the same GUI or by any other means during
the same VisualAge session) because the server socket is still being
held open by the lack of an explicit close. The only way I've found
to clear the problem is to exit VisualAge altogether; a SLOOO
process.
I've seen the same problem in my own applications. The fix was to be
SURE that the ServerSocket is closed EXPLICITLY rather than leaving
it to the operating system to do when the process exits.
This session console log may help locate the problem.
2001-04-24 08:51:00 - ContextManager: Adding context Ctx( /examples )
2001-04-24 08:51:01 - ContextManager: Adding context Ctx( /admin )
2001-04-24 08:51:01 - Ctx( /svlt ): Set debug to 9
2001-04-24 08:51:01 - ContextManager: Adding context Ctx( /svlt )
Starting tomcat. Check logs/tomcat.log for error messages
2001-04-24 08:51:01 - ContextManager: Adding context Ctx( )
2001-04-24 08:51:01 - ContextManager: Adding context Ctx( /test )
2001-04-24 08:51:01 - ContextManager: Adding context Ctx( /digiprop )
2001-04-24 08:51:02 - Ctx( /svlt ): XmlReader - init /svlt /digiprop
2001-04-24 08:51:02 - Ctx( /svlt ): Reading /digiprop/WEB-INF/web.xml
2001-04-24 08:51:02 - Ctx( /svlt ): Loading -2147483646 jsp
2001-04-24 08:51:02 - Ctx( /svlt ): Loading 1 flush
2001-04-24 08:51:03 - Ctx( /svlt ): Loading 1 page
2001-04-24 08:51:03 - Ctx( /svlt ): Loading 1 login
FATAL:java.net.SocketException: Address already in use
java.net.SocketException: Address already in use
java.lang.Throwable(java.lang.String)
java.lang.Exception(java.lang.String)
java.io.IOException(java.lang.String)
java.net.SocketException(java.lang.String)
void
java.net.PlainSocketImpl.socketBind(java.net.InetAddress, int)
void java.net.PlainSocketImpl.bind(java.net.InetAddress, int)
java.net.ServerSocket(int, int, java.net.InetAddress)
java.net.ServerSocket(int, int)
java.net.ServerSocket
org.apache.tomcat.net.DefaultServerSocketFactory.createSocket(int,
int)
void org.apache.tomcat.service.PoolTcpEndpoint.startEndpoint()
void org.apache.tomcat.service.PoolTcpConnector.start()
void org.apache.tomcat.core.ContextManager.start()
void
org.apache.tomcat.startup.Tomcat.execute(java.lang.String [])
void org.apache.tomcat.startup.Tomcat.main(java.lang.String [])
void digiprop.site.TomcatView.doStart()
void
digiprop.site.TomcatView.connEtoC2(java.awt.event.ActionEvent)
void
digiprop.site.TomcatView$IvjEventHandler.actionPerformed(java.
awt.event.ActionEvent)
void
java.awt.Button.processActionEvent(java.awt.event.ActionEvent)
void java.awt.Button.processEvent(java.awt.AWTEvent)
void java.awt.Component.dispatchEventImpl(java.awt.AWTEvent)
void java.awt.Component.dispatchEvent(java.awt.AWTEvent)
void java.awt.EventDispatchThread.run()
--
---
Brad Cox, Ph.D.; [EMAIL PROTECTED]
Phone: 703 361 4751 Cell: 703 919-9623
http://virtualschool.edu
RE: [Bug 1059] Changed - JSP pages fail to compile when referencing classes from apps classloader
I apologize for not mentioning the version number. I guess I am used to selecting the version I am reporting against and didn't remember to type it in the description. Can someone add an entry for Tomcat 3.3m2 in bugzilla? That is a little less error prone than expecting folks to enter the version number in bug description. -arun -Original Message- From: Marc Saegesser [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 21, 2001 12:48 PM To: Arun Katkere; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: [Bug 1059] Changed - JSP pages fail to compile when referencing classes from apps classloader Arun, This bug wasn't closed. The status was updated to RESOLVED the and the resolution was changed to LATER. All this means is that it won't be address in 3.2.2 but is still open for 3.3 and later releases. Also, it would have been helpful if the description in initial bug report indcated the exact version it was being reported against. That would have saved me the time I spent trying to decide if it really applied to 3.2.2 or not. -Original Message- From: Arun Katkere [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 21, 2001 2:43 PM To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: [Bug 1059] Changed - JSP pages fail to compile when referencing classes from apps classloader Unless you are going with the new classloader architecture for 3.2.2, which I doubt, this bug doesn't apply to 3.2.2. It applies to 3.3m2 (I had to mark the version as "Unknown" since 3.3 doesn't have an entry in bugzilla). Are we accepting only bugs that apply to 3.2.2 and everything that won't be done for 3.2.2 will be unceremoniously closed? -arun -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 21, 2001 12:29 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [Bug 1059] Changed - JSP pages fail to compile when referencing classes from apps classloader http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1059 *** shadow/1059 Tue Mar 20 23:32:48 2001 --- shadow/1059.tmp.21761 Wed Mar 21 12:29:05 2001 *** *** 2,11 | JSP pages fail to compile when referencing classes from apps classloader | +- ---+ |Bug #: 1059Product: Tomcat 3| ! | Status: NEW Version: Unknown | ! | Resolution:Platform: All | | Severity: MajorOS/Version: All | ! | Priority: Component: Jasper | +- ---+ | Assigned To: [EMAIL PROTECTED] | | Reported By: [EMAIL PROTECTED] | --- 2,11 | JSP pages fail to compile when referencing classes from apps classloader | +- ---+ |Bug #: 1059Product: Tomcat 3| ! | Status: RESOLVEDVersion: Unknown | ! | Resolution: LATER Platform: All | | Severity: MajorOS/Version: All | ! | Priority: High Component: Jasper | +- ---+ | Assigned To: [EMAIL PROTECTED] | | Reported By: [EMAIL PROTECTED] | *** *** 36,39 Workaround is to use the common classloader, but we hear talks of more classloaders (for groups of webapps), and please keep Jasper in sync with these ! excellent changes. --- 36,43 Workaround is to use the common classloader, but we hear talks of more classloaders (for groups of webapps), and please keep Jasper in sync with these ! excellent changes. ! ! --- Additional Comments From [EMAIL PROTECTED] 2001-03-21 12:29 --- ! This won't be addressed in Tomcat 3.2.2. It will be evaluated for a later ! release.
RE: An open letter to 3 developers
Jon: Where does it say ASF has to be acknowledged on the Web site describing the product? If the product contains ASF software and it doesn't acknowledge it in the documentation included with the software, then it is another matter. I am not advocating this practice, but since you bring up the license, just wondering if I am looking at the wrong license or reading it wrong. What else? If someone builds a Web site with Tomcat, ASF has to be acknowledged as well? -arun -Original Message- From: Jon Stevens [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 19, 2000 12:30 PM To: [EMAIL PROTECTED] Subject: Re: An open letter to 3 developers on 12/19/2000 11:09 AM, "Bergquist, Brett" [EMAIL PROTECTED] wrote: I'm using TC3.x as the backend for an network management system that we ship/sell/give away with our equipment. I appreciate that you are using Tomcat, but... I'm sorry, but I missed the part on your website where you Credit the ASF for the use of the software according to the license on the software that you are using. Would you like to please point that out to me? I looked here: http://www.canoga.com/netman.htm thanks, -jon
Modern compilation
While trying to figure out why exactly is Jasper page loading dog slow (initial compilation is very slow, most time spent in Zip file read, and page load is slow because of secure session id initialization), I noticed that Tomcat still uses "classic" javac (sun.tools.javac.Main) instead of "modern" javac (com.sun.tools.javac.Main) even in JDK 1.3 context. Is there plans to support this compiler (which is much faster)? Does anyone have a patch/plugin we can use? While trying to write a compiler plugin myself, I realized there is no way to force the modern compiler to write to my stream instead of System.out/err. Perhaps this is the reason why modern compiler is not supported?? Also, use of any compiler plugin other than the standard SunJavaCompiler is next to impossible since the JSP engine does not read web.xml in $TOMCAT_HOME/conf. So, we are left with two unfriendly choices. Patch tomcat code or insert Tomcat specific code into each web.xml. Is there plans to move JSP compiler plugin specification to server.xml? Great software, but it is not easy to convince that to folks used to near instantaneous page compilation/load times of JServ/GNUJSP/jikes combo that Tomcat is the greatest thing out there when they sit waiting for 30-45 seconds waiting for page to compile (or even just load!!). We are not talking about bottlenecks in outside code. It is the same with Tomcat sample JSPs. -arun - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
