Re: TOMCAT-fix for os/390??
Anna Fuhrmann wrote: Hi List, 4.1.28 does the job - but: /webapps/ROOT/index.jsp is screwed up; the browser cannot GET it, supposedly because of chunked encoded. It is HTTP1.1, which the browser does have. The first big chunk is 2000 big, we noticed when GETting it with a script. The browser GETs and GETs and GETs and never stops GETting ... Any remedies? Do you get ASCII or EBCDIC in the Tomcat response? - I am gettting EBCDIC for the moment - While using Servlets I have problems with ResourceBundle. Does it works ok for you (HelloWorldExample for example does not work)? Anna - Original Message - From: Bill Barker [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, October 10, 2003 9:06 AM Subject: Re: Re: TOMCAT-fix for os/390?? Try http://www.apache.org/dist/jakarta/tomcat-4/v4.1.28-alpha/. The 'alpha' is just because it is still in it's evaluation stage. It's likely to graduate to at least beta (if not 'stable'). However, your ability to test it on an os/390 system makes you particularly valuable to the developers, so I hope that you will try it out :). - Original Message - From: [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, October 10, 2003 12:35 AM Subject: Re: Re: TOMCAT-fix for os/390?? Well well ... being a simpleton (=user) I don't quite manage to manage cvs ... I would love to install tomcat 4.1.28 (having 4.1.27), bit I cannot find such a distribution. So what it boils down to if I cannot get 4.1.28 is: install rls 6 BETA - does it go well with JDK 1.3? thank you very much for your help Anna Von: Dirk Verbeeck [EMAIL PROTECTED] Datum: 2003/10/09 Do PM 10:53:59 GMT+02:00 An: Tomcat Developers List [EMAIL PROTECTED] Betreff: Re: TOMCAT-fix for os/390?? Hi Anna I don't use tomcat on os390 but by reading you problem I suspect your problem is solved in cvs, you need at least revision 1.16.2.1 http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-tomcat-connectors/http 11/src/java/org/apache/coyote/http11/InternalOutputBuffer.java?rev=1.16.2.1 or 1.18 http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-tomcat-connectors/http 11/src/java/org/apache/coyote/http11/InternalOutputBuffer.java?rev=1.18 of the following file: http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/InternalOutputBuffer.java Releases including this fix are TOMCAT_5_0_13 http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/http11/src/java/org /apache/coyote/http11/InternalOutputBuffer.java?only_with_tag=TOMCAT_5_0_13 , TOMCAT_5_0_12 http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/http11/src/java/org /apache/coyote/http11/InternalOutputBuffer.java?only_with_tag=TOMCAT_5_0_12 , TOMCAT_4_1_28 http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/http11/src/java/org /apache/coyote/http11/InternalOutputBuffer.java?only_with_tag=TOMCAT_4_1_28 Cheers Dirk Anna Fuhrmann wrote: Hi all, like a good girl I have been using the user-mailing-list up to now to search for user experience installing tomcat on os390. Most (if not all) contributions are in the form has anyone successfully installed tomcat on os390? From some other I got partly valuable ideas. I have been TRYING to get tomcat run on os390 in the last couple of days. Done everything I could - everything seems to be allright up to this pont: tomcat IS running at last without any serious signs of disbehaviour - no error messages at all, xml's behaving well. But if we connect to localhost:tomcatport/index.jsp (or wahtever else for that matter), the browser does not show anything. Doing the same with a perl script shows that the server is ansering and is supplying the requested page, BUT EACH LINE OF THE HTTP_HEADER CONTAINS AN INVALID (i.e.: ebcdic) LINE SEPARATOR. So thats the reason why. Today I tried to identify the .java-file giving us the header (looking for \r\n) . I thought I found it, by my hex.editor did not show me any 0x0d15 (which ought to be the suspect, i.e. Newline in ebcdic). What I would like to know: Is there any kind of patch for os/390? Do you have any suggestions? Is anybody working on it? What should I do? I want to have this beast running. PLEASE. We have os390 2.10 IBM-JDK 1.3 tomcat 4.1.27 Anna Fuhrmann - 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] 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
Re: jk2/apr patch
Kurt Miller wrote:
Checking out the apache2 makefile it looks like apr-0 is right. Here's a revised
patch (I missed a spot).
Index: jk/support/jk_apr.m4
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/jk/support/jk_apr.m4,v
retrieving revision 1.3
diff -u -r1.3 jk_apr.m4
--- jk/support/jk_apr.m4 25 Sep 2003 15:23:56 - 1.3
+++ jk/support/jk_apr.m4 30 Oct 2003 22:11:05 -
@@ -99,7 +99,7 @@
APR_CLEAN=apr-clean
APR_DIR=${tempval}
APR_INCDIR=${tempval}/include
-APR_LDFLAGS=${tempval}/.libs/libapr.a
+APR_LDFLAGS=${tempval}/.libs/libapr-0.a
APR_LIBDIR=
use_apr=true
COMMON_APR_OBJECTS=\${COMMON_APR_OBJECTS}
@@ -189,7 +189,7 @@
APR_CLEAN=
APR_DIR=
APR_LIBDIR=${tempval}
- APR_LDFLAGS=-lapr -L${tempval}
+ APR_LDFLAGS=-lapr-0 -L${tempval}
COMMON_APR_OBJECTS=\${COMMON_APR_OBJECTS}
use_apr=true
fi
- Original Message -
From: Kurt Miller [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Thursday, October 30, 2003 4:32 PM
Subject: jk2/apr patch
Getting ready for jk2 requiring apr (even for Apache13)... Building jk2
using:
./configure --with-apxs=/usr/sbin/apxs --with-apr=apr src loc make
linking fails because the apr library is not named libapr.a it is named
libapr-0.a. I'm not sure if this naming problem is universal for all
platforms, but libapr-0.a appears to be the correct name for OpenBSD,
FreeBSD and NetBSD. If it is universal then here's a quick patch to change
it:
Index: jk/support/jk_apr.m4
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/jk/support/jk_apr.m4,v
retrieving revision 1.3
diff -u -r1.3 jk_apr.m4
--- jk/support/jk_apr.m4 25 Sep 2003 15:23:56 - 1.3
+++ jk/support/jk_apr.m4 30 Oct 2003 21:03:16 -
@@ -99,7 +99,7 @@
APR_CLEAN=apr-clean
APR_DIR=${tempval}
APR_INCDIR=${tempval}/include
-APR_LDFLAGS=${tempval}/.libs/libapr.a
+APR_LDFLAGS=${tempval}/.libs/libapr-0.a
APR_LIBDIR=
use_apr=true
COMMON_APR_OBJECTS=\${COMMON_APR_OBJECTS}
If this name needs to be libapr.a for other platforms, then I guess I
could
patch the apr-build target in Makefile.in to rename it. Any thoughts?
-1. We have to use apr-config to get the name of the apr library.
Look in the web-app deprecated code (in wa_apr.m4).
-Kurt
-
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: jk2/apr patch
Clere, Jean-Frederic wrote:
Kurt Miller wrote:
Checking out the apache2 makefile it looks like apr-0 is right. Here's
a revised
patch (I missed a spot).
Index: jk/support/jk_apr.m4
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/support/jk_apr.m4,v
retrieving revision 1.3
diff -u -r1.3 jk_apr.m4
--- jk/support/jk_apr.m4 25 Sep 2003 15:23:56 - 1.3
+++ jk/support/jk_apr.m4 30 Oct 2003 22:11:05 -
@@ -99,7 +99,7 @@
APR_CLEAN=apr-clean
APR_DIR=${tempval}
APR_INCDIR=${tempval}/include
-APR_LDFLAGS=${tempval}/.libs/libapr.a
+APR_LDFLAGS=${tempval}/.libs/libapr-0.a
APR_LIBDIR=
use_apr=true
COMMON_APR_OBJECTS=\${COMMON_APR_OBJECTS}
@@ -189,7 +189,7 @@
APR_CLEAN=
APR_DIR=
APR_LIBDIR=${tempval}
- APR_LDFLAGS=-lapr -L${tempval}
+ APR_LDFLAGS=-lapr-0 -L${tempval}
COMMON_APR_OBJECTS=\${COMMON_APR_OBJECTS}
use_apr=true
fi
- Original Message - From: Kurt Miller [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Thursday, October 30, 2003 4:32 PM
Subject: jk2/apr patch
Getting ready for jk2 requiring apr (even for Apache13)... Building jk2
using:
./configure --with-apxs=/usr/sbin/apxs --with-apr=apr src loc make
linking fails because the apr library is not named libapr.a it is named
libapr-0.a. I'm not sure if this naming problem is universal for all
platforms, but libapr-0.a appears to be the correct name for OpenBSD,
FreeBSD and NetBSD. If it is universal then here's a quick patch to
change
it:
Index: jk/support/jk_apr.m4
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/support/jk_apr.m4,v
retrieving revision 1.3
diff -u -r1.3 jk_apr.m4
--- jk/support/jk_apr.m4 25 Sep 2003 15:23:56 - 1.3
+++ jk/support/jk_apr.m4 30 Oct 2003 21:03:16 -
@@ -99,7 +99,7 @@
APR_CLEAN=apr-clean
APR_DIR=${tempval}
APR_INCDIR=${tempval}/include
-APR_LDFLAGS=${tempval}/.libs/libapr.a
+APR_LDFLAGS=${tempval}/.libs/libapr-0.a
APR_LIBDIR=
use_apr=true
COMMON_APR_OBJECTS=\${COMMON_APR_OBJECTS}
If this name needs to be libapr.a for other platforms, then I guess I
could
patch the apr-build target in Makefile.in to rename it. Any thoughts?
-1. We have to use apr-config to get the name of the apr library.
Look in the web-app deprecated code (in wa_apr.m4).
For example I have with APR for CVS:
+++
[EMAIL PROTECTED]:~/apr apr-config --link-ld --libs
-L/home/jfclere/apr -lapr-1 -lrt -lm -lcrypt -lnsl -lpthread -ldl
[EMAIL PROTECTED]:~/apr find . -name *.so -print
./.libs/libapr-1.so
+++
-Kurt
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: Re: jk2/apr patch]
Does someone else got those kind of messages? If yes could the address [EMAIL PROTECTED] be removed from the tomcat-dev list? Cheers Jean-Frederic BTW: I think [EMAIL PROTECTED] should also be removed... ---BeginMessage--- AUTOMATED MESSAGE DO NOT REPLY -- The e-mail address you tried to contact is no longer a valid email address. If you need to contact NeuroDimension, please resend your message to [EMAIL PROTECTED] ---End Message--- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24197] - adding an extra slash in a mod_jk url circumvents tomcat (form) login authentication
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=24197. 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=24197 adding an extra slash in a mod_jk url circumvents tomcat (form) login authentication --- Additional Comments From [EMAIL PROTECTED] 2003-10-31 09:07 --- I'm using ajp13; haven't tried 4.1.29 yet. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24283] New: - Wrong result in request.getPathInfo() using 2-byte Unicode characters
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=24283. 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=24283 Wrong result in request.getPathInfo() using 2-byte Unicode characters Summary: Wrong result in request.getPathInfo() using 2-byte Unicode characters Product: Tomcat 4 Version: 4.1.27 Platform: All OS/Version: All Status: NEW Severity: Critical Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If you call a servlet with 2-byte Unicode characters in the URL and use URL-encoded sessions e.g. with a german umlaut 'ä' like http://192.168.1.xxx/servlet/%c3%a4;jsessionid=E3C9183C8A50CE11A10A62B4F8ADB1DE the method request.getPathInfo() returns ä; If there are more then one 2-byte Unicode characters in the URL the method returns the count of 2-byte Unicode characters more then required e.g. http://192.168.1.xxx/servlet/%c3%a4%c3%b6%c3% bc;jsessionid=E3C9183C8A50CE11A10A62B4F8ADB1DE returns äöü;js It seems that the length of the return string is calculated without respect to the count of encoded 2-byte Unicode charachters. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Fwd: Re: jk2/apr patch]
I'm not receiving this messages from the list, i'll try to unsubscribe them anyway.. Saludos, Ignacio J. Ortega -Original Message- From: jean-frederic clere [mailto:[EMAIL PROTECTED] Sent: Friday, October 31, 2003 9:39 AM To: [EMAIL PROTECTED] Subject: [Fwd: Re: jk2/apr patch] Does someone else got those kind of messages? If yes could the address [EMAIL PROTECTED] be removed from the tomcat-dev list? Cheers Jean-Frederic BTW: I think [EMAIL PROTECTED] should also be removed... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24009] - Jasper option for whitespace-optimized HTML output
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=24009. 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=24009 Jasper option for whitespace-optimized HTML output --- Additional Comments From [EMAIL PROTECTED] 2003-10-31 12:21 --- A simpler workaround is to write a filter which strips out space. I'll leave the bug open, but I really doubt any developer will want this patch. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24277] - Tomcat Icon Dissapear
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=24277. 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=24277 Tomcat Icon Dissapear [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Summary|Tomcat Icon Dissapear |Tomcat Icon Dissapear --- Additional Comments From [EMAIL PROTECTED] 2003-10-31 13:06 --- This works for me. Please try 5.0.14. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
Jan Luehe wrote: Remy Maucherat wrote: I guess I don't understand what makes 1 bad but 2 OK. Where do we draw the line of what is a stupid config? Yes, definitely, 2 is nearly as stupid as 1. We need a reasonable minimal value for maxThreads; let's say 10 - 20. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk quickhowto.xml
glenn 2003/10/31 05:50:04 Modified:jk/xdocs faq.xml jk/xdocs/jk quickhowto.xml Log: Update download and doc hrefs now that j-t-c source and binaries are on the mirrors. Revision ChangesPath 1.8 +8 -5 jakarta-tomcat-connectors/jk/xdocs/faq.xml Index: faq.xml === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/faq.xml,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- faq.xml 19 Nov 2002 15:21:09 - 1.7 +++ faq.xml 31 Oct 2003 13:50:04 - 1.8 @@ -15,7 +15,7 @@ The primary mechanism for support is through the JK documentation included in the doc directory. Documentation is also available on the Apache Jakarta web site devoted to the -a href=http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/doc/index.html; +a href=http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/index.html; Jakarta Tomcat Connectors Project/a For additional help, the best resource is the Tomcat Users Discussion list. You should start by searching @@ -36,9 +36,12 @@ subsection name=I can't find JK anywhere. Where is it? p Now that JK moved to the bjakarta-tomcat-connectors/b repository, -the source and binaries for JK are present -in the a href=http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/; -jakarta-tomcat-connectors directory/a +the source for JK can be downloaded from a mirror at the +a href=http://jakarta.apache.org/site/sourceindex.cgi; +Jakarta Source Download/a page and the binaries for JK can +be downloaded from a mirror at the +a href=http://jakarta.apache.org/site/binindex.cgi; +Jakarta Binary Download/a page. /p /subsection 1.10 +2 -2 jakarta-tomcat-connectors/jk/xdocs/jk/quickhowto.xml Index: quickhowto.xml === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/jk/quickhowto.xml,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- quickhowto.xml25 Sep 2003 13:06:30 - 1.9 +++ quickhowto.xml31 Oct 2003 13:50:04 - 1.10 @@ -72,7 +72,7 @@ /ul /p p - You'll find prebuilt binaries a href=http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.5/bin/;here/a + You'll find prebuilt binaries a href=http://jakarta.apache.org/site/binindex.cgi/;here/a /p p Here is the minimum which should be set in bhttpd.conf/b directly or - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2/apr patch
From: jean-frederic clere [EMAIL PROTECTED]
Clere, Jean-Frederic wrote:
Kurt Miller wrote:
Checking out the apache2 makefile it looks like apr-0 is right. Here's
a revised
patch (I missed a spot).
Index: jk/support/jk_apr.m4
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/support/jk_apr.m4,v
retrieving revision 1.3
diff -u -r1.3 jk_apr.m4
--- jk/support/jk_apr.m4 25 Sep 2003 15:23:56 - 1.3
+++ jk/support/jk_apr.m4 30 Oct 2003 22:11:05 -
@@ -99,7 +99,7 @@
APR_CLEAN=apr-clean
APR_DIR=${tempval}
APR_INCDIR=${tempval}/include
-APR_LDFLAGS=${tempval}/.libs/libapr.a
+APR_LDFLAGS=${tempval}/.libs/libapr-0.a
APR_LIBDIR=
use_apr=true
COMMON_APR_OBJECTS=\${COMMON_APR_OBJECTS}
@@ -189,7 +189,7 @@
APR_CLEAN=
APR_DIR=
APR_LIBDIR=${tempval}
- APR_LDFLAGS=-lapr -L${tempval}
+ APR_LDFLAGS=-lapr-0 -L${tempval}
COMMON_APR_OBJECTS=\${COMMON_APR_OBJECTS}
use_apr=true
fi
- Original Message - From: Kurt Miller [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Thursday, October 30, 2003 4:32 PM
Subject: jk2/apr patch
Getting ready for jk2 requiring apr (even for Apache13)... Building
jk2
using:
./configure --with-apxs=/usr/sbin/apxs --with-apr=apr src loc
make
linking fails because the apr library is not named libapr.a it is
named
libapr-0.a. I'm not sure if this naming problem is universal for all
platforms, but libapr-0.a appears to be the correct name for OpenBSD,
FreeBSD and NetBSD. If it is universal then here's a quick patch to
change
it:
Index: jk/support/jk_apr.m4
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/support/jk_apr.m4,v
retrieving revision 1.3
diff -u -r1.3 jk_apr.m4
--- jk/support/jk_apr.m4 25 Sep 2003 15:23:56 - 1.3
+++ jk/support/jk_apr.m4 30 Oct 2003 21:03:16 -
@@ -99,7 +99,7 @@
APR_CLEAN=apr-clean
APR_DIR=${tempval}
APR_INCDIR=${tempval}/include
-APR_LDFLAGS=${tempval}/.libs/libapr.a
+APR_LDFLAGS=${tempval}/.libs/libapr-0.a
APR_LIBDIR=
use_apr=true
COMMON_APR_OBJECTS=\${COMMON_APR_OBJECTS}
If this name needs to be libapr.a for other platforms, then I guess I
could
patch the apr-build target in Makefile.in to rename it. Any thoughts?
-1. We have to use apr-config to get the name of the apr library.
Look in the web-app deprecated code (in wa_apr.m4).
For example I have with APR for CVS:
+++
[EMAIL PROTECTED]:~/apr apr-config --link-ld --libs
-L/home/jfclere/apr -lapr-1 -lrt -lm -lcrypt -lnsl -lpthread -ldl
[EMAIL PROTECTED]:~/apr find . -name *.so -print
./.libs/libapr-1.so
+++
Ok thanks for the heads up, I've look briefly at wa_apr.m4 now. I've got a
question or two I think there are two cases:
1) when --with-apr is specified
2) when --with-apr-include and --with-apr-lib are specified
In case one the apr src directory is given and jk2 builds apr using the
apr-build target in the native2 makefile. The apr-build target does a
./configure make for apr when building jk2. When configuring jk2,
apr-config is not guaranteed to be available.
The webapp connector required apr to be built from source for Apache13 and
configured apr while configuring itself. Should jk2 also make this
requirement? It appears the webapp connector did it to ensure the same
complier was used and that apr was configured without threads for Apache13.
In the second case the apr src dir is not specified, so apr-config is not
available again. The webap connector used it to get the lib name. I'm not
sure what the best method for determining the lib name in this case.
Currently the the lib name is hardcoded to libapr.a for apache13 and
libapr-0 for apache2. Any suggestions?
-Kurt
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-site/xdocs news.xml
glenn 2003/10/31 05:54:39 Removed: xdocsnews.xml Log: Remove this since we aren't using it - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-site/docs news.html
glenn 2003/10/31 05:55:05 Removed: docs news.html Log: Remove this since we aren't using it - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TOMCAT-fix for os/390??
what I get is normal ascii - but then I left everything ascii except the shell scripts. index.jsp doens't function (that has to do with chunked encoding I think because non-chunked-encoded jsp's seem to be fine). Most of the servlets function all right; I'll have a look at HalloWorld on Monday. Manager and admin do not work at the moment. Anna - Original Message - From: jean-frederic clere [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, October 31, 2003 9:06 AM Subject: Re: TOMCAT-fix for os/390?? Anna Fuhrmann wrote: Hi List, 4.1.28 does the job - but: /webapps/ROOT/index.jsp is screwed up; the browser cannot GET it, supposedly because of chunked encoded. It is HTTP1.1, which the browser does have. The first big chunk is 2000 big, we noticed when GETting it with a script. The browser GETs and GETs and GETs and never stops GETting ... Any remedies? Do you get ASCII or EBCDIC in the Tomcat response? - I am gettting EBCDIC for the moment - While using Servlets I have problems with ResourceBundle. Does it works ok for you (HelloWorldExample for example does not work)? Anna - Original Message - From: Bill Barker [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, October 10, 2003 9:06 AM Subject: Re: Re: TOMCAT-fix for os/390?? Try http://www.apache.org/dist/jakarta/tomcat-4/v4.1.28-alpha/. The 'alpha' is just because it is still in it's evaluation stage. It's likely to graduate to at least beta (if not 'stable'). However, your ability to test it on an os/390 system makes you particularly valuable to the developers, so I hope that you will try it out :). - Original Message - From: [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, October 10, 2003 12:35 AM Subject: Re: Re: TOMCAT-fix for os/390?? Well well ... being a simpleton (=user) I don't quite manage to manage cvs ... I would love to install tomcat 4.1.28 (having 4.1.27), bit I cannot find such a distribution. So what it boils down to if I cannot get 4.1.28 is: install rls 6 BETA - does it go well with JDK 1.3? thank you very much for your help Anna Von: Dirk Verbeeck [EMAIL PROTECTED] Datum: 2003/10/09 Do PM 10:53:59 GMT+02:00 An: Tomcat Developers List [EMAIL PROTECTED] Betreff: Re: TOMCAT-fix for os/390?? Hi Anna I don't use tomcat on os390 but by reading you problem I suspect your problem is solved in cvs, you need at least revision 1.16.2.1 http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-tomcat-connectors/http 11/src/java/org/apache/coyote/http11/InternalOutputBuffer.java?rev=1.16.2.1 or 1.18 http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-tomcat-connectors/http 11/src/java/org/apache/coyote/http11/InternalOutputBuffer.java?rev=1.18 of the following file: http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/InternalOutputBuffer.java Releases including this fix are TOMCAT_5_0_13 http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/http11/src/java/org /apache/coyote/http11/InternalOutputBuffer.java?only_with_tag=TOMCAT_5_0_13 , TOMCAT_5_0_12 http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/http11/src/java/org /apache/coyote/http11/InternalOutputBuffer.java?only_with_tag=TOMCAT_5_0_12 , TOMCAT_4_1_28 http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/http11/src/java/org /apache/coyote/http11/InternalOutputBuffer.java?only_with_tag=TOMCAT_4_1_28 Cheers Dirk Anna Fuhrmann wrote: Hi all, like a good girl I have been using the user-mailing-list up to now to search for user experience installing tomcat on os390. Most (if not all) contributions are in the form has anyone successfully installed tomcat on os390? From some other I got partly valuable ideas. I have been TRYING to get tomcat run on os390 in the last couple of days. Done everything I could - everything seems to be allright up to this pont: tomcat IS running at last without any serious signs of disbehaviour - no error messages at all, xml's behaving well. But if we connect to localhost:tomcatport/index.jsp (or wahtever else for that matter), the browser does not show anything. Doing the same with a perl script shows that the server is ansering and is supplying the requested page, BUT EACH LINE OF THE HTTP_HEADER CONTAINS AN INVALID (i.e.: ebcdic) LINE SEPARATOR. So thats the reason why. Today I tried to identify the .java-file giving us the header (looking for \r\n) . I thought I found it, by my hex.editor did not show me any 0x0d15 (which ought to be the suspect, i.e. Newline in ebcdic). What I would like to know: Is there any kind of patch for os/390? Do you have any suggestions? Is anybody working on it? What should I do? I want to have
Fw: TOMCAT-fix for os/390??
- Original Message - From: Anna Fuhrmann [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED]; Clere, Jean-Frederic [EMAIL PROTECTED] Sent: Friday, October 31, 2003 3:07 PM Subject: Re: TOMCAT-fix for os/390?? what I get is normal ascii - but then I left everything ascii except the shell scripts. index.jsp doens't function (that has to do with chunked encoding I think because non-chunked-encoded jsp's seem to be fine). Most of the servlets function all right; I'll have a look at HalloWorld on Monday. Manager and admin do not work at the moment. Anna PS I had to delete all the previous mails below, too much headers for some mailers :-)) - I got it back
Re: JK2 is using APR as mandatory
- Original Message - From: Mladen Turk [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, October 30, 2003 3:35 PM Subject: JK2 is using APR as mandatory As said in the subject... plus the jk_pool and jk_channel socket are marked as deprecated. Are configurations using channel.socket depreciated now? Does this just mean that the code in jk_channel_socket.c is depreceated becuase jk_channel_apr_socket.c will always be used now? Couple of things to do. 1. APR-ize jk_file_logger to use apr_file API instead stdio's FILE. 2. All methods will return apr_status_t instead int (work in progress). 3. Henri, what about those AS400 defines, can they be removed now? 4. IIS is now presumed to have apr, apr-util, apr-iconv, and pcre in the srclib folder. Tested with apr-0.9.4. Need to document that. 5. ??? Comments? MT. - 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: jk2/apr patch
Kurt Miller wrote:
From: jean-frederic clere [EMAIL PROTECTED]
Clere, Jean-Frederic wrote:
Kurt Miller wrote:
Checking out the apache2 makefile it looks like apr-0 is right. Here's
a revised
patch (I missed a spot).
Index: jk/support/jk_apr.m4
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/support/jk_apr.m4,v
retrieving revision 1.3
diff -u -r1.3 jk_apr.m4
--- jk/support/jk_apr.m4 25 Sep 2003 15:23:56 - 1.3
+++ jk/support/jk_apr.m4 30 Oct 2003 22:11:05 -
@@ -99,7 +99,7 @@
APR_CLEAN=apr-clean
APR_DIR=${tempval}
APR_INCDIR=${tempval}/include
-APR_LDFLAGS=${tempval}/.libs/libapr.a
+APR_LDFLAGS=${tempval}/.libs/libapr-0.a
APR_LIBDIR=
use_apr=true
COMMON_APR_OBJECTS=\${COMMON_APR_OBJECTS}
@@ -189,7 +189,7 @@
APR_CLEAN=
APR_DIR=
APR_LIBDIR=${tempval}
- APR_LDFLAGS=-lapr -L${tempval}
+ APR_LDFLAGS=-lapr-0 -L${tempval}
COMMON_APR_OBJECTS=\${COMMON_APR_OBJECTS}
use_apr=true
fi
- Original Message - From: Kurt Miller [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Thursday, October 30, 2003 4:32 PM
Subject: jk2/apr patch
Getting ready for jk2 requiring apr (even for Apache13)... Building
jk2
using:
./configure --with-apxs=/usr/sbin/apxs --with-apr=apr src loc
make
linking fails because the apr library is not named libapr.a it is
named
libapr-0.a. I'm not sure if this naming problem is universal for all
platforms, but libapr-0.a appears to be the correct name for OpenBSD,
FreeBSD and NetBSD. If it is universal then here's a quick patch to
change
it:
Index: jk/support/jk_apr.m4
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/support/jk_apr.m4,v
retrieving revision 1.3
diff -u -r1.3 jk_apr.m4
--- jk/support/jk_apr.m4 25 Sep 2003 15:23:56 - 1.3
+++ jk/support/jk_apr.m4 30 Oct 2003 21:03:16 -
@@ -99,7 +99,7 @@
APR_CLEAN=apr-clean
APR_DIR=${tempval}
APR_INCDIR=${tempval}/include
-APR_LDFLAGS=${tempval}/.libs/libapr.a
+APR_LDFLAGS=${tempval}/.libs/libapr-0.a
APR_LIBDIR=
use_apr=true
COMMON_APR_OBJECTS=\${COMMON_APR_OBJECTS}
If this name needs to be libapr.a for other platforms, then I guess I
could
patch the apr-build target in Makefile.in to rename it. Any thoughts?
-1. We have to use apr-config to get the name of the apr library.
Look in the web-app deprecated code (in wa_apr.m4).
For example I have with APR for CVS:
+++
[EMAIL PROTECTED]:~/apr apr-config --link-ld --libs
-L/home/jfclere/apr -lapr-1 -lrt -lm -lcrypt -lnsl -lpthread -ldl
[EMAIL PROTECTED]:~/apr find . -name *.so -print
./.libs/libapr-1.so
+++
Ok thanks for the heads up, I've look briefly at wa_apr.m4 now. I've got a
question or two I think there are two cases:
1) when --with-apr is specified
2) when --with-apr-include and --with-apr-lib are specified
In case one the apr src directory is given and jk2 builds apr using the
apr-build target in the native2 makefile. The apr-build target does a
./configure make for apr when building jk2. When configuring jk2,
apr-config is not guaranteed to be available.
Right apr-config is not available before configuring apr.
The webapp connector required apr to be built from source for Apache13 and
configured apr while configuring itself. Should jk2 also make this
requirement?
Yes.
It appears the webapp connector did it to ensure the same
complier was used and that apr was configured without threads for Apache13.
In the second case the apr src dir is not specified, so apr-config is not
available again. The webap connector used it to get the lib name. I'm not
sure what the best method for determining the lib name in this case.
Currently the the lib name is hardcoded to libapr.a for apache13 and
libapr-0 for apache2. Any suggestions?
find + awk?
+++
NUMVERAPR=`find ${tempval} -name *.la | awk -F - '{ print $2 }' | awk -F . '{
print $1 }'
APR_LDFLAGS=-lapr-${NUMVERAPR} -L${tempval}
+++
-Kurt
-
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]
Request for a change
I'm running in an environment in which I sometimes need to authenticate based on both location (IP address, say) and credential (uid/pwd). To make this work, I need to have access to the remote address and/or host from the HTTP request hitting the protected subweb. This information isn't available if I've got BASIC authentication turned on (and probably not other authentication strategies either, though I haven't looked at them lately). To support what I need to do, I need to have a slight modification made to org.apache.catalina.authenticator.BasicAuthenticator. The modified source is attached from the 4.1 source archive. The strategy is the following: o Add the following static declarations to the class: public static final ThreadLocal REQUEST_ADDRESS = new ThreadLocal(); public static final ThreadLocal REQUEST_HOST = new ThreadLocal(); These give me a place to stick the address and host name from the incoming request. o Modify the authenticate() method in the vicinity of line 160 to look like the following (*** represents added lines): // Validate any credentials already included with this request HttpServletRequest hreq = (HttpServletRequest) request.getRequest(); HttpServletResponse hres = (HttpServletResponse) response.getResponse(); String authorization = request.getAuthorization(); String username = parseUsername(authorization); String password = parsePassword(authorization); *** REQUEST_ADDRESS.set(hreq.getRemoteAddr()); *** REQUEST_HOST.set(hreq.getRemoteHost()); principal = context.getRealm().authenticate(username, password); *** REQUEST_ADDRESS.set(null); *** REQUEST_HOST.set(null); The first pair of added lines caches the remote address and host name in the thread-local variables. BasicAuthenticator then calls the realm's authenticate() method as it always does, preserving the interface to existing realm implementations. However, a suitably modified realm implementation can now get the address or host from the BasicAuthenticator variables and make the values available to the authentication mechanism as appropriate. For example, I've modified a few classes in the JBoss environment to be able to use these static thread-local values, so I can have a JAAS LoginModule implementation that validates location and adds appropriate roles for a user. = R.W. Shore Templar Corporation [EMAIL PROTECTED] [EMAIL PROTECTED] (short txt) (703)505-4451 (cell, marginal quality) (540)858-3487 (also the modem line) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22607] - Does not recognize servlets when update a servlet
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=22607. 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=22607 Does not recognize servlets when update a servlet [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24009] - Jasper option for whitespace-optimized HTML output
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=24009. 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=24009 Jasper option for whitespace-optimized HTML output --- Additional Comments From [EMAIL PROTECTED] 2003-10-31 18:16 --- Besides, it'll break the spec, and cause TCK to fail. So if we were to trim white spaces, it'll need to be done with an option, with off the default. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
Remy Maucherat wrote: Jan Luehe wrote: Remy Maucherat wrote: I guess I don't understand what makes 1 bad but 2 OK. Where do we draw the line of what is a stupid config? Yes, definitely, 2 is nearly as stupid as 1. We need a reasonable minimal value for maxThreads; let's say 10 - 20. Remy, I agree we should help users come up with reasonable config values, but I'm just afraid rejecting any maxThreads 10 or 20 will send the wrong message, as if there was a bug in the way we dispatch incoming requests that requires at least 10 threads. I think we should make any maxThreads setting work, as my patch attempts to do, and update the documentation to make users aware of the limitations they will run into when picking a low maxThreads. I think that would be the cleanest solution. Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
Jan Luehe wrote: I agree we should help users come up with reasonable config values, but I'm just afraid rejecting any maxThreads 10 or 20 will send the wrong message, as if there was a bug in the way we dispatch incoming requests that requires at least 10 threads. Nope, I disagree. If maxThreads (say) 10, then set it to 10. Allowing broken settings is bad, as there will be people out there who will use them, and then will assume Tomcat is broken. I think we should make any maxThreads setting work, as my patch attempts to do, and update the documentation to make users aware of the limitations they will run into when picking a low maxThreads. I think that would be the cleanest solution. The rationale is that there's no point adding complexity and checks into the very critical algorithm, simply to be able to support broken cases. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JK2 is using APR as mandatory
-Original Message- From: Kurt Miller As said in the subject... plus the jk_pool and jk_channel socket are marked as deprecated. Are configurations using channel.socket depreciated now? Does this just mean that the code in jk_channel_socket.c is depreceated becuase jk_channel_apr_socket.c will always be used now? No, the channel.socket is actually channel.apr, and the channel.apr has been removed from registry (channel.apr was very intuitive name for a tcp channel). MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24303] New: - Tomcat Service Start-up error (1054): the service did not respond to the start or control request in a timely fashion.
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=24303. 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=24303 Tomcat Service Start-up error (1054): the service did not respond to the start or control request in a timely fashion. Summary: Tomcat Service Start-up error (1054): the service did not respond to the start or control request in a timely fashion. Product: Tomcat 5 Version: 5.0.14 Platform: PC OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I can start Tomcat using startup.bat and shutdown.bat, but I cannot start it as a service. I tried with versions 5.0.3, 5.0.12, and 5.014. I have been able to start it as a service on Windows XP, Windows 2000, but not on Windows 2000 Server. I found a similar problem, Bug #22000, that was a problem by an incorrectly setup VM. I don't see how this could also be my problem since it works with startup.bat. Specifically, to reproduce this error on my server, I download Tomcat, install it, go to the service panel and try to start it. As soon as I press the play button to start Tomcat, I receive the error message back. There are no logs written, but the windows event viewer has the same message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24091] - dynamic-attributes in tag file is broken
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=24091. 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=24091 dynamic-attributes in tag file is broken [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2003-10-31 20:25 --- Sorry, but it still works for me. At least I didn't get the compilation errors you did. Your test case still didn't run, but that's because there is a typo in your code. it should be %@ tag dynamic-attributes=otherAttributes % instead of %@ tag dynamic-attributes=otherAttribtues % With that change, everything works as expected. Of course, I am running on Solaris, not Linux, but they should behave the same. If you still have those compilation errors, then you'll need to do some debugging on your own. Can you look at the generated file for test.tag (i.e. test_tag.java) and see if setDynamicAttribute is properly defined there? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK2 is using APR as mandatory
From: Mladen Turk [EMAIL PROTECTED] From: Kurt Miller As said in the subject... plus the jk_pool and jk_channel socket are marked as deprecated. Are configurations using channel.socket depreciated now? Does this just mean that the code in jk_channel_socket.c is depreceated becuase jk_channel_apr_socket.c will always be used now? No, the channel.socket is actually channel.apr, and the channel.apr has been removed from registry (channel.apr was very intuitive name for a tcp channel). Got it. Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2/apr patch
From: jean-frederic clere [EMAIL PROTECTED]
Kurt Miller wrote:
Ok thanks for the heads up, I've look briefly at wa_apr.m4 now. I've got
a
question or two I think there are two cases:
1) when --with-apr is specified
2) when --with-apr-include and --with-apr-lib are specified
In case one the apr src directory is given and jk2 builds apr using the
apr-build target in the native2 makefile. The apr-build target does a
./configure make for apr when building jk2. When configuring jk2,
apr-config is not guaranteed to be available.
Right apr-config is not available before configuring apr.
The webapp connector required apr to be built from source for Apache13
and
configured apr while configuring itself. Should jk2 also make this
requirement?
Yes.
It appears the webapp connector did it to ensure the same
complier was used and that apr was configured without threads for
Apache13.
In the second case the apr src dir is not specified, so apr-config is
not
available again. The webap connector used it to get the lib name. I'm
not
sure what the best method for determining the lib name in this case.
Currently the the lib name is hardcoded to libapr.a for apache13 and
libapr-0 for apache2. Any suggestions?
find + awk?
+++
NUMVERAPR=`find ${tempval} -name *.la | awk -F - '{ print $2 }' | awk -F
. '{
print $1 }'
APR_LDFLAGS=-lapr-${NUMVERAPR} -L${tempval}
+++
Before I start making a patch, I'd like to make sure I've got the new
behavior nailed down...
It seems like there is some conflicting stuff going on. Apr may need to be
configured without threads at times (without for Apache13 on OpenBSD and
Apache2 on FreeBSD 4.7 (pre fork MPM)). When using --with-apr currently it
doesn't specify with or without threads while configuring apr. So it just
guesses and will likely be with threads at times it shouldn't be.
I'd like to add a new configure argument called --with-apr-threads that will
indicated if apr should be with or without threads. This argument will
ignored, unless -with-apr is also specified and will used to configure apr.
Not sure what the default should be.
Currently --with-apr-include and --with-apr-lib override --with-apr. So I'm
thinking after all three arguments have been processed do the following if
APR_BUILD is not empty:
1) For Apache13 and Apache2 get the compiler used by apxs.
2) configure apr with --enable-static --disable-shared (override
compiler for Apache13 and Apache2) --with-threads or
--without-threads based on the --with-apr-threads argument.
3) Use apr-config to get lib name.
In --with-apr-lib processing set the lib name using your find + awk
technique.
Does the above sound acceptable so far?
Hummm, if neither --with-apr or --with-apr-lib is specified what do we do
for the lib name (it may be there already for Apache2)?
-Kurt
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24303] - Tomcat Service Start-up error (1054): the service did not respond to the start or control request in a timely fashion.
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=24303. 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=24303 Tomcat Service Start-up error (1054): the service did not respond to the start or control request in a timely fashion. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-10-31 20:51 --- Apparently, what caused this problem was that Java SDK directory was copied from one machine to the other. The solution was to delete the copied directory and run the Java SDK install. *** This bug has been marked as a duplicate of 2200 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ContainerBase.java StandardContext.java
remm2003/10/31 13:45:25
Modified:catalina/src/share/org/apache/catalina/core
ContainerBase.java StandardContext.java
Log:
- Modify the MBean lifecycle for the containers.
- The MBeans will now be removed only on destroy, rather than on stop.
- The use case is this:
* Assume a started host exists
* Add a context by instantiating a MBean
* Then call init (addChild will be called, which will start the context)
* If there's an error starting the context, its MBean would have been removed
right away, preventing further operations on the context (at least through JMX),
and preventing redeploying it again (the host still has it as a child, so trying
the
same sequence again after fixing the issue would fail). I have deterrmined
there's no way to properly handle this case through JMX, so the clean fix
seems to do JMX unregistration only on destroy (so that the MBean has the
same lifecycle as the context itself, which seems logical).
Revision ChangesPath
1.30 +14 -13
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ContainerBase.java
Index: ContainerBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ContainerBase.java,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- ContainerBase.java15 Oct 2003 17:24:16 - 1.29
+++ ContainerBase.java31 Oct 2003 21:45:25 - 1.30
@@ -1213,18 +1213,6 @@
}
}
-// unregister this component
-if( oname != null ) {
-try {
-if( controller == oname ) {
-Registry.getRegistry().unregisterComponent(oname);
-log.debug(unregistering + oname);
-}
-} catch( Throwable t ) {
-log.error(Error unregistering , t );
-}
-}
-
// Notify our interested LifecycleListeners
lifecycle.fireLifecycleEvent(AFTER_STOP_EVENT, null);
@@ -1253,7 +1241,7 @@
mserver.invoke(parentName, addChild, new Object[] { this },
new String[] {org.apache.catalina.Container});
}
-}
+}
initialized=true;
}
@@ -1266,6 +1254,19 @@
stop();
}
initialized=false;
+
+// unregister this component
+if ( oname != null ) {
+try {
+if( controller == oname ) {
+Registry.getRegistry().unregisterComponent(oname);
+log.debug(unregistering + oname);
+}
+} catch( Throwable t ) {
+log.error(Error unregistering , t );
+}
+}
+
if (parent != null) {
parent.removeChild(this);
}
1.98 +32 -18
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java
Index: StandardContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
retrieving revision 1.97
retrieving revision 1.98
diff -u -r1.97 -r1.98
--- StandardContext.java 21 Oct 2003 00:18:25 - 1.97
+++ StandardContext.java 31 Oct 2003 21:45:25 - 1.98
@@ -4059,6 +4059,7 @@
if (ok) {
+boolean mainOk = false;
try {
started = true;
@@ -4084,7 +4085,7 @@
// Set JMX object name for proper pipeline registration
preRegisterJMX();
-
+
// Start our child containers, if any
Container children[] = findChildren();
for (int i = 0; i children.length; i++) {
@@ -4123,9 +4124,16 @@
// Start ContainerBackgroundProcessor thread
super.threadStart();
+mainOk = true;
+
} finally {
// Unbinding thread
unbindThread(oldCCL);
+if (!mainOk) {
+// An exception occurred
+// Register with JMX anyway, to allow management
+registerJMX();
+}
}
}
@@ -4190,9 +4198,9 @@
}
// JMX registration
-if (ok) {
-registerJMX();
+registerJMX();
+if (ok) {
// Notify our interested LifecycleListeners
lifecycle.fireLifecycleEvent(AFTER_START_EVENT, null);
}
@@
DO NOT REPLY [Bug 24307] New: - jk2 distribution does not build
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=24307. 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=24307 jk2 distribution does not build Summary: jk2 distribution does not build Product: Tomcat 4 Version: Unknown Platform: Other URL: http://jakarta.apache.org/site/sourceindex.cgi OS/Version: Other Status: NEW Severity: Critical Priority: Other Component: Connector:Coyote JK 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] jakarta-tomcat-connectors-jk2-src-current.tar.gz does not contain either the directory ./util or ./coyote, both of which would seem to be required by the build.xml viz: [home]409: ant Buildfile: build.xml coyote: BUILD FAILED file:/home/devel/apache/jakarta-tomcat-connectors-jk2-2.0.2-src/build.xml:11: Basedir /home/devel/apache/jakarta-tomcat-connectors-jk2-2.0.2-src/util does not exist Total time: 1 second - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24308] New: - for charset=UTF8 request.getParameter(i1).getBytes() return non UTF8 bytes
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=24308.
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=24308
for charset=UTF8 request.getParameter(i1).getBytes() return non UTF8 bytes
Summary: for charset=UTF8 request.getParameter(i1).getBytes()
return non UTF8 bytes
Product: Tomcat 4
Version: 4.1.29
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Example JSP:
%@ page contentType=text/html;charset=UTF8 %
meta http-equiv=Content-Type content=text/html; charset=UTF8 /
FORM
INPUT TYPE=text NAME=i1 /
/FORM
%
String i1=request.getParameter(i1);
if(i1 ==null)return;
byte[] bytes=i1.getBytes();
%
Value of String(bytes,UTF8):br
%=new String(bytes,UTF8) %
br
Values of the byte array:br
%
for(int i=0; ibytes.length; i++){
%
%= bytes[i]% br
% } %
When I enter some characters above 127 e.g. the character
Ä or a cyrillic character then
request.getParameter(i1).getBytes()
returns a byte array that does not contain the
correct UTF( encoding for these characters.
This is easily seen by looking at the output generated by
%=new String(bytes,UTF8) %
By the way the length of the byte array is ok so for Ä it has length two
and for chinese characters it hastb length 3.
Same Problem already in Tomcat 4.1.27
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24308] - for charset=UTF8 request.getParameter(i1).getBytes() return non UTF8 bytes
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=24308. 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=24308 for charset=UTF8 request.getParameter(i1).getBytes() return non UTF8 bytes --- Additional Comments From [EMAIL PROTECTED] 2003-11-01 01:14 --- Same problem here using 4.1.29 with HttpServletResponse.getOutputStream().write(byte[]) However, this worked fine with tomcat-4.1.27, so it seems to be a regression against 4.1.29 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24314] New: - jk2/AJP13: jkstatus unsafely prints jk_stat-active
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=24314. 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=24314 jk2/AJP13: jkstatus unsafely prints jk_stat-active Summary: jk2/AJP13: jkstatus unsafely prints jk_stat-active Product: Tomcat 4 Version: 4.0.4 Final Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Connector:Coyote JK 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I saw this under LastReq a couple of times in my jkstatus page (built from the 2.0.2 tarball): /cnetcd/aiListTransactions.do;jsessionid=3C39F41641B7CA3405B45D0¢Ù? Which seems really scary. Sure enough, in jk_worker_ajp13.c we see that this struct field (struct jk_stat's active is char[64]) is populated by a strncpy on line 472: /* XXX configurable ? */ strncpy( e-stats-active, s-req_uri, 64); In jk_worker_status.c, the utility function jk2_worker_status_displayStat(...) doesn't pay attention to this size, using jkprintf: s-jkprintf(env, s, td%s/td\n, JK_CHECK_NULL(stat-active) ); jkprintf is a void* to jk2_requtil_printf, which does expects a NULL terminated string! It will occasionally wander off into oblivion until it hits a null. Icky. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
Remy, I agree we should help users come up with reasonable config values, but I'm just afraid rejecting any maxThreads 10 or 20 will send the wrong message, as if there was a bug in the way we dispatch incoming requests that requires at least 10 threads. Nope, I disagree. If maxThreads (say) 10, then set it to 10. Allowing broken settings is bad, as there will be people out there who will use them, and then will assume Tomcat is broken. I think changing people's config values behind their backs is not such a good idea in general. I think we should make any maxThreads setting work, as my patch attempts to do, and update the documentation to make users aware of the limitations they will run into when picking a low maxThreads. I think that would be the cleanest solution. The rationale is that there's no point adding complexity and checks into the very critical algorithm, simply to be able to support broken cases. I think we have 2 options: 1. Support any maxThreads setting (including 1, 2, etc.). 2. Reject any maxThreads values that are smaller than some threshold and throw an error. The problem with 2. is that picking a value for the threshold (10? 20?) seems rather arbitrary. Therefore, I think we should do 1. The complexity it is adding is not significant and is well-documented. Please tell me you agree. :) Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
Jan Luehe [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Remy, I agree we should help users come up with reasonable config values, but I'm just afraid rejecting any maxThreads 10 or 20 will send the wrong message, as if there was a bug in the way we dispatch incoming requests that requires at least 10 threads. Nope, I disagree. If maxThreads (say) 10, then set it to 10. Allowing broken settings is bad, as there will be people out there who will use them, and then will assume Tomcat is broken. I think changing people's config values behind their backs is not such a good idea in general. I think we should make any maxThreads setting work, as my patch attempts to do, and update the documentation to make users aware of the limitations they will run into when picking a low maxThreads. I think that would be the cleanest solution. The rationale is that there's no point adding complexity and checks into the very critical algorithm, simply to be able to support broken cases. I think we have 2 options: 1. Support any maxThreads setting (including 1, 2, etc.). 2. Reject any maxThreads values that are smaller than some threshold and throw an error. The problem with 2. is that picking a value for the threshold (10? 20?) seems rather arbitrary. Therefore, I think we should do 1. The complexity it is adding is not significant and is well-documented. Please tell me you agree. :) Well, I don't agree :). There is no reason to accept a config value that won't work, and it is cheaper and safer to handle in the config code then in the critical runtime code (although, in this particular case, I admit that the perfomance hit should be minimal). Personally, I would be perfectly happy with an enforced min setting of '2' (but Remy's suggestion is much more practical, given that TC 5 does so much hand-holding already :). As long as the override is logged at WARN level, I don't see any problem with enforcing a minimum. I'm still -1 on this patch at heart, but I could be talked down to an official -0 if enough of the rest of the community thinks that it is useful. Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Missing mod_jk2 docs?
Thanks for reporting this. Forwarding on to the tomcat developers. Glenn Matt McParland wrote: There are links in various places on jakarta.apache.org pointing to the URL below: http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/doc/ But that URL points me to: http://jakarta.apache.org/site/binindex.cgi which doesn't have any documentation on jk2 at all. Am I missing something? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
custom web app classloader
I want to write my own custom web application class loader, for Tomcat 4.1* (and hopefully it will continue to work for Tomcat 5*). From the precious little info that is available, I have gleaned the following: - the class I write should implement org.apache.catalina.Loader interface. - once I write the class, I tell tomcat to use it by specifying it in the Loader tag of a Context in server.xml - my class itself goes into $CATALINA_HOME/server/lib Are my assumptions above correct? It would be a real bonus to see an example. I am sure more than one person in this community has done this before. Any words of advice? Advanced Thanks, Jwahar Bammi Memento, Inc. [EMAIL PROTECTED]
[OT] Digest List of Tomcat List(s)
http://jakarta.apache.org/site/mail2.html#Tomcat (I modified/updated this page and committed a little while ago :-D Did you all know that you can subscribe to Daily Digest user/dev list(s) of Tomcat? :-) Happy mailing! -- Tetsuya. ([EMAIL PROTECTED]) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Apache Tomcat 4.1.29 Stable and Apache Tomcat 5.0.14 Beta released
The Tomcat Team announces the immediate availability of Apache Tomcat 4.1.29 Stable and Apache Tomcat 5.0.14 Beta. Please refer to the changelog for the list of changes. Downloads: Binaries: http://jakarta.apache.org/site/binindex.cgi Sources: http://jakarta.apache.org/site/sourceindex.cgi The Apache Tomcat Team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
