Re: [PATCH] Bug 841 - JSPC stack fault on NT
[EMAIL PROTECTED] (Steve Downey) writes: Under NT (and presumably any OS where File.sep != '/') JspC has a stack underflow at baseDirStack.peek() in ParserController.java. This patch converts from '\' to '/' for those cases. It also sets the package name for the class based on the URI, so that the java file is distinguished from others with the same name. The problem with '\' as the filename seperator instead of '/' also causes problems with "jsp:include", relative paths and JspC (see Bugzilla #412). I suggested there that it might be possible to just convert the '\' into '/' before passing into CommandLineContext (in JspC). This is really what happens when running within Tomcat -- the path passed into JspEngineContext has '/', not the local file seperator. Unfortunately, I don't have a patch, as I'm not organised enough to get a build environment running so I can test. -- `O O' | [EMAIL PROTECTED] // ^ \\ | http://www.pyrites.org.uk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[PROPOSAL] Tomcat 4 unpacking of WAR files behavior
"Craig R. McClanahan" wrote: Remy Maucherat wrote: Remy, What I am trying to do is start a discussion of _what_ the behaviour should be, so it can be fixed. I already consider the current behaviour to be broken. I'm mixed on the subject. Craig implemented it that way, so I want to hear his opinion on the subject. The original rationale for the current behavior was/is a very common user error with Tomcat 3.x -- it goes like this: * User drops a WAR file into "webapps" and restarts Tomcat * Tomcat auto-expands the WAR and runs fine * User updates the app, drops in an updated WAR, and restarts Tomcat * Tomcat sees the expanded directory, and does NOT auto-expand * User files a bug report "Tomcat does not reload my updated classes" :-( I'm open to suggestion for different behavior, but keep this scenario in mind. That "problem" is taken care of if the user configures the Context with unpackWARs="false", and can be documented in the user config docs. The current behaviour could lead to other bug reports, "I changed some files in an expanded WAR file, but when I restarted Tomcat my changes are missing". [PROPOSAL] Tomcat Startup ** If unpackWARs="false" - If a new war file exists with no corresponding expanded war file - The war file componenets are expanded out as needed into the work dir. If a war file with a last mod time newer than the unpacked war file components exists - The previous war file components are removed, then the war file components are expanded as needed into work dir. If unpackWARs="true" A war file exits, but no directory exists matching war file prefix. - create directory name matching war file prefix and expand war file. A war file exists, and a corresponding directory exists. The war file last mod time is older than directory. - Don't expand war file. A war file exists, and a corresponding directory exists. The war file last mod time is newer than the directory. You have one of two cases: A completely different web app exists in a directory with the same name as a new war file. You wouldn't want Tomcat to overwrite another web app, how would you determine that the war file is not a replacement. An updated war file was installed and the directory is for the previously expanded version. What if the web app saves configuration info to property files in /WEB-INF/classes, or other data in /WEB-INF? In both cases I think you should not do anything, just log an information message to the Context log. Let the user decide, perhaps they could use the manager servlet to redploy a web app. Tomcat Shutdown *** When tomcat is shutdown it should not remove any unpacked war files, whether unpackWARs is true or false. Tomcat Runtime ** In a web hosting environment I envision the manager servlet getting used a great deal by users to manage their web apps. The manager would most likely be invoked by some web app administration tool which does authentication and authorization. The DefaultContext would set unpackWARs="true", since that is the default behaviour for a Context deployed using the manager. The manager servlet currently supports the following: list - List the context paths of all web applications currently deployed on the virtual host in which this manager application is deployed. deploy?path=/xxxwar=yyy - Deploy the web application whose WAR file (or directory containing the unpacked application) is present at URL yyy, and attach it to context path /xxx. See below for valid syntax options for the web applcation archive URl. If the URL of an actual WAR file is specified, the WAR will be automatically expanded into a directory underneath the application base for this virtual host. [PROPOSAL] Change the command name to "install". If the web app already exists the install will fail. The user will have to "remove" it first. The "war" file is renamed if necessary so its prefix is the same name as the path. reload?path=/xxx - Cause the web application deployed at context path /xxx to reload all its associated Java classes, even if automatic reloading is disabled. undeploy?path=/xxx - Cause the web application deployed at context path /xxx to be gracefully shut down and undeployed. If a WAR file was automatically expanded into an unpacked directory when this application was deployed (or when the servlet container was first started), the expanded directory is deleted. [PROPOSAL] Change the command name to "stop". Do not remove the expanded web app directory when undeployed. Perhaps the user just wants to stop the web app for maintenance reasons, and will start the web app again after the maintenance is over. [PROPOSAL] New manager servlet commands
Re: Proposed ApacheConfig.java change
Costin, I would strongly vote for turning the auto-config back on by default for the following reasons (other than the fact that I explicity turned it back on when Keith fixed the ApacheConfig class): 1) This is how 3.2 worked, and how the docs specify that 3.3 works. 2) Configuration of mod_jk is notoriously complicated. Giving people the auto generated file is a big, big win. 3) For the people who run it in standalone, we can provide a comment in the file telling them to "comment out the below". That way it would work out of the box for both types (standalone + behind Apache), and be very easy for people to tune to their needs. Since the syntax has changed (and I've never been a server.xml master), I'm not sure where the AutoConfig stuff would go now. -Dan [EMAIL PROTECTED] wrote: However, after upgrading to the latest and greatest tomcat 3.3 version out of CVS (as of last night) I've suddenly noticed that tomcat is no longer generating the mod_jk.conf-auto or tomcat-apache.conf files automatically. As near as I can tell, ApacheConfig.execute() is not being called. Yes, you need to insert the ApacheConfig module in server.xml. We can include it by default for the next milestone - but I would rather not, many people use tomcat standalone. ( a better solution be part of the new admin interface, but probably after 3.3 ) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: autoconf / automake
Jon, Do you think these tools are *worth* using, or do they cause more problems than they solve? I've got a friend who is a pretty solid autoconf/automake guru, and I'm trying to tempt him into helping out with setting this up, but I won't do that if people with experience think it's going to make trouble down the road. Anyone? -Dan Jon Stevens wrote: on 3/2/01 9:12 AM, "Jones, Stephen" [EMAIL PROTECTED] wrote: Does anybody know how to use autoconf or automake? We could perhaps put an end to most of the mod_jk compilation problems if we had some good configure scripts that generated Makefiles. I don't know how complicated the tools are... Steve You can use JServ's system (which myself and Vadim) built as your basis. Needless to say, using those tools and getting them to work on a bazillion different platforms is a royal bitch. thanks, -jon -- -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: autoconf / automake
on 3/3/01 10:52 AM, "Dan Milstein" [EMAIL PROTECTED] wrote: Jon, Do you think these tools are *worth* using, or do they cause more problems than they solve? I've got a friend who is a pretty solid autoconf/automake guru, and I'm trying to tempt him into helping out with setting this up, but I won't do that if people with experience think it's going to make trouble down the road. Anyone? -Dan They are totally worth using. Once you get it right, they are a life saver and the work put into JServ can really be re-used here. Getting it right is the hard part. It needs a *lot* of testing. -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous http://jakarta.apache.org/velocity/ http://java.apache.org/turbine/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/tests/webpages/WEB-INF test-tomcat.xml
nacho 01/03/03 14:08:16
Modified:src/tests/webpages/WEB-INF test-tomcat.xml
Added: src/tests/webpages/WEB-INF/classes CloseWriter.java
src/tests/share/tests/jsp/Golden CloseWriter.txt
Log:
Regression test for reciclying writer bug ( aka RequesDispatcher ) .
Revision ChangesPath
1.1
jakarta-tomcat/src/tests/webpages/WEB-INF/classes/CloseWriter.java
Index: CloseWriter.java
===
import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;
public class CloseWriter extends HttpServlet {
public void init(ServletConfig conf)
throws ServletException
{
super.init(conf);
}
public void service(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException
{
res.setContentType("text/plain");
PrintWriter out= res.getWriter();
out.write( "Closing Writer" );
/// XXX trying to simulate the closed outputstream bug,
// this test runs 2 times hoping it will catch a regression
// on this issue..
out.close();
}
}
1.1 jakarta-tomcat/src/tests/share/tests/jsp/Golden/CloseWriter.txt
Index: CloseWriter.txt
===
Closing Writer
1.27 +25 -9 jakarta-tomcat/src/tests/webpages/WEB-INF/test-tomcat.xml
Index: test-tomcat.xml
===
RCS file: /home/cvs/jakarta-tomcat/src/tests/webpages/WEB-INF/test-tomcat.xml,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- test-tomcat.xml 2001/03/01 17:59:03 1.26
+++ test-tomcat.xml 2001/03/03 22:08:16 1.27
@@ -16,7 +16,7 @@
early tests.
--
- property name="revision" value="$Revision: 1.26 $" /
+ property name="revision" value="$Revision: 1.27 $" /
property name="host" value="127.0.0.1" /
property name="port" value="8080" /
property name="outputType" value="text" /
@@ -52,7 +52,7 @@
taskdef name="comment"
classname="org.apache.tomcat.util.test.Body" /
- taskdef name="gtestDefaults"
+ taskdef name="gtestDefaults"
classname="org.apache.tomcat.util.test.TestDefaults" /
!-- Backward compatibility --
@@ -108,7 +108,7 @@
target name="params" depends="init"
httpClient
- commentSimple GET with parmeters/comment
+ commentSimple GET with parameters/comment
httpRequest path="/test/servlet/params.Params"
param name="a" value="k" /
param name="c" value="l" /
@@ -120,7 +120,7 @@
/httpClient
httpClient
- commentSimple POST parmeters/comment
+ commentSimple POST parameters/comment
httpRequest path="/test/servlet/params.Params"
method="POST"
param name="a" value="b" /
@@ -133,7 +133,7 @@
httpClient
commentPOST and GET parameters/comment
- httpRequest
+ httpRequest
path="/test/servlet/params.Params"
method="POST"
param name="a" value="x" type="GET" /
@@ -214,7 +214,7 @@
/httpRequest
responseMatch match="before:a = [ k , m ]" /
responseMatch match="before:c = [ l ]" /
- responseMatch
+ responseMatch
match="Calling RD.include for: params.Params/include1?a=b"/
responseMatch match="/include1:a = [ b , k , m ]" /
responseMatch match="/include1:c = [ l ]" /
@@ -339,9 +339,9 @@
target name="dispatch" depends="init"
gtest description="SimpleInclude"
request="GET /test/servlet/dispatch.SimpleIncludeServlet HTTP/1.0"
- expectHeaders="Content-Type:text/foobar"
+ expectHeaders="Content-Type:text/foobar"
returnCode="${http.protocol} 200"
- goldenFile="${gdir}/SimpleInclude.txt"
+ goldenFile="${gdir}/SimpleInclude.txt"
/
gtest description="SimpleForward"
request="GET /test/servlet/dispatch.SimpleForwardServlet HTTP/1.0"
@@ -1107,11 +1107,27 @@
request="GET /test/jsp/HelloWorld.jsp%20 HTTP/1.0"
returnCode="${http.protocol} 404"
/
+ /target
+ target name="writer"
+ httpClient
+ commentWriter test, closing writer at end/comment
+ httpRequest path="/test/servlet/CloseWriter" /
+ httpStatusMatch match="200" /
+ headerMatch name="Content-Type" value="text/plain" /
+ goldenMatch
Re: [PROPOSAL] Tomcat 4 unpacking of WAR files behavior
"Craig R. McClanahan" wrote: Remy Maucherat wrote: The original rationale for the current behavior was/is a very common user error with Tomcat 3.x -- it goes like this: * User drops a WAR file into "webapps" and restarts Tomcat * Tomcat auto-expands the WAR and runs fine * User updates the app, drops in an updated WAR, and restarts Tomcat * Tomcat sees the expanded directory, and does NOT auto-expand * User files a bug report "Tomcat does not reload my updated classes" :-( I'm open to suggestion for different behavior, but keep this scenario in mind. That "problem" is taken care of if the user configures the Context with unpackWARs="false", and can be documented in the user config docs. The current behaviour could lead to other bug reports, "I changed some files in an expanded WAR file, but when I restarted Tomcat my changes are missing". [PROPOSAL] Tomcat Startup ** If unpackWARs="false" - If a new war file exists with no corresponding expanded war file - The war file componenets are expanded out as needed into the work dir. Until Jasper is fixed (if it is ever fixed). It is possible to know whether or not a context uses Jasper, so this operation could be smarter. If a war file with a last mod time newer than the unpacked war file components exists - The previous war file components are removed, then the war file components are expanded as needed into work dir. That looks a bit too risky ... I wouldn't remove anything in that case just to be safe. If unpackWARs="true" A war file exits, but no directory exists matching war file prefix. - create directory name matching war file prefix and expand war file. A war file exists, and a corresponding directory exists. The war file last mod time is older than directory. - Don't expand war file. A war file exists, and a corresponding directory exists. The war file last mod time is newer than the directory. You have one of two cases: A completely different web app exists in a directory with the same name as a new war file. You wouldn't want Tomcat to overwrite another web app, how would you determine that the war file is not a replacement. An updated war file was installed and the directory is for the previously expanded version. What if the web app saves configuration info to property files in /WEB-INF/classes, or other data in /WEB-INF? In both cases I think you should not do anything, just log an information message to the Context log. Let the user decide, perhaps they could use the manager servlet to redploy a web app. +1. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: autoconf / automake
They are totally worth using. Once you get it right, they are a life saver and the work put into JServ can really be re-used here. Getting it right is the hard part. It needs a *lot* of testing. I know a little autoconf stuff and if Jserv allready used it so more than 80% of the work is allready done (libs, includes...). I could take a look at it for mod_jk 1.3/2.0 and mod_jserv. Another proof of all the good things that were allready in Jserv ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Some benchmarks
I need to choose for my company the "next generation" servlet-engine. For now we are using JRUN. I am doing benchmark to choose the next one. choices for me are : JRUN, RESIN... not Tomcat as it is considered not stable and slow compare to the two others... When you say that Tomcat is slow could you give numbers. ie : tomcat served 1000 req/s and Resin 3000 req/s - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Proposed ApacheConfig.java change
Costin, I would strongly vote for turning the auto-config back on by default for the following reasons (other than the fact that I explicity turned it back on when Keith fixed the ApacheConfig class): You don't need a "strong" vote - I'll do the change :-) 2) Configuration of mod_jk is notoriously complicated. Giving people the auto generated file is a big, big win. Wouldn't be enough to add a simple command line option ? For example, we have now a -enableAdmin ( to turn "trusted" on the /admin app ). We could add a "-generateConfig" - and everyone can be happy. ( plus - you'll not have problems with overriting the files ) ( unless you change your mind and agree with -generateConfig I'll just re-add the default behavior ) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Multiclient support in httpServer
Hello, Would somebody kind enough to tell me how to implement multiclient support in httpServer. I used Thread, but the server just accept only one request and abort. I could not know why? The following is what the system gave out: New connection from client1 GET /s1/page2.html HTTP/1.1Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword, */*Accept-Language: en-us,fi;q=0.5Accept-Encoding: gzip, deflateUser-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)Host: alpha.hut.fi:8088Connection: Keep-AliveSIGSEGV 11* segmentation violation si_signo [11]: SIGSEGV 11* segmentation violation si_errno [0]: Error 0 occurred. si_code [1]: SEGV_ACCERR [addr: 0x0] sc_pc: 0x3ffbff5c6f0, r26: 0x3ffbff5c6f0Full thread dump: "SIGQUIT handler" (TID:0x310590, sys_thread_t:0x400a7180, state:R, pthread_t: t@1074895232, sp:0x0 pc:0x0 threadID:0x140119980, stack_base:0x140117b10 stack_size:0x22000) prio=2 "Finalizer thread" (TID:0x310110, sys_thread_t:0x400a6f00, state:CW, pthread_t: t@1074739584, sp:0x1400f18d8 pc:0x3ffbff59db0 threadID:0x1400f3980, stack_base:0x1400f1b10 stack_size:0x22000) prio=2 "main" (TID:0x310160, sys_thread_t:0x400a6c80, state:R, pthread_t: t@-1072154992, sp:0x11fffea10 pc:0x3ffbff5c7c0 threadID:0x3ffc0183690, stack_base:0x11550 stack_size:0x20) prio=5 java.net.PlainSocketImpl.accept(Compiled Code) java.net.ServerSocket.implAccept(Compiled Code) java.net.ServerSocket.accept(Compiled Code) hServer.main(Compiled Code)Monitor Cache Dump: java.net.PlainSocketImpl@317D40/368520: owner "main" (0x1400a6c80, 1 entry)Registered Monitor Dump: Thread queue lock: unowned Name and type hash table lock: unowned String intern lock: unowned JNI pinning lock: unowned JNI global reference lock: unowned BinClass lock: unowned Class loading lock: unowned Java stack lock: unowned Code rewrite lock: unowned Heap lock: unowned Has finalization queue lock: unowned Finalize me queue lock: unowned Waiting to be notified: "Finalizer thread" (0x1400a6f00) Monitor registry: unownedAbort
cvs commit: jakarta-tomcat/src/share/org/apache/jasper/runtime BodyContentImpl.java
marcsaeg01/03/03 19:26:22
Modified:src/share/org/apache/jasper/runtime Tag: tomcat_32
BodyContentImpl.java
Log:
BodyContentImpl.java
Revision ChangesPath
No revision
No revision
1.6.6.1 +6 -8
jakarta-tomcat/src/share/org/apache/jasper/runtime/BodyContentImpl.java
Index: BodyContentImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/runtime/BodyContentImpl.java,v
retrieving revision 1.6
retrieving revision 1.6.6.1
diff -u -r1.6 -r1.6.6.1
--- BodyContentImpl.java 1999/11/13 00:32:51 1.6
+++ BodyContentImpl.java 2001/03/04 03:26:21 1.6.6.1
@@ -88,7 +88,7 @@
super(writer);
cb = new char[bufferSize];
nextChar = 0;
-}
+ }
/**
* Write a single character.
@@ -107,19 +107,19 @@
//Need to re-allocate the buffer since it is to be
//unbounded according to the updated spec..
-char[] tmp = new char [bufferSize];
- System.arraycopy(cb, 0, tmp, 0, cb.length);
+char[] tmp = null;
//XXX Should it be multiple of DEFAULT_BUFFER_SIZE??
if (len = Constants.DEFAULT_BUFFER_SIZE) {
- cb = new char [bufferSize + Constants.DEFAULT_BUFFER_SIZE];
+ tmp = new char [bufferSize + Constants.DEFAULT_BUFFER_SIZE];
bufferSize += Constants.DEFAULT_BUFFER_SIZE;
} else {
- cb = new char [bufferSize + len];
+ tmp = new char [bufferSize + len];
bufferSize += len;
}
- System.arraycopy(tmp, 0, cb, 0, tmp.length);
+ System.arraycopy(cb, 0, tmp, 0, cb.length);
+ cb = tmp;
tmp = null;
}
@@ -499,8 +499,6 @@
public void clear() throws IOException {
synchronized (lock) {
-cb = new char [Constants.DEFAULT_BUFFER_SIZE];
- bufferSize = Constants.DEFAULT_BUFFER_SIZE;
nextChar = 0;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat build.xml
costin 01/03/03 19:27:26
Modified:.build.xml
Log:
Implement the proposed change in lib/ organization.
lib/apps will contain jars shared by web applications ( prev. "share" )
lib/common will contain jars shared by the container and web applications
( same as CLASSPATH )
lib/container will contain jars visible and used by the container (
previously lib/ )
In lib we keep the executable jars used to start/stop tomcat.
Also, integrate this into the prepare target, and generate the jars
in the final place ( instead of copy/move )
Another change is the split of jasper into jasper-runtime and jasper.
Runtime is all you need to run Jsps, jasper is the compiler.
The utils are also split in "core_util" - i.e. what's needed in the
core, and "tomcat_util" - other utils used by various modules.
This makes clear what are the dependencies, and will allow finer
permissions.
Revision ChangesPath
1.119 +68 -43jakarta-tomcat/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat/build.xml,v
retrieving revision 1.118
retrieving revision 1.119
diff -u -r1.118 -r1.119
--- build.xml 2001/02/19 19:45:11 1.118
+++ build.xml 2001/03/04 03:27:25 1.119
@@ -47,6 +47,9 @@
mkdir dir="${tomcat.build}/conf"/
mkdir dir="${tomcat.build}/src"/
mkdir dir="${tomcat.build}/lib"/
+mkdir dir="${tomcat.build}/lib/apps"/
+mkdir dir="${tomcat.build}/lib/container"/
+mkdir dir="${tomcat.build}/lib/common"/
mkdir dir="${tomcat.build}/logs"/
mkdir dir="${tomcat.build}/bin"/
mkdir dir="${tomcat.build}/doc"/
@@ -72,19 +75,33 @@
copy todir="${tomcat.build}/bin"
fileset dir="${ant.home}/bin"/
/copy
-copy tofile="${tomcat.build}/lib/jaxp.jar"
+copy tofile="${tomcat.build}/lib/container/jaxp.jar"
file="${ant.home}/lib/jaxp.jar"/
-copy tofile="${tomcat.build}/lib/parser.jar"
+copy tofile="${tomcat.build}/lib/container/parser.jar"
file="${ant.home}/lib/parser.jar"/
-copy tofile="${tomcat.build}/lib/jaxp.jar" file="${jaxp}/jaxp.jar"/
-copy tofile="${tomcat.build}/lib/parser.jar" file="${jaxp}/parser.jar"/
-copy tofile="${tomcat.build}/lib/jaxp.jar" file="${jaxp}/jaxp.jar"/
-copy tofile="${tomcat.build}/lib/crimson.jar" file="${jaxp}/crimson.jar"/
+copy tofile="${tomcat.build}/lib/container/jaxp.jar"
+ file="${jaxp}/jaxp.jar"/
+copy tofile="${tomcat.build}/lib/container/parser.jar"
+ file="${jaxp}/parser.jar"/
+copy tofile="${tomcat.build}/lib/container/jaxp.jar"
+ file="${jaxp}/jaxp.jar"/
+copy tofile="${tomcat.build}/lib/container/crimson.jar"
+ file="${jaxp}/crimson.jar"/
+copy file ="src/build/readme.container"
+ tofile="${tomcat.build}/lib/container/README" /
+
+copy file ="src/build/readme.shared"
+ tofile="${tomcat.build}/lib/apps/README" /
+
+copy file ="src/build/readme.common"
+ tofile="${tomcat.build}/lib/common/README" /
+
!-- This act as a "default", Tomcat3.3 will not load it in
classpath, just a hack to ease the transition
--
-copy tofile="${tomcat.build}/lib/servlet.jar" file="${servlet22.jar}"/
+copy tofile="${tomcat.build}/lib/common/servlet.jar"
+ file="${servlet22.jar}"/
fixcrlf srcdir="${tomcat.build}/bin" includes="**/*.sh" cr="remove"/
fixcrlf srcdir="${tomcat.build}/bin" includes="**/*.bat" cr="add"/
@@ -111,10 +128,20 @@
exclude name="**/util/net/SSLSocketFactory.java" unless="jsse.present"/
exclude name="**/util/compat/Jdk12Support.java" unless="jdk12.present"/
/javac
-jar jarfile="${tomcat.build}/lib/tomcat_util.jar"
+
+jar jarfile="${tomcat.build}/lib/common/core_util.jar"
+ basedir="${tomcat.build}/classes"
+ include name="org/apache/tomcat/util/log/**"/
+ include name="org/apache/tomcat/util/collections/**"/
+ include name="org/apache/tomcat/util/hooks/**"/
+ include name="org/apache/tomcat/util/http/**"/
+ include name="org/apache/tomcat/util/res/**"/
+ include name="org/apache/tomcat/util/buf/**"/
+/jar
+
+jar jarfile="${tomcat.build}/lib/container/tomcat_util.jar"
basedir="${tomcat.build}/classes"
include name="org/apache/tomcat/util/**"/
- include name="org/apache/tomcat/logging/**"/
/jar
/target
@@ -158,11 +185,12 @@
include name="**/*.dtd"/
/fileset
/copy
+
jar jarfile="${tomcat.build}/lib/stop-tomcat.jar"
basedir="${tomcat.build}/classes"
manifest="src/build/manifest.stop-tomcat"
include
cvs commit: jakarta-tomcat/src/share/org/apache/jasper/runtime package.html
costin 01/03/03 19:29:08 Modified:src/share/org/apache/jasper/runtime package.html Log: Added the resources to the list of deps for runtime. Revision ChangesPath 1.2 +1 -0 jakarta-tomcat/src/share/org/apache/jasper/runtime/package.html Index: package.html === RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/runtime/package.html,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- package.html 2001/03/02 06:54:13 1.1 +++ package.html 2001/03/04 03:29:08 1.2 @@ -13,6 +13,7 @@ A servlet generated by jasper will depend at runtime on the following: org.apache.jasper.runtime.* ( act as a facade ) +org.apache.jasper.resources.* org.apache.jasper.Constants org.apache.jasper.JasperException - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core BaseInterceptor.java ContextManager.java package.html
costin 01/03/03 19:31:52
Modified:src/share/org/apache/tomcat/core BaseInterceptor.java
ContextManager.java package.html
Log:
Few more changes in the core:
- added the getNote/setNote hooks, will be used later to allow
lazy-evaluation for notes and fix the few remaining request properties
that are not "lazy" ( SSL attributes, etc ), and provide a simple
mechanism to plug encoding modules.
- Fix in ContextManager, make sure the per/context modules are called.
- Removed the dependencies that are no longer valid.
Revision ChangesPath
1.43 +7 -10
jakarta-tomcat/src/share/org/apache/tomcat/core/BaseInterceptor.java
Index: BaseInterceptor.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/BaseInterceptor.java,v
retrieving revision 1.42
retrieving revision 1.43
diff -u -r1.42 -r1.43
--- BaseInterceptor.java 2001/02/20 03:17:56 1.42
+++ BaseInterceptor.java 2001/03/04 03:31:52 1.43
@@ -176,16 +176,6 @@
return 0;
}
-// /** New Session notification - called when the servlet
-// asks for a new session. You can do all kind of stuff with
-// this notification - the most important is create a session
-// object. This will be the base for controling the
-// session allocation.
-// */
-// public int newSessionRequest( Request request, Response response) {
-// return 0;
-// }
-
/** The hook for session managers. It'll be called to
* find or create a ServerSession object associated with a request.
*
@@ -263,6 +253,13 @@
return 0;
}
+public Object getNote( Request request, int id ) {
+ return null;
+}
+
+public int setNote( Request request, int id, Object obj ) {
+ return DECLINED;
+}
/** This callback is called whenever an exception happen.
* If t is null assume this is a "status" report ( 500, 404, etc).
1.171 +7 -4
jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java
Index: ContextManager.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java,v
retrieving revision 1.170
retrieving revision 1.171
diff -u -r1.170 -r1.171
--- ContextManager.java 2001/02/25 17:47:16 1.170
+++ ContextManager.java 2001/03/04 03:31:52 1.171
@@ -704,7 +704,7 @@
handleError( req, res, ex );
}
finally {
- BaseInterceptor reqI[]= req.getContainer().
+ BaseInterceptor reqI[]= req.getContext().getContainer().
getInterceptors(Container.H_postRequest);
for( int i=0; i reqI.length; i++ ) {
@@ -807,7 +807,8 @@
handleStatus( req, req.getResponse(), 503 ); // service unavailable
}
- ri=defaultContainer.getInterceptors(Container.H_requestMap);
+ ri=req.getContext().getContainer().
+ getInterceptors(Container.H_requestMap);
for( int i=0; i ri.length; i++ ) {
if( debug 1 )
log( "RequestMap " + ri[i] );
@@ -913,7 +914,8 @@
BaseInterceptor ri[];
int status;
- ri=req.getContainer().getInterceptors( Container.H_handleError );
+ ri=req.getContext().getContainer().
+ getInterceptors( Container.H_handleError );
for( int i=0; i ri.length; i++ ) {
status=ri[i].handleError( req, res, null );
@@ -927,7 +929,8 @@
public final void handleError( Request req, Response res , Throwable t ) {
BaseInterceptor ri[];
int status;
- ri=req.getContainer().getInterceptors( Container.H_handleError );
+ ri=req.getContext().getContainer().
+ getInterceptors( Container.H_handleError );
for( int i=0; i ri.length; i++ ) {
status=ri[i].handleError( req, res, t );
if( status!=0 ) return;
1.8 +0 -5 jakarta-tomcat/src/share/org/apache/tomcat/core/package.html
Index: package.html
===
RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/package.html,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- package.html 2001/02/27 18:21:58 1.7
+++ package.html 2001/03/04 03:31:52 1.8
@@ -94,11 +94,6 @@
liorg.apache.tomcat.util.http.*/li
liorg.apache.tomcat.util.res.StringManager/li
liorg.apache.tomcat.util.buf.MessageBytes;/li
-
-
- liorg.apache.tomcat.util.threads.TimeStamp: ServerSession/rm /li
-
- liorg.apache.tomcat.util.SimplePrincipal - Request/-facade/li
/ul
Indirect dependencies:
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/startup Main.java
costin 01/03/03 19:36:52
Modified:src/share/org/apache/tomcat/startup Main.java
Log:
The new lib structure - change the Main for that.
Also: classes/ are no longer included ( the build is generating the right
jars, having the expanded classes may affect the testing in build
versus dist )
Revision ChangesPath
1.27 +7 -7 jakarta-tomcat/src/share/org/apache/tomcat/startup/Main.java
Index: Main.java
===
RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/startup/Main.java,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- Main.java 2001/02/26 09:42:30 1.26
+++ Main.java 2001/03/04 03:36:52 1.27
@@ -1,4 +1,4 @@
-/* $Id: Main.java,v 1.26 2001/02/26 09:42:30 nacho Exp $
+/* $Id: Main.java,v 1.27 2001/03/04 03:36:52 costin Exp $
*
*
* The Apache Software License, Version 1.1
@@ -102,7 +102,7 @@
@author Costin Manolache
@author Ignacio J. Ortega
@author Mel Martinez [EMAIL PROTECTED]
- @version $Revision: 1.26 $ $Date: 2001/02/26 09:42:30 $
+ @version $Revision: 1.27 $ $Date: 2001/03/04 03:36:52 $
*/
public class Main {
@@ -227,9 +227,9 @@
return libBase;
}
if( homeDir!=null ){
-libBase=checkDir( homeDir + "/lib");
+libBase=checkDir( homeDir + "/lib/container");
}else{
-libBase=checkDir("./lib");
+libBase=checkDir("./lib/container");
}
return libBase;
}
@@ -239,9 +239,9 @@
return serverBase;
}
if( homeDir!=null ){
-serverBase=checkDir( homeDir + "/lib/shared");
+serverBase=checkDir( homeDir + "/lib/apps");
}else{
-serverBase=checkDir("./lib/shared");
+serverBase=checkDir("./lib/apps");
}
return serverBase;
}
@@ -271,7 +271,7 @@
// the server classloader loads from classes dir too and from tools.jar
Vector serverJars=new Vector();
-serverJars.addElement( getURL( getServerDir() ,"../classes/" ));
+//serverJars.addElement( getURL( getServerDir() ,"../classes/" ));
Vector serverUrlV =getClassPathV(getServerDir());
for(int i=0; i serverUrlV.size();i++){
serverJars.addElement(serverUrlV.elementAt(i));
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util IntrospectionUtils.java
costin 01/03/03 19:37:16
Modified:src/share/org/apache/tomcat/util IntrospectionUtils.java
Log:
Added few more introspection tools.
Revision ChangesPath
1.5 +106 -0
jakarta-tomcat/src/share/org/apache/tomcat/util/IntrospectionUtils.java
Index: IntrospectionUtils.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/IntrospectionUtils.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- IntrospectionUtils.java 2001/01/20 21:44:39 1.4
+++ IntrospectionUtils.java 2001/03/04 03:37:16 1.5
@@ -191,4 +191,110 @@
}
return null;
}
+
+
+/** Find a method with the right name
+ If found, call the method ( if param is int or boolean we'll convert
+ value to the right type before) - that means you can have setDebug(1).
+*/
+public static void setProperty( Object o, String name, String value )
+{
+ if( dbg 1 ) d("setProperty(" +
+ o.getClass() + " " + name + "=" +
+ value +")" );
+
+ String setter= "set" +capitalize(name);
+
+ try {
+ Method methods[]=o.getClass().getMethods();
+ Method setPropertyMethod=null;
+
+ // First, the ideal case - a setFoo( String ) method
+ for( int i=0; i methods.length; i++ ) {
+ Class paramT[]=methods[i].getParameterTypes();
+ if( setter.equals( methods[i].getName() )
+ paramT.length == 1
+ "java.lang.String".equals( paramT[0].getName())) {
+
+ methods[i].invoke( o, new Object[] { value } );
+ return;
+ }
+ }
+
+ // Try a setFoo ( int ) or ( boolean )
+ for( int i=0; i methods.length; i++ ) {
+ boolean ok=true;
+ if( setter.equals( methods[i].getName() )
+ methods[i].getParameterTypes().length == 1) {
+
+ // match - find the type and invoke it
+ Class paramType=methods[i].getParameterTypes()[0];
+ Object params[]=new Object[1];
+ if ("java.lang.Integer".equals( paramType.getName()) ||
+ "int".equals( paramType.getName())) {
+ try {
+ params[0]=new Integer(value);
+ } catch( NumberFormatException ex ) {ok=false;}
+ } else if ("java.lang.Boolean".
+equals( paramType.getName()) ||
+ "boolean".equals( paramType.getName())) {
+ params[0]=new Boolean(value);
+ } else {
+ d("Unknown type " + paramType.getName() );
+ }
+
+ if( ok ) {
+ methods[i].invoke( o, params );
+ return;
+ }
+ }
+
+ // save "setProperty" for later
+ if( "setProperty".equals( methods[i].getName())) {
+ setPropertyMethod=methods[i];
+ }
+ }
+
+ // Ok, no setXXX found, try a setProperty("name", "value")
+ if( setPropertyMethod != null ) {
+ Object params[]=new Object[2];
+ params[0]=name;
+ params[1]=value;
+ setPropertyMethod.invoke( o, params );
+ }
+
+ } catch( SecurityException ex1 ) {
+ if( dbg 0 )
+ d("SecurityException for " + o.getClass() + " " +
+ name + "=" + value +")" );
+ if( dbg 1 ) ex1.printStackTrace();
+ } catch (IllegalAccessException iae) {
+ if( dbg 0 )
+ d("IllegalAccessException for " +
+ o.getClass() + " " + name + "=" + value +")" );
+ if( dbg 1 ) iae.printStackTrace();
+ } catch (InvocationTargetException ie) {
+ if( dbg 0 )
+ d("InvocationTargetException for " + o.getClass() +
+ " " + name + "=" + value +")" );
+ if( dbg 1 ) ie.printStackTrace();
+ }
+}
+
+/** Reverse of Introspector.decapitalize
+ */
+public static String capitalize(String name) {
+ if (name == null || name.length() == 0) {
+ return name;
+ }
+ char chars[] = name.toCharArray();
+ chars[0] = Character.toUpperCase(chars[0]);
+ return new String(chars);
+}
+
+// debug
+static final int dbg=0;
+static void d(String s ) {
+ System.out.println("IntrospectionUtils: " + s );
+}
}
-
To unsubscribe,
cvs commit: jakarta-tomcat/src/share/org/apache/jasper/runtime BodyContentImpl.java
marcsaeg01/03/03 19:42:20
Modified:src/share/org/apache/jasper/runtime Tag: tomcat_32
BodyContentImpl.java
Log:
I somehow commited the previous revision without a log message. This update
improves buffer allocation to increase performance. Submitted by Casey Lucas
[EMAIL PROTECTED].
Revision ChangesPath
No revision
No revision
1.6.6.2 +1 -1
jakarta-tomcat/src/share/org/apache/jasper/runtime/BodyContentImpl.java
Index: BodyContentImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/runtime/BodyContentImpl.java,v
retrieving revision 1.6.6.1
retrieving revision 1.6.6.2
diff -u -r1.6.6.1 -r1.6.6.2
--- BodyContentImpl.java 2001/03/04 03:26:21 1.6.6.1
+++ BodyContentImpl.java 2001/03/04 03:42:19 1.6.6.2
@@ -105,7 +105,7 @@
private void reAllocBuff (int len) {
//Need to re-allocate the buffer since it is to be
- //unbounded according to the updated spec..
+ //unbounded according to the updated spec..
char[] tmp = null;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Proposed ApacheConfig.java change
FYI: I'm pretty much done with the mods I wanted to make (I ended up adding a few extras) and am in the testing and documenting phase. Should be ready tomorrow. BTW: I figured out soon after my last post that the only thing I needed to do enable auto-generation of apache config files was to insert an ApacheConfig/ config intercepter element inside the ContextManager tag like so: ContextManager ... ... ApacheConfig / ... /ContextManager That returned it to the default 3.2.1 behavior. --- Dan Milstein [EMAIL PROTECTED] wrote: I would strongly vote for turning the auto-config back on by default for the following reasons (other than the fact that I explicity turned it back on when Keith fixed the ApacheConfig class): 1) This is how 3.2 worked, and how the docs specify that 3.3 works. I think that that is a strong argument in favor of having it enabled. The cost in startup performance is negligible and runtime is essentially zero so I advocate defaulting it to enabled. At a minimum, the ApacheConfig element should be present in the server.xml file to comment/uncomment out to toggle. 2) Configuration of mod_jk is notoriously complicated. Giving people the auto generated file is a big, big win. Aside from the proposed mod to make the LoadModule statement conditional, I've also added some attributes to the ApacheConfig / tag that should greatly help setting up Apache and Tomcat together: confighome - default parent directory for the following paths. If not set, this defaults to TOMCAT_HOME. Ignored whenever any of the following paths is absolute. jservconfig - path to write apache jserv conf file to. If not set, defaults to "conf/jserv/tomcat-apache.conf". jkconfig - path to write apacke mod_jk conf file to. If not set, defaults to "conf/jk/mod_jk.conf". workersconfig - path to workers.properties file used by mod_jk. If not set, defaults to "conf/jk/workers.properties". modjserv - path to Apache JServ plugin module file. If not set, defaults to "modules/ApacheModuleJServ.dll" on windows, "modules/Jserv.nlm" on netware, and "libexec/mod_jserv.so" everywhere else. modjk - path to Apache mod_jk plugin file. If not set, defaults to "modules/mod_jk.dll" on windows, "modules/mod_jk.nlm" on netware, and "libexec/mod_jk.so" everywhere else. jklog - path to log file to be used by mod_jk. All of these attributes are optional. 3) For the people who run it in standalone, we can provide a comment in the file telling them to "comment out the below". That way it would work out of the box for both types (standalone + behind Apache), and be very easy for people to tune to their needs. Since the syntax has changed (and I've never been a server.xml master), I'm not sure where the AutoConfig stuff would go now. Lemme know if you guys like/dislike the above changes. I should be able to have it ready early tomorrow (Sunday). I will post a PATCH version first so I can get some feedback on test configurations I don't have available. Mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
