Re: [5.0.17] Build available
Remy Maucherat wrote: Hi, Tomcat 5.0.17 Alpha is now available for testing. http://www.apache.org/dist/jakarta/tomcat-5/v5.0.17-alpha/ Why the sources are under jakarta-tomcat-5.0.17-src/src and not under jakarta-tomcat-5.0.17-src directly? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Found it - WAS: Memory leak
Filip Hanik wrote:
Ok, I think I nailed it.
There is a memory leak in Tomcat 5. I downloaded a trial of JProbe (they
should provide free licenses for open source! :)
There is a class called o.a.coyote.RequestGroupInfo.java, in that class
there is a method called addRequestProcessor.
This method stores a reference to a RequestInfo object in an ArrayList, the
RequestInfo object has a reference to a Request object and that eventually
holds the reference to a MessageBytes/ByteChunk.
The nr of instances of ByteChunk and CharChunk keep growing and they never
get garbage collected.
To validate my thoughts, I commented out the line
public void addRequestProcessor( RequestInfo rp ) {
//processor.add( rp );
}
in RequestGroupInfo.java and now the instance count for ByteChunk stay
constant.
I have a feeling that the actual solution is a little bit deeper down, right
now I am eager on getting the clustering to perform the way I want, so if
someone wants to take this on be my guest and let me know. If I don't hear
from anyone, I will commit a solution to this next week.
-1. There is no memory leak with this.
ByteChunks/CharChunks are always reused. If new ones are created, they
will be reused.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Found it - WAS: Memory leak
Bill Barker wrote: I'd be in favor of just dropping RequestInfo and RequestGroupInfo altogether (and provide RequestListener commented out in web.xml that does the same thing). Then people that want this can still get Request stats via JMX (which I might use on a development site, but never on a production site). And as a bonus, we get to ship an example of a RequestListener :). Removing isn't hard (I've just done it for my downloaded version of 5.0.17). The original code isn't very careful about what operations are atomic, so a replacement Listener that's as good as RequestGroupInfo isn't hard to do either :). -1. Please reconsider. There is no memory leak, please check for yourself. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.17] Build available
Remy Maucherat wrote:
Hi,
Tomcat 5.0.17 Alpha is now available for testing.
http://www.apache.org/dist/jakarta/tomcat-5/v5.0.17-alpha/
Where is the build.xml comming from?
I would like to fix things like:
available property=source.exists file=${basedir}/${tomcat.project} /
type=dir is missing.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.17] Build available
jean-frederic clere wrote: Remy Maucherat wrote: Hi, Tomcat 5.0.17 Alpha is now available for testing. http://www.apache.org/dist/jakarta/tomcat-5/v5.0.17-alpha/ Why the sources are under jakarta-tomcat-5.0.17-src/src and not under jakarta-tomcat-5.0.17-src directly? Only in the .tar.gz, and likely because I switched to Ant 1.6. It shouldn't break anything, though. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.17] Build available
jean-frederic clere wrote:
Remy Maucherat wrote:
Hi,
Tomcat 5.0.17 Alpha is now available for testing.
http://www.apache.org/dist/jakarta/tomcat-5/v5.0.17-alpha/
Where is the build.xml comming from?
I would like to fix things like:
available property=source.exists file=${basedir}/${tomcat.project} /
type=dir is missing.
Last time I checked, the build was working.
The build.xml in the src distribution is in
jakarta-tomcat-5/resources/build.xml
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 build.xml
remm2004/01/15 01:38:49
Modified:.build.xml
Log:
- Make .tgz source package the same as the zip package. This wasn't Ant's
fault after all.
Revision ChangesPath
1.173 +2 -3 jakarta-tomcat-5/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
retrieving revision 1.172
retrieving revision 1.173
diff -u -r1.172 -r1.173
--- build.xml 19 Dec 2003 16:47:55 - 1.172
+++ build.xml 15 Jan 2004 09:38:49 - 1.173
@@ -1498,7 +1498,7 @@
excludes=**/*.jar,**/*.gif,**/*.bmp,**/*.jpg,**/*.ico eol=lf/
tar longfile=gnu compression=gzip
tarfile=${tomcat.release}/v${version}/src/${final-src.name}.tar.gz
- tarfileset dir=${tomcat.dist} mode=755 prefix=${final-src.name}
+ tarfileset dir=${tomcat.dist}/src mode=755 prefix=${final-src.name}
include name=${jtc.project}/jk/native/buildconf.sh /
include name=${jtc.project}/jk/native/apache-1.3/build-hpux-cc.sh /
include name=${jtc.project}/jk/native/apache-1.3/build-solaris.sh /
@@ -1507,8 +1507,7 @@
include name=${jtc.project}/jk/native/apache-2.0/install-unix.sh /
include name=${jtc.project}/jk/native/domino/mkini.sh /
/tarfileset
- tarfileset dir=${tomcat.dist} prefix=${final-src.name}
-include name=src/** /
+ tarfileset dir=${tomcat.dist}/src prefix=${final-src.name}
exclude name=${jtc.project}/jk/native/buildconf.sh /
exclude name=${jtc.project}/jk/native/apache-1.3/build-hpux-cc.sh /
exclude name=${jtc.project}/jk/native/apache-1.3/build-solaris.sh /
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5/resources build.xml
jfclere 2004/01/15 01:50:57
Modified:resources build.xml
Log:
without typedir ant always tries to checkout the sources from repos.
Revision ChangesPath
1.4 +3 -2 jakarta-tomcat-5/resources/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-5/resources/build.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- build.xml 8 Sep 2003 10:15:14 - 1.3
+++ build.xml 15 Jan 2004 09:50:56 - 1.4
@@ -88,14 +88,15 @@
target name=check.source
-available property=source.exists file=${basedir}/${tomcat.project} /
+available property=source.exists
+ file=${basedir}/${tomcat.project} type=dir /
/target
target name=check.source.depends
available property=source.depends.exists
- file=${basedir}/${commons-daemon.project} /
+ file=${basedir}/${commons-daemon.project} type=dir /
/target
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.17] Build available
Remy Maucherat wrote:
jean-frederic clere wrote:
Remy Maucherat wrote:
Hi,
Tomcat 5.0.17 Alpha is now available for testing.
http://www.apache.org/dist/jakarta/tomcat-5/v5.0.17-alpha/
Where is the build.xml comming from?
I would like to fix things like:
available property=source.exists
file=${basedir}/${tomcat.project} /
type=dir is missing.
Last time I checked, the build was working.
With ant 1.5.1 it always tries to checkout the sources from repos.
The build.xml in the src distribution is in
jakarta-tomcat-5/resources/build.xml
Fixed.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26162] New: - Typo in conf/server-minimal.xml
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26162. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26162 Typo in conf/server-minimal.xml Summary: Typo in conf/server-minimal.xml Product: Tomcat 5 Version: 5.0.17 Platform: Other OS/Version: Other Status: NEW Severity: Minor Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Line 14 has a typo which prevents the MemoryUserDatabaseFactory to work: namepathaame/name ^ should be changed to namepathname/name - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-servletapi-5/jsr152/examples/WEB-INF web.xml
remm2004/01/15 04:53:24 Modified:jsr152/examples/WEB-INF web.xml Log: - Bug 26147: Fix typo in schemaLocation. Revision ChangesPath 1.11 +1 -1 jakarta-servletapi-5/jsr152/examples/WEB-INF/web.xml Index: web.xml === RCS file: /home/cvs/jakarta-servletapi-5/jsr152/examples/WEB-INF/web.xml,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- web.xml 12 Aug 2003 19:41:23 - 1.10 +++ web.xml 15 Jan 2004 12:53:24 - 1.11 @@ -2,7 +2,7 @@ web-app xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; -xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee web-app_2_4.xsd +xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; version=2.4 description - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/conf server-minimal.xml
remm2004/01/15 04:54:54 Modified:catalina/src/conf server-minimal.xml Log: - Bug 26162: Fix typo. Revision ChangesPath 1.3 +1 -1 jakarta-tomcat-catalina/catalina/src/conf/server-minimal.xml Index: server-minimal.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/conf/server-minimal.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- server-minimal.xml3 Dec 2003 15:30:38 - 1.2 +++ server-minimal.xml15 Jan 2004 12:54:54 - 1.3 @@ -11,7 +11,7 @@ valueorg.apache.catalina.users.MemoryUserDatabaseFactory/value /parameter parameter -namepathaame/name +namepathname/name valueconf/tomcat-users.xml/value /parameter /ResourceParams - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26162] - Typo in conf/server-minimal.xml
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26162. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26162 Typo in conf/server-minimal.xml [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-01-15 12:58 --- Fixed. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Protocol.java
remm2004/01/15 05:16:41 Modified:http11/src/java/org/apache/coyote/http11 Http11Protocol.java Log: - Properly remove the RequestInfo from the request group on thread end. Revision ChangesPath 1.46 +4 -0 jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Protocol.java Index: Http11Protocol.java === RCS file: /home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Protocol.java,v retrieving revision 1.45 retrieving revision 1.46 diff -u -r1.45 -r1.46 --- Http11Protocol.java 25 Nov 2003 01:26:26 - 1.45 +++ Http11Protocol.java 15 Jan 2004 13:16:41 - 1.46 @@ -614,6 +614,10 @@ ObjectName oname=(ObjectName)tpData[Http11Protocol.THREAD_DATA_OBJECT_NAME]; if( oname==null ) return; Registry.getRegistry().unregisterComponent(oname); +Http11Processor processor = +(Http11Processor) tpData[Http11Protocol.THREAD_DATA_PROCESSOR]; +RequestInfo rp=processor.getRequest().getRequestProcessor(); +rp.setGlobalProcessor(null); } } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote RequestGroupInfo.java RequestInfo.java
remm2004/01/15 05:16:49
Modified:coyote/src/java/org/apache/coyote RequestGroupInfo.java
RequestInfo.java
Log:
- Properly remove the RequestInfo from the request group on thread end.
Revision ChangesPath
1.2 +4 -0
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/RequestGroupInfo.java
Index: RequestGroupInfo.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/RequestGroupInfo.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- RequestGroupInfo.java 20 Jan 2003 23:43:41 - 1.1
+++ RequestGroupInfo.java 15 Jan 2004 13:16:49 - 1.2
@@ -13,6 +13,10 @@
processors.add( rp );
}
+public void removeRequestProcessor( RequestInfo rp ) {
+processors.remove( rp );
+}
+
public long getMaxTime() {
long maxTime=0;
for( int i=0; iprocessors.size(); i++ ) {
1.7 +3 -0
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/RequestInfo.java
Index: RequestInfo.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/RequestInfo.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- RequestInfo.java 13 Nov 2003 20:03:33 - 1.6
+++ RequestInfo.java 15 Jan 2004 13:16:49 - 1.7
@@ -92,6 +92,9 @@
if( global != null) {
this.global=global;
global.addRequestProcessor( this );
+} else {
+this.global.removeRequestProcessor( this );
+this.global = null;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Found it - WAS: Memory leak
Remy Maucherat wrote: -1. There is no memory leak with this. ByteChunks/CharChunks are always reused. If new ones are created, they will be reused. Arg, I have to find something. I know ! It's all Costin's fault ! I didn't think about the scaling back feature of the thread pool, to be honest. It should be very easy to avoid the problem, by setting maxSpareThreads to maxThreads. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26147] - xsi:schemaLocation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26147. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26147 xsi:schemaLocation [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-01-15 13:24 --- Fixed. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Found it - WAS: Memory leak
Howdy,
+1 one having a RequestListener -- I've been looking for a non-trivial example to
write and ship along with tomcat!
Yoav Shapira
Millennium ChemInformatics
-Original Message-
From: Bill Barker [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 14, 2004 11:07 PM
To: Tomcat Developers List
Subject: Re: Found it - WAS: Memory leak
I'd be in favor of just dropping RequestInfo and RequestGroupInfo
altogether
(and provide RequestListener commented out in web.xml that does the same
thing). Then people that want this can still get Request stats via JMX
(which I might use on a development site, but never on a production site).
And as a bonus, we get to ship an example of a RequestListener :).
Removing isn't hard (I've just done it for my downloaded version of
5.0.17).
The original code isn't very careful about what operations are atomic, so a
replacement Listener that's as good as RequestGroupInfo isn't hard to do
either :).
- Original Message -
From: Filip Hanik [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Wednesday, January 14, 2004 6:47 PM
Subject: Found it - WAS: Memory leak
Ok, I think I nailed it.
There is a memory leak in Tomcat 5. I downloaded a trial of JProbe (they
should provide free licenses for open source! :)
There is a class called o.a.coyote.RequestGroupInfo.java, in that class
there is a method called addRequestProcessor.
This method stores a reference to a RequestInfo object in an ArrayList,
the
RequestInfo object has a reference to a Request object and that
eventually
holds the reference to a MessageBytes/ByteChunk.
The nr of instances of ByteChunk and CharChunk keep growing and they
never
get garbage collected.
To validate my thoughts, I commented out the line
public void addRequestProcessor( RequestInfo rp ) {
//processor.add( rp );
}
in RequestGroupInfo.java and now the instance count for ByteChunk stay
constant.
I have a feeling that the actual solution is a little bit deeper down,
right
now I am eager on getting the clustering to perform the way I want, so if
someone wants to take this on be my guest and let me know. If I don't
hear
from anyone, I will commit a solution to this next week.
Filip
-Original Message-
From: Filip Hanik [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 14, 2004 5:22 PM
To: Tomcat Developers List
Subject: RE: Memory leak- yeah I know
RE: Memory leak- yeah I knowhi Michael, thanks for your info. I will look
into that as well and set those settings
The thing I am investigating right now is if the fact that we are
registering a lot of things with JMX causes some references to never be
released.
more info to follow.
Filip
-Original Message-
From: Michael Yates [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 14, 2004 4:43 PM
To: Tomcat Developers List
Subject: RE: Memory leak- yeah I know
Filip,
I spent some time a while back trying to get some reproducibility into
memory use in Tomcat (4.1.24)
I found that even sitting idle tomcats memory use would increase.
Here is my original mail to the tomcat-dev mailing list
4.1.24 secure connector throws a LOT of garbage
After I did some more investigations and figured out a fix the
following
bug was raised
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19264
To reduce the amount of garbage thrown by tomcat I would recommend two
things, doing these might help you track down other memory issues.
1 - Use -XmxsomeValuem -XmssomeValuem.
The above sizes the heap to whatever value you put in there (note the
value is megabytes). I found (at least on the Solaris JVM) that sizing
the
heap and making the min and max heap sizes the same not only sped up
start
up but also made the garbage collector behave much better.
2- Set the serverSoTimeout value to 0 in the connector configuration in
your server configuration file. This will prevent the sever socket timing
out. Which DOES throw garbage, and if it is a secure connector you are
using
it throws SO much garbage that the garbage collector can not keep up too
well.
Using just number tip 1 above (as the fix to the bug above wasn't in
Tomcat 4.1.x before we needed to go into production. We managed to run at
something like 100 TPS for 48 hours with no falling over and no net
increase
in memory usage.
If you need any more information on the above let me know.
Michael Yates
Software Engineer, Location Center
Nortel Networks Wollongong, Australia.
-Original Message-
From: Filip Hanik [mailto:[EMAIL PROTECTED]
Sent: Thursday, 15 January 2004 11:09 AM
To: Tomcat Developers List
Subject: RE: Memory leak- yeah I know
Remy, absolutely no intentions of being sarcastic :), if there isn't a
leak, that is great, if there is, will fix it.
I'm trying to figure it out, I didn't ask anyone else to spend time on
it,
or even read my email. but if anyone is doing
Error in mod_jk Makefile?
I am trying to build mod_jk-1.2.5 from source on FreeBSD 4.9-RELEASE and I encounter at the end of the build process the following error: ... /usr/local/bin/bash /usr/local/apache/build/libtool --silent --mode=install cp `pwd`/mod_jk.so libtool: install: you must specify a destination Try `libtool --help --mode=install' for more information. *** Error code 1 Whe looking at the Makefile it looks like the build stops at that command: ... mod_jk.so: mod_jk.la $(LIBTOOL) --mode=install cp $ `pwd`/$@ ... Unfortunately, I have no expirience in writing Makefiles, however, it looks like that line does not work on FreeBSD. Anyone any idea to rewrite that line or to edit the command manually? Thanks. Dave. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Found it - WAS: Memory leak
Shapira, Yoav wrote: Howdy, +1 one having a RequestListener -- I've been looking for a non-trivial example to write and ship along with tomcat! -0. This kind of stuff is already in the servlet API to some extent, and all these event notifications will likely introduce overhead. This looks like a bad idea to me so far. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[5.0.18] New tag
I'll tag a new release today. This is sooo boring !! (why do people always find issues 5 minutes after I finish uploading/signing a release ?) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Error in mod_jk Makefile?
Gentlemen Is there a reason for tomcat use of makefiles? I have used Ant successfully for a number of engagements with spectacular results. The difference is like driving a yugo and a Ferrari..once you increase the amount of functionaility of your environment by 100 you will not go back Ant has the capability to compile and link any C++ file along with starting,stopping processes and emailing logs to admins..thats only the tip of it's capabilities. Has there been any effort to rewrite these makefiles to user friendly Ant build.xml? Thanks, Martin Gainty OOA/OOD Developer/Instructor - Original Message - From: David Meier [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 15, 2004 8:53 AM Subject: Error in mod_jk Makefile? I am trying to build mod_jk-1.2.5 from source on FreeBSD 4.9-RELEASE and I encounter at the end of the build process the following error: ... /usr/local/bin/bash /usr/local/apache/build/libtool --silent --mode=install cp `pwd`/mod_jk.so libtool: install: you must specify a destination Try `libtool --help --mode=install' for more information. *** Error code 1 Whe looking at the Makefile it looks like the build stops at that command: ... mod_jk.so: mod_jk.la $(LIBTOOL) --mode=install cp $ `pwd`/$@ ... Unfortunately, I have no expirience in writing Makefiles, however, it looks like that line does not work on FreeBSD. Anyone any idea to rewrite that line or to edit the command manually? Thanks. Dave. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 build.properties.default build.xml
jfclere 2004/01/15 06:37:38
Modified:.build.properties.default build.xml
Log:
Add jaxen/saxpath location.
Revision ChangesPath
1.117 +3 -1 jakarta-tomcat-5/build.properties.default
Index: build.properties.default
===
RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
retrieving revision 1.116
retrieving revision 1.117
diff -u -r1.116 -r1.117
--- build.properties.default 13 Jan 2004 14:32:29 - 1.116
+++ build.properties.default 15 Jan 2004 14:37:37 - 1.117
@@ -220,11 +220,13 @@
# - Jaxen ( required by taglibs/standard required by jasper ) -
jaxen.home=${base.path}/jaxen-1.0-FCS
jaxen.jar=${jaxen.home}/jaxen-full.jar
+jaxen.loc=${base-sf.loc}/jaxen/jaxen-1.0-FCS.tar.gz
# - Saxpath ( required by taglibs/standard required by jasper ) -
saxpath.home=${base.path}/saxpath-1.0-FCS
saxpath.jar=${saxpath.home}/saxpath.jar
+saxpath.loc=${base-sf.loc}/saxpath/saxpath-1.0.tar.gz
# - Java Database Connectivity (JDBC) Optional Package, version 2.0 -
1.174 +10 -0 jakarta-tomcat-5/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
retrieving revision 1.173
retrieving revision 1.174
diff -u -r1.173 -r1.174
--- build.xml 15 Jan 2004 09:38:49 - 1.173
+++ build.xml 15 Jan 2004 14:37:37 - 1.174
@@ -1630,6 +1630,16 @@
param name=destfile value=${commons-daemon.jar}/
/antcall
+antcall target=downloadgz
+ param name=sourcefile value=${jaxen.loc}/
+ param name=destfile value=${jaxen.jar}/
+/antcall
+
+antcall target=downloadgz
+ param name=sourcefile value=${saxpath.loc}/
+ param name=destfile value=${saxpath.jar}/
+/antcall
+
!-- Build the dependencies that are not yet released --
antcall target=build-depends/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
JAAS Jar not in server/lib for tomcat 5?
Hi, A user just noted that the jaas.jar that was present in server/lib for tomcat 4.1.x is missing in tomcat 5. Is this by design? If so, I'll add a note to the release notes. Or is this a simple mistake? Yoav Shapira Millennium ChemInformatics This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Error in mod_jk Makefile?
David Meier wrote: I am trying to build mod_jk-1.2.5 from source on FreeBSD 4.9-RELEASE and I encounter at the end of the build process the following error: ... /usr/local/bin/bash /usr/local/apache/build/libtool --silent --mode=install cp `pwd`/mod_jk.so libtool: install: you must specify a destination Try `libtool --help --mode=install' for more information. *** Error code 1 Whe looking at the Makefile it looks like the build stops at that command: ... mod_jk.so: mod_jk.la $(LIBTOOL) --mode=install cp $ `pwd`/$@ ... Unfortunately, I have no expirience in writing Makefiles, however, it looks like that line does not work on FreeBSD. Use gmake instead make (mod_jk needs a GNU make). Anyone any idea to rewrite that line or to edit the command manually? Thanks. Dave. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Bug 23929] - request.setCharacterEncoding(String) doesn't work
--- Additional Comments From [EMAIL PROTECTED] 2004-01-14 13:03 There is a standard for encoding URIs (http://www.w3.org/International/O-URL- code.html) but this standard is not consistently followed by clients. This causes a number of problems. ... 2. The Coyote HTTP/1.1 connector has a URIEncoding attribute which defaults to ISO-8859-1. Why is the default iso-8859-1, when the recommended encoding for URIs is UTF-8 ? That doesn't make sense. I found following in Tomcat-dev archive: Tomcat will default to US-ASCII instead of UTF-8 so it won't break too many existing webapps. If there are other parts to this story, I would be interested in learning of them. I think that it is false. If some webapplication did not care about i18n, it cannot be broken by using UTF-8 instead of ISO-8859-1. And if some webapplication used i18n, it was not using ISO-8859-1. By the way, there is no *standard* which says that URLs should be in UTF-8. http://www.w3.org/International/O-URL-code.html is not a standard, it is a web page in HintsTips section :-) The RFC 2396 (URI syntax) doesn't recommend utf-8, it just says that For example, UTF-8 [UTF-8] defines a mapping from sequences of octets to sequences of characters in the repertoire of ISO 10646. That's the only place where UTF-8 is mentioned in RFC 2396. The RFC 2718 (Guidelines for new URL Schemes) is talking about *new* URL schemes, not about the old http scheme. If anybody knows about any other standard which mandates UTF-8 for http URL, please let me know. Martin -- ~~ Supercomputing Center Brno Martin Kuba Institute of Computer Scienceemail: [EMAIL PROTECTED] Masaryk University http://www.ics.muni.cz/~makub/ Botanicka 68a, 60200 Brno, CZ mobil: +420-603-533775 -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
remm2004/01/15 07:32:05 Modified:webapps/docs changelog.xml Log: - Update changelog. Revision ChangesPath 1.33 +75 -0 jakarta-tomcat-catalina/webapps/docs/changelog.xml Index: changelog.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v retrieving revision 1.32 retrieving revision 1.33 diff -u -r1.32 -r1.33 --- changelog.xml 14 Jan 2004 12:53:42 - 1.32 +++ changelog.xml 15 Jan 2004 15:32:05 - 1.33 @@ -13,6 +13,81 @@ body +section name=Tomcat 5.0.18 (remm) + + subsection name=General + +changelog + + fix + Fix packaging of the source .tar.gz (remm) + /fix + fix + Fix bug in the netbuild where the script would always attempt to + checkout the sources (jfclere) + /fix + fix + bug26162/bug: Fix typo in the minimal config (remm) + /fix + +/changelog + + /subsection + + subsection name=Catalina + +changelog + + fix + Remove CGI servlet dependency on JDK 1.4 (markt) + /fix + +/changelog + + /subsection + + subsection name=Coyote + +changelog + + fix + Fix memory leak when spare threads are destroyed (remm, fhanik) + /fix + +/changelog + + /subsection + + subsection name=Webapps + +changelog + + fix + bug26147/bug: Fix typo in schemaLocation (remm) + /fix + +/changelog + + /subsection + + subsection name=Modules + +changelog + + fix + Implemented the ability to not expire sessions on shutdown, since that + will expire them across the cluster (fhanik) + /fix + fix + Fix initialization of the session in delta manager (fhanik) + /fix + +/changelog + + /subsection + +/section + section name=Tomcat 5.0.17 (remm) subsection name=General - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat vs PHP
Hi ppl, Anyone here knows any resource about Tomcat and PHP performance comparinson under linux? Anyone knows wich one is faster? Thanks in advance! Thiago Souza
Re: [PATCH]Virtual Host Choice on HTML Manager
on Mon, 12 Jan 2004 17:04:07 +0100 Remy Maucherat [EMAIL PROTECTED] wrote: Fixes were added a few days ago to the admin webapp to support dynamic host creation. This is a first step. It should then be possible to add a manager to a newly created host using the admin webapp (and then you're done, no hacks required). The biggest problem is probably that the admin webapp is not scriptable at all. Thank you for your comment. Your modification is same as my second idea. I'm looking forward to evaluating this new feature soon. (on 5.0.18?) Regards. TANAKA - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26171] New: - NullPointerException in AccessLogValve
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26171. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26171 NullPointerException in AccessLogValve Summary: NullPointerException in AccessLogValve Product: Tomcat 5 Version: 5.0.16 Platform: PC OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Catalina:Modules AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] context.xml contains a AccessLogValve. After install (via ant task) everything works. A subsequent remove and install of the same webapp cause the error below after pressing the reload button in an existing session in the client browser: 15.01.2004 16:39:50 org.apache.coyote.tomcat5.CoyoteAdapter service SCHWERWIEGEND: An exception or error occurred in the container during the request processing java.lang.NullPointerException at org.apache.catalina.valves.AccessLogValve.getDate(AccessLogValve.java:1030) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:589) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:564) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:195) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:164) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:564) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:156) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:564) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:972) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:211) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:805) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:696) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:605) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:677) at java.lang.Thread.run(Thread.java:534) Looks like currentDate is not initialized under certain circumstances. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves AccessLogValve.java
yoavs 2004/01/15 08:18:11
Modified:catalina/src/share/org/apache/catalina/valves
AccessLogValve.java
Log:
Added null check for current date for safety, after user reported
null date following webapp reload.
Revision ChangesPath
1.8 +12 -10
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/AccessLogValve.java
Index: AccessLogValve.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/AccessLogValve.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- AccessLogValve.java 2 Sep 2003 21:22:03 - 1.7
+++ AccessLogValve.java 15 Jan 2004 16:18:11 - 1.8
@@ -1022,17 +1022,21 @@
* less than 1 second since a new Date was created, this method
* simply gives out the same Date again so that the system doesn't
* spend time creating Date objects unnecessarily.
+ *
+ * @return Date
*/
private Date getDate() {
-
-// Only create a new Date once per second, max.
-long systime = System.currentTimeMillis();
-if ((systime - currentDate.getTime()) 1000) {
-currentDate = new Date(systime);
-}
+if(currentDate == null) {
+ currentDate = new Date();
+} else {
+ // Only create a new Date once per second, max.
+ long systime = System.currentTimeMillis();
+ if ((systime - currentDate.getTime()) 1000) {
+ currentDate = new Date(systime);
+ }
+ }
return currentDate;
-
}
@@ -1160,6 +1164,4 @@
close();
}
-
-
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26171] - NullPointerException in AccessLogValve
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26171. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26171 NullPointerException in AccessLogValve [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-01-15 16:20 --- Added a null check in the relevant method, which will generate a new date object only if needed. I wonder why the lifecycle start wasn't taking care of this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 26171] - NullPointerException in AccessLogValve
[EMAIL PROTECTED] wrote:
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26171.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26171
NullPointerException in AccessLogValve
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||FIXED
--- Additional Comments From [EMAIL PROTECTED] 2004-01-15 16:20 ---
Added a null check in the relevant method, which will generate a new date
object only if needed. I wonder why the lifecycle start wasn't taking care of
this.
It was.
public void start() throws LifecycleException {
// Validate and update our current component state
if (started)
throw new LifecycleException
(sm.getString(accessLogValve.alreadyStarted));
lifecycle.fireLifecycleEvent(START_EVENT, null);
started = true;
// Initialize the timeZone, Date formatters, and currentDate
TimeZone tz = TimeZone.getDefault();
timeZone = calculateTimeZoneOffset(tz.getRawOffset());
if (fileDateFormat==null || fileDateFormat.length()==0)
fileDateFormat = -MM-dd;
dateFormatter = new SimpleDateFormat(fileDateFormat);
dateFormatter.setTimeZone(tz);
dayFormatter = new SimpleDateFormat(dd);
dayFormatter.setTimeZone(tz);
monthFormatter = new SimpleDateFormat(MM);
monthFormatter.setTimeZone(tz);
yearFormatter = new SimpleDateFormat();
yearFormatter.setTimeZone(tz);
timeFormatter = new SimpleDateFormat(HH:mm:ss);
timeFormatter.setTimeZone(tz);
currentDate = new Date();
dateStamp = dateFormatter.format(currentDate);
timeTakenFormatter = new DecimalFormat(0.000);
open();
}
I think it could be some other bug, but I don't know for sure. It could
have been working already.
However, never use the install/remove tasks. Always point out they're
deprecated in favor of deploy/undeploy.
I have a test .war like that (struts-example), with a context.xml and 3
access log valves in it (there was a bug if you had more than once of
the same valve in the pipeline), and it works: deploy / undeploy /
retsart / etc.
I won't integrate the patch in 5.0.18 (if start of the valve doesn't get
called, it's a much bigger problem).
It could be a concurrent request which went in too soon, who knows.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
catalina (tomcat 5.0.16) JAASRealm and GenericPrincipal and Me
I am trying to implement my own JAAS LoginModule.
I configure server.xml
Realm className=org.apache.catalina.realm.JAASRealm
debug=99
appName=NadejJAAS
userClassName=com.micropole.jaas.memory.UserPrincipal
roleClassName=com.micropole.jaas.memory.RolePrincipal
/
My LoginModule works fine until i need to populate Principal in the commit()
method.
Kind of result:
[MemoryLoginModule] user entered user name: testUser
[MemoryLoginModule] user entered password: testPassword
[MemoryLoginModule] authentication succeeded
And finnaly i get a 403 : forbidden access to ressource
I find an explication in the following method of RealmBase.hasRole(Principal
principal, String role)
In fact, i populate with my own Principal (RolePrincipal) but
Tomcat rejects my user because it is waiting for a GenericPrincipal.
JAASRealm seems to use public boolean hasRole(Principal principal, String
role)
inherited from RealmBase with the following code :
public boolean hasRole(Principal principal, String role) {
// Should be overriten in JAASRealm - to avoid pretty inefficient
conversions
if ((principal == null) || (role == null) ||
!(principal instanceof GenericPrincipal))
return (false);
GenericPrincipal gp = (GenericPrincipal) principal;
if (!(gp.getRealm() == this)) {
log.debug(Different realm + this + + gp.getRealm());//
return (false);
}
boolean result = gp.hasRole(role);
if (log.isDebugEnabled()) {
String name = principal.getName();
if (result)
log.debug(sm.getString(realmBase.hasRoleSuccess, name,
role));
else
log.debug(sm.getString(realmBase.hasRoleFailure, name,
role));
}
return (result);
}
Two things :
1 - the comment says that it should be re-implemented in JAASRealm but it
is not done.
2 - This implementation depends on a GenericPrincipal class specific to
Catalina packages.
Maybe somebody is working about this JAASRealm and can help me to be able
to write a LoginModule that is not compiling depend of Catalina but usable
with Catalina.
A bonus question : why using two principals in server.xml realm tag if we
are using in one code?
It seems there is an error in the manual (Realm Element Attributes Table
seems to talk about MemoryRealm instead of JAASRealm).
Thanks in advance for any help.
Emmanuel BURRIEL
DO NOT REPLY [Bug 26147] - xsi:schemaLocation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26147. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26147 xsi:schemaLocation [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2004-01-15 16:58 --- According to XML Schema 1.0 spec at http://www.w3.org/TR/xmlschema- 0/#schemaLocation, The schemaLocation attribute contains pairs of values: The first member of each pair is the namespace for which the second member is the hint describing where to find to an appropriate schema document. Here's an excerpt from Sun's J2EE 1.4 RI samples: web-app version=2.4 xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; I guess xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee web-app_2_4.xsd can be validly used by some catalog system (equipped in Tomcat). In conclusion, http://marc.theaimsgroup.com/?l=tomcat-devm=107417121117386w=2 should be rolled back or xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; can be another alternative. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-servletapi-5/jsr152/examples/WEB-INF web.xml
remm2004/01/15 09:18:31 Modified:jsr152/examples/WEB-INF web.xml Log: - Fix again schema location. Revision ChangesPath 1.12 +1 -1 jakarta-servletapi-5/jsr152/examples/WEB-INF/web.xml Index: web.xml === RCS file: /home/cvs/jakarta-servletapi-5/jsr152/examples/WEB-INF/web.xml,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- web.xml 15 Jan 2004 12:53:24 - 1.11 +++ web.xml 15 Jan 2004 17:18:31 - 1.12 @@ -2,7 +2,7 @@ web-app xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; -xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; +xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; version=2.4 description - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26147] - xsi:schemaLocation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26147. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26147 xsi:schemaLocation [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-01-15 17:19 --- Thanks for the comments. I checked in the specification this time. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
remm2004/01/15 09:22:40 Modified:webapps/docs changelog.xml Log: - Update changelog. Revision ChangesPath 1.34 +3 -12 jakarta-tomcat-catalina/webapps/docs/changelog.xml Index: changelog.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v retrieving revision 1.33 retrieving revision 1.34 diff -u -r1.33 -r1.34 --- changelog.xml 15 Jan 2004 15:32:05 - 1.33 +++ changelog.xml 15 Jan 2004 17:22:40 - 1.34 @@ -41,29 +41,20 @@ fix Remove CGI servlet dependency on JDK 1.4 (markt) /fix - -/changelog - - /subsection - - subsection name=Coyote - -changelog - fix - Fix memory leak when spare threads are destroyed (remm, fhanik) + bug26171/bug: Fix NPE in AccessLogValve during a reload (yoavs) /fix /changelog /subsection - subsection name=Webapps + subsection name=Coyote changelog fix - bug26147/bug: Fix typo in schemaLocation (remm) + Fix memory leak when spare threads are destroyed (remm, fhanik) /fix /changelog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Found it - WAS: Memory leak
-1. Please reconsider. There is no memory leak, please check for yourself. Rémy dude, I spent hours on this yesterday with a profiler...how about giving in a little bit :) the leak is pretty bad, I ran up to 512MB in hours of heavy load. Filip -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Thursday, January 15, 2004 12:28 AM To: Tomcat Developers List Subject: Re: Found it - WAS: Memory leak Bill Barker wrote: I'd be in favor of just dropping RequestInfo and RequestGroupInfo altogether (and provide RequestListener commented out in web.xml that does the same thing). Then people that want this can still get Request stats via JMX (which I might use on a development site, but never on a production site). And as a bonus, we get to ship an example of a RequestListener :). Removing isn't hard (I've just done it for my downloaded version of 5.0.17). The original code isn't very careful about what operations are atomic, so a replacement Listener that's as good as RequestGroupInfo isn't hard to do either :). -1. Please reconsider. There is no memory leak, please check for yourself. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Found it - WAS: Memory leak
Filip Hanik wrote: dude, I spent hours on this yesterday with a profiler...how about giving in a little bit :) the leak is pretty bad, I ran up to 512MB in hours of heavy load. For one, I couldn't reproduce the problem. I had to use my imagination and saw that there was an issue when the thread pool was stopping threads. So there is a trivial workaround. OTOH, using HTTP client is better on Windows than ab, which behaves oddly sometimes due to Cygwin's IO. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Found it - WAS: Memory leak
I dont think setting maxSpareThreads==maxThreads is a good solution to a problem as this memory leak. I still have to verify that that would actually solve the problem if we don't want to remove request info, lets fix it. Filip -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Thursday, January 15, 2004 5:24 AM To: Tomcat Developers List Subject: Re: Found it - WAS: Memory leak Remy Maucherat wrote: -1. There is no memory leak with this. ByteChunks/CharChunks are always reused. If new ones are created, they will be reused. Arg, I have to find something. I know ! It's all Costin's fault ! I didn't think about the scaling back feature of the thread pool, to be honest. It should be very easy to avoid the problem, by setting maxSpareThreads to maxThreads. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Found it - WAS: Memory leak
This sort of memory leak can't be left unaddressed -- i.e. you shouldn't have to change the settings to avoid an intolerable memory leak. Is this issue new to 5.0.17 or was it in 5.0.16 as well? In either case, it would be good to see this fixed in 5.0.17 -- but it is all the more critical if it was initially broken in 5.0.17! -- Jess Holle Filip Hanik wrote: I dont think setting maxSpareThreads==maxThreads is a good solution to a problem as this memory leak. I still have to verify that that would actually solve the problem if we don't want to remove request info, lets fix it. Filip -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Thursday, January 15, 2004 5:24 AM To: Tomcat Developers List Subject: Re: Found it - WAS: Memory leak Remy Maucherat wrote: -1. There is no memory leak with this. ByteChunks/CharChunks are always reused. If new ones are created, they will be reused. Arg, I have to find something. I know ! It's all Costin's fault ! I didn't think about the scaling back feature of the thread pool, to be honest. It should be very easy to avoid the problem, by setting maxSpareThreads to maxThreads. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Found it - WAS: Memory leak
I ran HTTP client on windows, Tomcat on RH8 AND RH9, both of them have the leak. I ran tomcat through both OptimizeIt and JProbe yesterday, and both of them showed the leak. it should be very easy to reproduce, you just have to be patient...it takes time for the memory to grow, but it does and it doesn't shrink back. Looks like I have to do more digging in, I will try to find out exactly where it is wrong, I just know that skipping addRequestProcessor solves my problem. Be back in a few days with what I hope is a concrete solution, than just commenting out a line Filip -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Thursday, January 15, 2004 9:41 AM To: Tomcat Developers List Subject: Re: Found it - WAS: Memory leak Filip Hanik wrote: dude, I spent hours on this yesterday with a profiler...how about giving in a little bit :) the leak is pretty bad, I ran up to 512MB in hours of heavy load. For one, I couldn't reproduce the problem. I had to use my imagination and saw that there was an issue when the thread pool was stopping threads. So there is a trivial workaround. OTOH, using HTTP client is better on Windows than ab, which behaves oddly sometimes due to Cygwin's IO. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26174] New: - NoClassDefFoundError when calling getNamedDispatcher with security manager
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26174. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26174 NoClassDefFoundError when calling getNamedDispatcher with security manager Summary: NoClassDefFoundError when calling getNamedDispatcher with security manager Product: Tomcat 4 Version: 4.1.24 Platform: PC OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] In the default RPM installation, the following servlet code causes a NoClassDefFoundError when running under the security manager. RequestDispatcher rd = servletcontext.getNamedDispatcher(default); This problem was solved by putting the following into catalina.policy: permission java.lang.RuntimePermission accessClassInPackage.org.apache.catalina.*; permission java.lang.RuntimePermission accessClassInPackage.org.apache.catalina; permission java.lang.RuntimePermission defineClassInPackage.org.apache.catalina.*; permission java.lang.RuntimePermission defineClassInPackage.org.apache.catalina; I propose that either (A) getNamedDispatcher be modified so that it doesn't generate this error or (B) the above lines get added by default to catalina.policy. (Possibly this is too liberal. Maybe there is a more specific setting that should be applied). As a side note, the RPM (rightly so, I believe) installs Tomcat with the security manager on by default. This makes it important that catalina.policy settings allow servlets and JSP files to work smoothly. Trace: java.lang.NoClassDefFoundError: org/apache/catalina/core/ApplicationDispatcher java.lang.NoClassDefFoundError: org/apache/catalina/core/ApplicationDispatcher at org.apache.catalina.core.ApplicationContext.getNamedDispatcher (Unknown Source) at org.apache.catalina.core.ApplicationContextFacade.getNamedDispatcher (Unknown Source) at com.forio.servlet.plugin.implement.ServeFile.sendFileResponse (Unknown Source) at com.forio.servlet.plugin.implement.ServeFile.processRequest(Unknown Source) at com.forio.servlet.SimServlet.handleRequest(Unknown Source) at com.forio.servlet.util.VelocityServletAlt.doRequest(Unknown Source) at com.forio.servlet.util.VelocityServletAlt.doGet(Unknown Source) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (Unknown Source) at org.apache.catalina.core.ApplicationFilterChain.access$0(Unknown Source) at org.apache.catalina.core.ApplicationFilterChain$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationFilterChain.doFilter(Unknown Source) at org.apache.catalina.core.StandardWrapperValve.invoke(Unknown Source) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Found it - WAS: Memory leak
Filip Hanik wrote: I ran HTTP client on windows, Tomcat on RH8 AND RH9, both of them have the leak. I ran tomcat through both OptimizeIt and JProbe yesterday, and both of them showed the leak. it should be very easy to reproduce, you just have to be patient...it takes time for the memory to grow, but it does and it doesn't shrink back. Looks like I have to do more digging in, I will try to find out exactly where it is wrong, I just know that skipping addRequestProcessor solves my problem. Be back in a few days with what I hope is a concrete solution, than just commenting out a line I have fixed the leak, and have provided an easy workaround using the configuration file. I could not reproduce the said leak without finding where it was in the code first, so it will not leak a lot of memory in real world situations. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
5.0.17 Feedback
5.0.17 seemed to work fine overall [though I'm anxiously awaiting the memory leak resolution] -- including the new useBodyEncodingForURI flag :-) I did notice that out of 992 JSP pages Tomcat 5.0.16 has successfully compiled (via an Ant precompilation using Tomcat's jspc) only 899 were successfully compiled by 5.0.17. I looked into this further and discovered that 5.0.16 misreported 3 failures as successes as the jspc task failed but did not signal such. Thus Tomcat 5.0.17 is a nice improvement in this regard! -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: 5.0.17 Feedback
Howdy, I did notice that out of 992 JSP pages Tomcat 5.0.16 has successfully compiled (via an Ant precompilation using Tomcat's jspc) only 899 were successfully compiled by 5.0.17. I looked into this further and discovered that 5.0.16 misreported 3 failures as successes as the jspc task failed but did not signal such. Thus Tomcat 5.0.17 is a nice improvement in this regard! I hope you meant 902 and not 992? Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.0.17 Feedback
Shapira, Yoav wrote: Howdy, I did notice that out of 992 JSP pages Tomcat 5.0.16 has successfully compiled (via an Ant precompilation using Tomcat's jspc) only 899 were successfully compiled by 5.0.17. I looked into this further and discovered that 5.0.16 misreported 3 failures as successes as the jspc task failed but did not signal such. Thus Tomcat 5.0.17 is a nice improvement in this regard! I hope you meant 902 and not 992? Good catch. I actually mean 992 and 989 respectively. I transposed the 8 and 9 in the latter statistic -- i.e. only 3 JSPs out of 992 failed to compile with 5.0.16 but were not noted as failures only to be noted as such by 5.0.17. Which means that neither our JSPs nor 5.0.16 was that far amiss -- but 5.0.17 is a definite improvement in this regard. -- Jess Holle
Re: Error in mod_jk Makefile?
Yap! That was it. I am fairly new to FreeBSD and I was not aware about that issue. Thanx a lot! Dave David Meier wrote: I am trying to build mod_jk-1.2.5 from source on FreeBSD 4.9-RELEASE and I encounter at the end of the build process the following error: ... /usr/local/bin/bash /usr/local/apache/build/libtool --silent --mode=install cp `pwd`/mod_jk.so libtool: install: you must specify a destination Try `libtool --help --mode=install' for more information. *** Error code 1 Whe looking at the Makefile it looks like the build stops at that command: ... mod_jk.so: mod_jk.la $(LIBTOOL) --mode=install cp $ `pwd`/$@ ... Unfortunately, I have no expirience in writing Makefiles, however, it looks like that line does not work on FreeBSD. Use gmake instead make (mod_jk needs a GNU make). Anyone any idea to rewrite that line or to edit the command manually? Thanks. Dave. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Found it - WAS: Memory leak
I'll try the fix since I am still on the eval period of the profilers :) thanks Filip - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, January 15, 2004 9:56 AM Subject: Re: Found it - WAS: Memory leak Filip Hanik wrote: I ran HTTP client on windows, Tomcat on RH8 AND RH9, both of them have the leak. I ran tomcat through both OptimizeIt and JProbe yesterday, and both of them showed the leak. it should be very easy to reproduce, you just have to be patient...it takes time for the memory to grow, but it does and it doesn't shrink back. Looks like I have to do more digging in, I will try to find out exactly where it is wrong, I just know that skipping addRequestProcessor solves my problem. Be back in a few days with what I hope is a concrete solution, than just commenting out a line I have fixed the leak, and have provided an easy workaround using the configuration file. I could not reproduce the said leak without finding where it was in the code first, so it will not leak a lot of memory in real world situations. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Found it - WAS: Memory leak
Filip Hanik wrote: I'll try the fix since I am still on the eval period of the profilers :) Cool :) (crossing all fingers) You know there's also that tomcat-committers mailing list for the issues that make people nervous (security, etc) ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Found it - WAS: Memory leak
From: Remy Maucherat [EMAIL PROTECTED] Filip Hanik wrote: I'll try the fix since I am still on the eval period of the profilers :) Cool :) (crossing all fingers) You know there's also that tomcat-committers mailing list for the issues that make people nervous (security, etc) ;) no, I didn't know that, funny me being a committer and all :-)) LOL - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[5.0.18] Build available
Hi, A new new build is now available for testing: Tomcat 5.0.18 Alpha. http://www.apache.org/dist/jakarta/tomcat-5/v5.0.18-alpha/ Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Found it - WAS: Memory leak
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, January 15, 2004 5:24 AM Subject: Re: Found it - WAS: Memory leak Remy Maucherat wrote: -1. There is no memory leak with this. ByteChunks/CharChunks are always reused. If new ones are created, they will be reused. Arg, I have to find something. I know ! It's all Costin's fault ! I didn't think about the scaling back feature of the thread pool, to be honest. It should be very easy to avoid the problem, by setting maxSpareThreads to maxThreads. Also, Jk-Coyote doesn't pool threads, so the total number of Requests created will (slowly) grow over time. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Found it - WAS: Memory leak
Bill Barker wrote: Remy Maucherat wrote: -1. There is no memory leak with this. ByteChunks/CharChunks are always reused. If new ones are created, they will be reused. Arg, I have to find something. I know ! It's all Costin's fault ! I didn't think about the scaling back feature of the thread pool, to be honest. It should be very easy to avoid the problem, by setting maxSpareThreads to maxThreads. Also, Jk-Coyote doesn't pool threads, so the total number of Requests created will (slowly) grow over time. I'm almost certain JK doesn't register the RequestInfo objects. It should (and it's a bug), but actually it doesn't. I tried to have the status servlet work with JK also, and had partial fixes, but in the end, I didn't find the feature too worthwhile (and my fixes were hacks), so I forgot about it (good thing I did). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Found it - WAS: Memory leak
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, January 15, 2004 11:41 AM Subject: Re: Found it - WAS: Memory leak Bill Barker wrote: Remy Maucherat wrote: -1. There is no memory leak with this. ByteChunks/CharChunks are always reused. If new ones are created, they will be reused. Arg, I have to find something. I know ! It's all Costin's fault ! I didn't think about the scaling back feature of the thread pool, to be honest. It should be very easy to avoid the problem, by setting maxSpareThreads to maxThreads. Also, Jk-Coyote doesn't pool threads, so the total number of Requests created will (slowly) grow over time. I'm almost certain JK doesn't register the RequestInfo objects. It should (and it's a bug), but actually it doesn't. I tried to have the status servlet work with JK also, and had partial fixes, but in the end, I didn't find the feature too worthwhile (and my fixes were hacks), so I forgot about it (good thing I did). It registers it on line 475 of HandlerRequest. It's true that Jk doesn't do much else with the RequestInfo, but it does register it. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Found it - WAS: Memory leak
Bill Barker wrote: I'm almost certain JK doesn't register the RequestInfo objects. It should (and it's a bug), but actually it doesn't. I tried to have the status servlet work with JK also, and had partial fixes, but in the end, I didn't find the feature too worthwhile (and my fixes were hacks), so I forgot about it (good thing I did). It registers it on line 475 of HandlerRequest. It's true that Jk doesn't do much else with the RequestInfo, but it does register it. Yes, I know the code exists and would look like it would work, but last time I tried, all the JMX code in JK wasn't executed. For example, the MBean for the ChannelSocket wasn't registered. Did you put traces in there to double check ? I'm not very familar with JK, so I don't know for sure. Even if it's registered, I don't know if it would be a problem or not. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Found it - WAS: Memory leak
setting maxSpareThreads==minSpareThreads==maxThreads does take care of the memory leak with the new code, however, going with the default server.xml settings, tomcat is still leaking memory. I will delve into this when I get home tonight, that is when I have access to the profiler. have a good one, Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Found it - WAS: Memory leak
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, January 15, 2004 12:33 PM Subject: Re: Found it - WAS: Memory leak Bill Barker wrote: I'm almost certain JK doesn't register the RequestInfo objects. It should (and it's a bug), but actually it doesn't. I tried to have the status servlet work with JK also, and had partial fixes, but in the end, I didn't find the feature too worthwhile (and my fixes were hacks), so I forgot about it (good thing I did). It registers it on line 475 of HandlerRequest. It's true that Jk doesn't do much else with the RequestInfo, but it does register it. Yes, I know the code exists and would look like it would work, but last time I tried, all the JMX code in JK wasn't executed. For example, the MBean for the ChannelSocket wasn't registered. Did you put traces in there to double check ? Yup, it seems that the JMX registration in Jk is broken. HandlerRequest never gets registered, so it never registers the RequestInfo. I'm not very familar with JK, so I don't know for sure. Even if it's registered, I don't know if it would be a problem or not. If it was registered, it most definitely would be a memory leak. You would keep creating Request objects that never get dereferenced. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25965] - RequestDispatcher fails after cross context include
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25965. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25965 RequestDispatcher fails after cross context include --- Additional Comments From [EMAIL PROTECTED] 2004-01-16 01:22 --- Created an attachment (id=9970) This is the client web app of the test case. Browse to index.jsp to invoke the test. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25965] - RequestDispatcher fails after cross context include
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25965. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25965 RequestDispatcher fails after cross context include --- Additional Comments From [EMAIL PROTECTED] 2004-01-16 01:23 --- Created an attachment (id=9971) This is the server web app of the test case. It's invoked through the client web app (also attached) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25965] - RequestDispatcher fails after cross context include
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25965. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25965 RequestDispatcher fails after cross context include [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2004-01-16 01:26 --- I've sent an e-mail regarding this bug to both mailing lists and did not recieve a response. Therefore, I've attached the test case (two war files) and have reopened the issue. Please let me know if you cannot reproduce the problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26181] New: - error message The requested resource (/stuff/index.html) is not available.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26181. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26181 error message The requested resource (/stuff/index.html) is not available. Summary: error message The requested resource (/stuff/index.html) is not available. Product: Tomcat 5 Version: 5.0.16 Platform: PC OS/Version: Windows XP Status: NEW Severity: Blocker Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi All, I installed Jakarta.tomcat 5.0.16. I am able to start up and shut down = the web server successfully. I tried to write a simple HTML to print hello world. The HTML program alone is working fine offline but when I try to link it = to webserver I get this error message: The requested resource (/stuff/index.html) is not available. the index.html is located at webapps/stuff/index.html. I am setting CATALINA_HOME and JAVA_HOME at the beginning of startup.bat = and am using Windows XP. Any help is much appreciated. Thanks, Susan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26181] - error message The requested resource (/stuff/index.html) is not available.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26181. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26181 error message The requested resource (/stuff/index.html) is not available. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-01-16 02:35 --- Bugzilla is not a place to ask question. Please post your question to [EMAIL PROTECTED] -- Jeanfrancois - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkCoyoteHandler.java
billbarker2004/01/15 19:14:11
Modified:jk/java/org/apache/jk/server JkCoyoteHandler.java
Log:
Fix JMX self-registration when loading the normal way.
Revision ChangesPath
1.48 +8 -8
jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkCoyoteHandler.java
Index: JkCoyoteHandler.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkCoyoteHandler.java,v
retrieving revision 1.47
retrieving revision 1.48
diff -u -r1.47 -r1.48
--- JkCoyoteHandler.java 7 Jan 2004 05:32:44 - 1.47
+++ JkCoyoteHandler.java 16 Jan 2004 03:14:11 - 1.48
@@ -182,14 +182,6 @@
jkMain=new JkMain();
jkMain.setWorkerEnv(wEnv);
-if( oname != null ) {
-try {
-Registry.getRegistry().registerComponent(jkMain,
oname.getDomain(),
-JkMain, type=JkMain);
-} catch (Exception e) {
-log.error( Error registering jkmain + e );
-}
-}
}
return jkMain;
}
@@ -229,6 +221,14 @@
public void start() {
try {
+if( oname != null getJkMain().getDomain() == null) {
+try {
+Registry.getRegistry().registerComponent(getJkMain(),
oname.getDomain(),
+JkMain, type=JkMain);
+} catch (Exception e) {
+log.error( Error registering jkmain + e );
+}
+}
getJkMain().start();
} catch( Exception ex ) {
ex.printStackTrace();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/common HandlerRequest.java
billbarker2004/01/15 19:57:59
Modified:jk/java/org/apache/jk/common HandlerRequest.java
Log:
Add an option to allow the admin to *not* JMX register the requests.
This is mostly because it may take awhile to plug the memory leaks that registering
the requests causes (esp. for channel.jni :).
Revision ChangesPath
1.30 +17 -2
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/HandlerRequest.java
Index: HandlerRequest.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/HandlerRequest.java,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- HandlerRequest.java 3 Dec 2003 05:37:42 - 1.29
+++ HandlerRequest.java 16 Jan 2004 03:57:59 - 1.30
@@ -295,7 +295,21 @@
if( .equals( path ) ) path=null;
ajpidDir=path;
}
-
+
+/**
+ * Set the flag to tell if we JMX register requests.
+ */
+public void setRegisterRequests(boolean srr) {
+registerRequests = srr;
+}
+
+/**
+ * Get the flag to tell if we JMX register requests.
+ */
+public boolean getRegisterRequests() {
+return registerRequests;
+}
+
// Ajp13.id
private void generateAjp13Id() {
@@ -345,6 +359,7 @@
boolean decoded=true;
boolean tomcatAuthentication=true;
+boolean registerRequests=true;
public int invoke(Msg msg, MsgContext ep )
throws IOException
@@ -462,7 +477,7 @@
Response res=new Response();
req.setResponse(res);
ep.setRequest( req );
-if( this.getDomain() != null ) {
+if( registerRequests this.getDomain() != null ) {
try {
if( global==null ) {
global=new RequestGroupInfo();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26183] New: - ServletResponse#reset() method and cookie session control problem on tomcat4.1.24
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26183. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26183 ServletResponse#reset() method and cookie session control problem on tomcat4.1.24 Summary: ServletResponse#reset() method and cookie session control problem on tomcat4.1.24 Product: Tomcat 4 Version: 4.1.24 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Connector:Coyote HTTP/1.1 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The following problem was encountered. I was wondering if this behavior is specification. 1)I set true as value of 'cookeis' attribute of 'context' tag in server.xml. (default) 2)I called following JSP in the web application. -- . % session.invalidate(); session=request.getSession(); session.setAttribute(SessionData,dummy); response.reset(); % . -- 3)I found that 'session.getAttribute(SessionData)' returned null at the next request from the same browser. It seems that the session was lost. Originally, 'session' and 'reset() method' should not be related but they seem to be related. I think that this problem originates in the following operation. org.apache.coyote.tomcat4.CoyoteRequest.java doGetSession() method . ((HttpServletResponse) response).addCookie(cookie); . This code set 'Set-Cookie' header to the response. Next the 'Set-Cookie' header has been cleared by the reset() method. Then session maintenance went wrong at the next request. In fact, this has generated on the error page and evasion is difficult. (I don't use reset() method directly but exception occurred after create new session. reset() method is called indirectly to handle this exception from tomcat.) This problem occurred also on tomcat5 but happened neither on weblogic8 nor WebSphere5. Is this behavior specification ? If this is not as an intention, could I have the correction of tomcat(maybe coyote) ? regards, Naru Hayashi from Japan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH]Virtual Host Choice on HTML Manager
On Mon, Jan 12, 2004 at 11:43:44AM -0700, George Sexton wrote: Here is my thinking. Of course, I am a lowly user and not a developer but I think it pretty much covers the issues. The major issues from my perspective are: 1)Admin cannot deploy privileged applications. This requires deploying manager by hand. 2)Admin cannot stop or restart applications. This requires using manager. 3)Manager already displays the status for all virtual hosts. This kind of breaks the virtual host purity that Remy and others want in this application. 4)Deployment of application using manager is difficult at best. I have never been able to do it. Even if you can do it, there are no configuration points. IOW, you cannot configure logging. 5)As Remy points out, people will next be asking for manager to manage virtual hosts. The biggest issue for me is that if you want to use a UI to manage tomcat, 3 different tools (Admin, Hand Edit, and Manager) must be used to create a virtual host that can be stopped and restarted. Doesn't anyone else see a problem with this? If I had my way, what I would do is: 1)Add capability for admin application to stop/start/re-start contexts. This really shouldn't be that big a deal. I cannot see any rationale for not putting it in. Additionally, I would put the status reports in the Admin app. If you do this, then I don't really care about the manager application and wouldn't even deploy it all. This is ok, no reason why the uber-tomcat-admin can't have just one place to do this. 2)Strip every feature except list, status, stop, and re-start from manager. IOW, remove the deployment capability and the complete server status feature (or limit it to the virtual host). How many people REALLY need to script deployment of a web application? Particularly in the limited fashion allowed by the current Manager? Strong -1. Its there and it is being used, and there will continue to be a need for it even if the admin app supports the types of things the manager does. There are many who use the ant tasks to manage webapps, especially during web application development. The ability to delegate out web application mangement and deployment to a customer for only a single virtual host is crucial for those who administer instances of Tomcat which support multiple customers in multiple virtual hosts. Including the ability to deploy a web application via the HTML manager. Regards, Glenn -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Monday, January 12, 2004 9:04 AM To: Tomcat Developers List Subject: Re: [PATCH]Virtual Host Choice on HTML Manager TANAKA Yoshihiro wrote: on Tue, 6 Jan 2004 16:48:47 -0600 Glenn Nielsen [EMAIL PROTECTED] wrote: I'll try to modify as follows: 1)Make new classes extend HTMLManagerServlet ManagerServlet. 2)These servlets are optional. (commented out in web.xml) 3)Only admin role can access them. (by web.xml) Do you think I've it figured out? That sounds right. :-) I've done and put them on http://www.ytp.ne.jp/tech/tomcat/manager/index.html I modified existing classes to allow them to be extended, but did not change their functions. Also I create a new build file for Deployer named 'build-muti.xml' cause of security. I hope committers evaluate and commit them. While I appreciate the effort, I don't like your patch right now, sorry :-( Why add complexity when it is so simple to deploy the manager webapp on a new host ? Note: A webapp doesn't use any noticeable amount of resources in TC 5 (no background thread, no nothing). I suppose if there weren't all the changes to the default manager, I would have nothing against the patch (although I do hate the changes to the Ant tasks; it's really counter productive, and proves this is a bad design: the place of the vhost is in the URL). Soon, there will be requests to add host management in the manager webapp, and it will become a big mess. If there's interest in improving the management tools, fine, but there should be a thinking process before the hacking starts. Fixes were added a few days ago to the admin webapp to support dynamic host creation. This is a first step. It should then be possible to add a manager to a newly created host using the admin webapp (and then you're done, no hacks required). The biggest problem is probably that the admin webapp is not scriptable at all. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/core JkHandler.java
billbarker2004/01/15 22:48:21
Modified:jk/java/org/apache/jk/common ChannelSocket.java
HandlerRequest.java
jk/java/org/apache/jk/core JkHandler.java
Log:
Initial fix for memory leak with registering Requests.
This only currently fixes channel.socket. All other channels are still broken.
Revision ChangesPath
1.38 +8 -0
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelSocket.java
Index: ChannelSocket.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelSocket.java,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -r1.37 -r1.38
--- ChannelSocket.java30 Sep 2003 07:39:58 - 1.37
+++ ChannelSocket.java16 Jan 2004 06:48:20 - 1.38
@@ -639,6 +639,14 @@
catch( Exception e) {
log.error( Error, closing connection, e);
}
+try{
+ MsgAjp endM = new MsgAjp();
+endM.reset();
+endM.appendByte((byte)HANDLE_THREAD_END);
+next.invoke(endM, ep);
+} catch( Exception ee) {
+log.error( Error, releasing connection,ee);
+}
}
}
1.31 +32 -13
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/HandlerRequest.java
Index: HandlerRequest.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/HandlerRequest.java,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -r1.30 -r1.31
--- HandlerRequest.java 16 Jan 2004 03:57:59 - 1.30
+++ HandlerRequest.java 16 Jan 2004 06:48:20 - 1.31
@@ -65,6 +65,7 @@
import java.io.CharConversionException;
import java.net.InetAddress;
import java.util.Properties;
+import javax.management.ObjectName;
import org.apache.commons.modeler.Registry;
import org.apache.coyote.Request;
@@ -247,10 +248,12 @@
JK_AJP13_SHUTDOWN,
this, null); // 7
-dispatch.registerMessageType( JK_AJP13_CPING_REQUEST,
-
JK_AJP13_CPING_REQUEST,
-
this, null); // 10
-
+dispatch.registerMessageType( JK_AJP13_CPING_REQUEST,
+ JK_AJP13_CPING_REQUEST,
+ this, null); // 10
+dispatch.registerMessageType( HANDLE_THREAD_END,
+ HANDLE_THREAD_END,
+ this, null);
// register outgoing messages handler
dispatch.registerMessageType( JK_AJP13_SEND_BODY_CHUNK, // 3
JK_AJP13_SEND_BODY_CHUNK,
@@ -260,6 +263,7 @@
bodyNote=wEnv.getNoteId( WorkerEnv.ENDPOINT_NOTE, jkInputStream );
tmpBufNote=wEnv.getNoteId( WorkerEnv.ENDPOINT_NOTE, tmpBuf );
secretNote=wEnv.getNoteId( WorkerEnv.ENDPOINT_NOTE, secret );
+JMXRequestNote =wEnv.getNoteId( WorkerEnv.ENDPOINT_NOTE, requestNote);
if( next==null )
next=wEnv.getHandler( container );
@@ -356,6 +360,7 @@
int bodyNote;
int tmpBufNote;
int secretNote;
+int JMXRequestNote;
boolean decoded=true;
boolean tomcatAuthentication=true;
@@ -447,14 +452,25 @@
return OK;
-// We got a PING REQUEST, quickly respond with a PONG
-case JK_AJP13_CPING_REQUEST:
-msg.reset();
-msg.appendByte(JK_AJP13_CPONG_REPLY);
-ep.setType( JkHandler.HANDLE_SEND_PACKET );
-ep.getSource().invoke( msg, ep );
+// We got a PING REQUEST, quickly respond with a PONG
+case JK_AJP13_CPING_REQUEST:
+msg.reset();
+msg.appendByte(JK_AJP13_CPONG_REPLY);
+ep.setType( JkHandler.HANDLE_SEND_PACKET );
+ep.getSource().invoke( msg, ep );
-return OK;
+ return OK;
+
+case HANDLE_THREAD_END:
+if(registerRequests) {
+Request req = (Request)ep.getRequest();
+if( req != null ) {
+ObjectName roname = (ObjectName)ep.getNote(JMXRequestNote);
+Registry.getRegistry().unregisterComponent(roname);
+
