Re: Latest mod_jk?
Fenlason, Josh wrote: What is the latest stable mod_jk? I know there was a vote for 1.2.15. What is the status of that? On the download page it has links to 1.2.14, but these links are broken. (http://tomcat.apache.org/download-connectors.cgi) I have repaired the download page. On the documentation page, 1.2.13 is the latest listed. (http://tomcat.apache.org/connectors-doc/) If anyone would be able to clarify this for me, I would be grateful. The page should tell something like "JK-1.2.14" according to the source in svn... Thanks in advance. , Josh. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Latest mod_jk?
Jean-frederic Clere wrote: Fenlason, Josh wrote: What is the latest stable mod_jk? I know there was a vote for 1.2.15. What is the status of that? On the download page it has links to 1.2.14, but these links are broken. (http://tomcat.apache.org/download-connectors.cgi) I have repaired the download page. On the documentation page, 1.2.13 is the latest listed. (http://tomcat.apache.org/connectors-doc/) If anyone would be able to clarify this for me, I would be grateful. The page should tell something like "JK-1.2.14" according to the source in svn... I have fixed it. Thanks in advance. , Josh. - 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]
tomcat/build/tc5.5.x/resources/build.xml
hi, This file uses cvs but it should do the same with svn. The question is how to solve the problem: 1 - using a like: +++ +++ 2 - Using svnant (http://subclipse.tigris.org/svnant.html). 3 - Using AntSvnTask (http://antsvntask.sourceforge.net/subtask.html). 4 - Something else? (like using javasvn: http://tmate.org/svn/). Comments? Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat/build/tc5.5.x/resources/build.xml
Costin Manolache wrote: Isn't possible to get a svn tree using http download ? I tought one of the benefits of svn is that it uses http. gets only one file not the complete tree ;-( Jean-frederic Costin On 10/18/05, Jean-frederic Clere <[EMAIL PROTECTED]> wrote: hi, This file uses cvs but it should do the same with svn. The question is how to solve the problem: 1 - using a like: +++ +++ 2 - Using svnant (http://subclipse.tigris.org/svnant.html). 3 - Using AntSvnTask (http://antsvntask.sourceforge.net/subtask.html). 4 - Something else? (like using javasvn: http://tmate.org/svn/). Comments? Cheers Jean-Frederic - 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]
Re: [JK] Status -- was [VOTE] JK 1.2.15
Mladen Turk wrote: William A. Rowe, Jr. wrote: Do you guys find something that would prevent 1.2.15 to be declared as stable that I'm missing? I'll try to find cycles to test myself, next week. I know I'm having alot of trouble with the apache 1.3 build on odd architectures, probably because the clash of a libtool-based mod_jk.so.1.2 v.s. non-libtool based httpd 1.3. I'm working on cleaner autoconf against httpd-2.0 already for building mod_ftp, which will probably apply very cleanly here as well. Fine :) Anyhow, what should I do, since I've volunteer for a RM? I mean, I don't expect to see the 1.3 branch for couple of months from now, and the 1.2.14 is unusable on Solaris, so we need some action. The 1.2.15 (bugfix) release is the only thing that is implementable right now, thought. There are 10 open bug, what about trying to close them before the release? Since there was no reactions to the VOTE either pro or contra for more then a mont, seems to me we are in a serious problem, because the developers/commiter interest is blocking the release. The final solution is either to bring that to the tomcat pmc, and if there is really zero interest on maintaining mod_jk, among the current commiters, it should be either shut down, or proposed as a new project with a different set of maintainers. Regards, Mladen. - 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: tomcat source / eclipse project
hasssip satang wrote: Hi, I'm trying to setup a tomcat eclipse project. Looking through the list archive I've seen that some of you have been sharing their .project and .classpath files. If you could send me these files as well (or point me to a resource where I can download them) that would be really helpful. Setting it up from scratch seems like a really time consuming task. Eclipse obviously does not find all source trees and jars correctly after setting up new projects as stated in http://tomcat.apache.org/tomcat-5.5-doc/building.html . I get tons of error messages. Try to use http://svn.apache.org/repos/asf/tomcat/build/tc5.5.x/resources/build.xml (it worked for me with ant but I have not yet tried it with eclipse). If that helps, I will the build.xml in web site. Also is there a build.xml which is working on the subversion repository already? For my first tests I used the one mentioned in the article found under the link above. This, however, is working on the 'old' CVS repository. Thanks, Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sloppy, Lazy Tomcat Developers (Was: Persistent "xmlValidation" Problem)
Bob Bronson wrote: Comments below, for any of you who care Friendly peoples always care about the needs of other... + CUT ++ I installed a fresh copy of TC 5.5.12 (using JDK 1.5.0 on Win XP). I went into the server.xml that is distributed with TC and changed the 'xmlValidation' attribute value to "true" on the attribute. What do you think happened? I got tons of meaningless stack traces. meaningless... I don't think so. Open a bug in bugzilla so that someone could think of fixing what is wrong. This tells me one of two things -- either the sloppy Tomcat open sores programmers released an invalid web.xml that doesn't validate *OR* that the 'xmlValidation' functionality is broken. The fact that Tomcat 5.5.12 was released with this very basic (admit it, it's not a subtle issue) problem indicates to me the poor state of testing the Tomcat programmers must do at a system level. When I set the 'xmlValidation' attribute to 'true' I get a big stack trace. One would think it might be appropriate to offer a nice error message describing the problem. Blame Xerces ;-). XML error are not always easy to discover. You say that the lousy XML error messages are something I should "blame on Xerces". Yes, we could blame xerces... Xerces is also in ASF (we are blaming ourself). OpenSource works because developers and users are playing togother, not one against the other. Unfriendy messages tends to cause unfriendly answer, but keep cool, report the errors, propose a patch, propose a work-around... Well do something that helps you. +++ CUT +++ The fact that the Tomcat User mailing list often receives over 150 messages a day is more a testament to Tomcat's crappy documentation than to its popularity. Well Tomcat documentation needs _urgent_ improvements. Cheers Jean-Frederic Yes, yes, I know Tomcat is "not for me". You're damned right. I'm happy to pay money for quality. I guess Tomcat bares out the old adage, "you get what you pay for". - 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: HPUX Itanium Native Connector Build Error
Fenlason, Josh wrote: Hey everybody! I'm trying to build the native apr connector from Tomcat 5.5.12 on HPUX Itanium and I'm running into a problem during the configure. APR 1.2.2 built fine. I built OpenSSL 0.9.8a as a static library (I couldn't get it to build as a shared library.) When I try to configure the tomcat native connector, I get the following error: checking for openssl/engine.h... yes checking for SSLeay_version in -lcrypto... no checking for SSL_CTX_new in -lssl... no checking for ENGINE_init... no checking for ENGINE_load_builtin_engines... no checking for SSL_set_cert_store... no configure: error: ... Error, SSL/TLS libraries were missing or unusable The config.log probably contains more information about what is going wrong. Here's my build environment: gcc 3.3.1 gnu make 3.79.1 Here's how I configured the native connector CC="gcc -static-libgcc" \ CPPFLAGS="-I/home/snow/jfenlason/hp/lib/opensslStaticDist/include" \ SHLIB_PATH="/home/snow/jfenlason/hp/lib/opensslStaticDist/lib" \ CFLAGS="-O2" \ ./configure \ "--prefix=/home/snow/jfenlason/hp/lib/tomcatNativeConnector" \ "--with-apr=/home/snow/jfenlason/hp/lib/apr" \ "--with-ssl=/home/snow/jfenlason/hp/lib/opensslStaticDist" \ "--with-java_home=/opt/java1.5" \ "--with-java-platform=2" \ "$@" Has anyone been able to get this to work? Suggestions on what I'm doing wrong would be greatly appreciated. Thanks in advance. , Josh. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AprEndpoint and IPv6
Jim Jagielski wrote:
There's a bug report (37788) regarding allowing AprEndpoint
to use APR IPv6 addresses. Their patch is almost right, but
instead the value should be to use APR_UNSPEC instead
of APR_INET6 (or the current APR_INET) to allow APR
to correctly determine IP version and do a graceful
recovery... As well as handle cases where APR wasn't
built with IPv6 support.
I'd like to commit that change... comments?
Looking to src/network.c, I have noted:
+++
if (family > 0) {
TCN_THROW_IF_ERR(apr_socket_create(&s,
f, t, protocol, p), a);
}
+++
Isn't APR_UNSPEC defined to zero? - that would explain the problem
decribed in
http://issues.apache.org/bugzilla/attachment.cgi?id=17525 -
Cheers
Jean-Frederic
-
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: AprEndpoint and IPv6
Jim Jagielski wrote: There's a bug report (37788) regarding allowing AprEndpoint to use APR IPv6 addresses. Their patch is almost right, but instead the value should be to use APR_UNSPEC instead of APR_INET6 (or the current APR_INET) to allow APR to correctly determine IP version and do a graceful recovery... As well as handle cases where APR wasn't built with IPv6 support. I'd like to commit that change... comments? -1: It also cores on my machine. +++ # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0xa808eb5e, pid=10005, tid=3084708160 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode) # Problematic frame: # C [libapr-1.so.0+0x19b5e] apr_socket_bind+0x2e # +++ APR_INET6 works OK with the same configuration. - 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: AprEndpoint and IPv6
Jean-frederic Clere wrote:
Jim Jagielski wrote:
There's a bug report (37788) regarding allowing AprEndpoint
to use APR IPv6 addresses. Their patch is almost right, but
instead the value should be to use APR_UNSPEC instead
of APR_INET6 (or the current APR_INET) to allow APR
to correctly determine IP version and do a graceful
recovery... As well as handle cases where APR wasn't
built with IPv6 support.
I'd like to commit that change... comments?
-1: It also cores on my machine.
+++
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
# SIGSEGV (0xb) at pc=0xa808eb5e, pid=10005, tid=3084708160
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode)
# Problematic frame:
# C [libapr-1.so.0+0x19b5e] apr_socket_bind+0x2e
#
+++
APR_INET6 works OK with the same configuration.
With the following patch:
+++
Index: src/network.c
===
--- src/network.c (revision 373299)
+++ src/network.c (working copy)
@@ -280,7 +280,7 @@
GET_S_FAMILY(f, family);
GET_S_TYPE(t, type);
-if (family > 0) {
+if (family >= 0) {
TCN_THROW_IF_ERR(apr_socket_create(&s,
f, t, protocol, p), a);
}
@@ -290,7 +290,7 @@
a = (tcn_socket_t *)apr_pcalloc(p, sizeof(tcn_socket_t));
a->sock = s;
a->pool = p;
-if (family > 0)
+if (family >= 0)
a->net = &apr_socket_layer;
a->opaque = s;
apr_pool_cleanup_register(p, (const void *)a,
+++
It works.
Comments?
Cheers
Jean-Frederic
-
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]
war deployement question
Hi, I have small question: In which class(es) are the warfiles deployed? Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: war deployement question
Remy Maucherat wrote: Jean-frederic Clere wrote: Hi, I have small question: In which class(es) are the warfiles deployed? In Tomcat, the "deployer" is a listener class for the Host, called HostConfig. Thanks, I am now in ExpandWar.java ;-) Cheers Jean-Frederic 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: Strange Google search text for Tomcat
Costin Manolache wrote:
If you do a search for the snippet, one of the first links is in the
directory -
http://www.google.com/Top/Computers/Programming/Languages/Java/Server-Side/Servlets/Servlet_Engines/
Searching for resin or servletexec will also show the snippents from
the directory - so it's likely the source.
Don't know how it could be fixed - either submit it with the right
description, or maybe ask to become an editor ?
I have applied for it.
Cheers
Jean-Frederic
Costin
( with standard disclaimers, I just did a quick search :-)
On 2/25/06, Yoav Shapira <[EMAIL PROTECTED]> wrote:
Hi,
When I do a Google search for Tomcat, the first result is
tomcat.apache.org as expected, but the snippet line that google
displays is strange, saying something about Tomcat growing into a
fuller J2EE container. Does anyone have a clue where the line under
the top result ("has grown into...") comes from?
Attaching a screenshot to show this, though it's easy to reproduce by
just googling for tomcat...
--
Yoav Shapira
System Design and Management Fellow
MIT Sloan School of Management
Cambridge, MA, USA
[EMAIL PROTECTED] / www.yoavshapira.com
-
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]
Re: svn commit: r381081 - /tomcat/container/tc5.5.x/webapps/docs/logging.xml
Hi, Next question: how do I republish the http://tomcat.apache.org/tomcat-5.5-doc pages? Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New build ?
Remy Maucherat wrote: Hi, Because of the critical AJP bugfix found and fixed earlier today, would it be possible to plan releasing a new 5.5.16 build soon ? +1... I have something not working when deploying an application with the 5.5.15 and using trunk helps ;-) Cheers Jean-Frederic Sorry for the trouble (once again ...). 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: [ANN] Apache Tomcat v5.5.16-beta Now Available
Yoav Shapira wrote: The Apache Tomcat team is proud to announce the immediate availability of Tomcat v5.5.16-beta. This release contains dozens of bug fixes and a number of other updates. Please consult the change log below for more details. Release Notes: http://tomcat.apache.org/tomcat-5.5-doc/RELEASE-NOTES Change Log: http://tomcat.apache.org/tomcat-5.5-doc/changelog.html Downloads: http://tomcat.apache.org/download-55.cgi Why commons-fileupload has not been upgraded to its lastest version? The 1.0 has a bug that prevents upload+deploy working on no-ascii machines (EBCDIC). Cheers Jean-Frederic Thank you, The Apache Tomcat Team - 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: [ANN] Apache Tomcat v5.5.16-beta Now Available
Yoav Shapira wrote: Hola, The dependency update process is not automatic. Someone needs to update the dependency and test the build before committing the revised build.properties.default file. I sometimes do this myself, but for 5.5.16 I didn't have time to check all the dependencies for updated versions... Ok... If nobody complains I will update the file in svn... For the next version. Cheers Jean-Frederic Yoav On 3/6/06, Jean-frederic Clere <[EMAIL PROTECTED]> wrote: Yoav Shapira wrote: The Apache Tomcat team is proud to announce the immediate availability of Tomcat v5.5.16-beta. This release contains dozens of bug fixes and a number of other updates. Please consult the change log below for more details. Release Notes: http://tomcat.apache.org/tomcat-5.5-doc/RELEASE-NOTES Change Log: http://tomcat.apache.org/tomcat-5.5-doc/changelog.html Downloads: http://tomcat.apache.org/download-55.cgi Why commons-fileupload has not been upgraded to its lastest version? The 1.0 has a bug that prevents upload+deploy working on no-ascii machines (EBCDIC). Cheers Jean-Frederic Thank you, The Apache Tomcat Team - 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] -- Yoav Shapira Senior Architect Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - 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]
apache-tomcat-5.5.15-src/connectors/jni/native/configure
Hi, Why aren´t we providing a configure in the released sources? Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
bad permissions in the 5.5.16 sources tar file.
Hi, I am trying to build libtcnative-1.so using the 5.5.16 sources tar file and I have the following problem: +++ buildconf: line 83: build/get-version.sh: Permission denied [EMAIL PROTECTED]:~/apache-tomcat-5.5.16-src/connectors/jni/native$ ls -lt build/get-version.sh -rw-r--r-- 1 tomcat5 tomcat5 1156 Mar 5 02:25 build/get-version.sh +++ Strange permissions in trunk are ok, any hints? Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bad permissions in the 5.5.16 sources tar file.
Bill Barker wrote: -Original Message- From: Jean-frederic Clere [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 14, 2006 2:34 PM To: Tomcat Developers List Subject: bad permissions in the 5.5.16 sources tar file. Hi, I am trying to build libtcnative-1.so using the 5.5.16 sources tar file and I have the following problem: +++ buildconf: line 83: build/get-version.sh: Permission denied [EMAIL PROTECTED]:~/apache-tomcat-5.5.16-src/connectors/jni/na tive$ ls -lt build/get-version.sh -rw-r--r-- 1 tomcat5 tomcat5 1156 Mar 5 02:25 build/get-version.sh +++ Strange permissions in trunk are ok, any hints? Urm, 'chmod +x build/*.sh'? Sure... But my question was more why are the permission not ok in the tar file? They probably should have svn:executable set on them at some point. Cheers Jean-Frederic - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ParserController.java
Hi,
One of the patches I need to get TC working with JSP in EBCDIC is the
following:
+++
---
/home2/tomcat5/apache-tomcat-5.5.15-src.org/jasper/jasper2/src/share/org/apa
che/jasper/compiler/ParserController.java 2006-01-03
15:15:14.0 +0
000
+++
apache-tomcat-5.5.15/apache-tomcat-5.5.15-src/jasper/jasper2/src/share/org/a
pache/jasper/compiler/ParserController.java 2006-03-15
09:31:28.0 +0
000
@@ -372,7 +372,8 @@
* Determine the page encoding from the page directive, unless it's
* specified via JSP config.
*/
- sourceEnc = jspConfigPageEnc;
+if (jspConfigPageEnc != null)
+ sourceEnc = jspConfigPageEnc;
if (sourceEnc == null) {
sourceEnc = getPageEncodingForJspSyntax(jspReader, startMark);
if (sourceEnc == null) {
+++
If I get it right I would say that if jspConfigPageEnc is null we should
used the sourceEnc to read the JSP file, so this patch is also needed
for all the encodings.
Any comments?
Cheers
Jean-Frederic
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ParserController.java
Mladen Turk wrote: Jean-frederic Clere wrote: Hi, One of the patches I need to get TC working with JSP in EBCDIC is the following: Any comments? Yes. Fix your clock. You live in the future :) Have to fix the past to be allow to live in the future :) Cheers, Mladen. - 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: svn commit: r386315 - /tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/ParserController.java
Bill Barker wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, March 16, 2006 3:55 AM To: tomcat-dev@jakarta.apache.org Subject: svn commit: r386315 - /tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/Pa rserController.java Author: jfclere Date: Thu Mar 16 03:54:29 2006 New Revision: 386315 URL: http://svn.apache.org/viewcvs?rev=386315&view=rev Log: If the encoding is not specified use the detected one. -1. If it gets to this point, the detected encoding is *wrong* (e.g. in JSP syntax). Why wrong? +++ Connected to localhost. Escape character is '^]'. GET /try1.jsp http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> +++ I don't have access to an EBCDIC machine to know what the problem is, but this isn't the fix. Possibly a better way to guess the encoding of the Reader? Thinking to it the patch is not prefect but the old code is worse we have a piece of code that detects correctly the source encoding and detroy it... In doParse() in ParserController.java the following happends parse() is called with pageEnc = sourceEnc jspConfigPageEnc = null isDefaultPageEncoding = false. But the line before the jspReader uses the sourceEnc to create the InputStreamReader so the content of the file is translated to utf-8 when reading it. In validator.java the charset will be set to the detected encoding... In the example above iso-8859.2. Bad for me that will be OSD_EBCDIC_DF04_1. Cheers Jean-Frederic 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r386315 - /tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/ParserController.java
Costin Manolache wrote: Sorry, I forgot there are 2 meanings of 'xml syntax' :-), I was thinking if the output is an xml file - with encoding in declaration, but in regular jsp. (well, the patch is not dealing with jspx anyway ) I was referring to the fact that is treated as template text, and pageEncoding (or web.xml ) takes precedence. In jsp-xml ( jspx ) it seems we report an error if the web.xml encoding doesn't match the encoding. I can't see many use cases for having an explicit encoding in the xml header, and yet the file read with a different encoding. In my case the xml header is: (In EBCDIC...) Reading the file with ISO-8859-1 encoding only gives garbages. But the patch prevents reading the <@page pageEncoding="bla" %> so it is bad. The old code should be improved to allow to use the sourceEnc when the pageEncoding is not specified and ISO-8859-1 if none are specified. Cheers Jean-Frederic Costin On 3/17/06, Bill Barker <[EMAIL PROTECTED]> wrote: -Original Message- From: Costin Manolache [mailto:[EMAIL PROTECTED] Sent: Friday, March 17, 2006 11:57 AM To: Tomcat Developers List Subject: Re: svn commit: r386315 - /tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/Pa rserController.java In his example ( where both XML and JSP declare encodings ) - which one would win ? The patch only affects pages in JSP syntax, so the is just another piece of template text :). IMO the XML encoding should win i.e. if the file uses xml syntax and starts with , then jsp pageEncoding should be ignored. If a jsp is written using the XML syntax - it is supposed to follow the XML rules - there is no exception in the XML spec for jsps specifying their different syntax for encoding. The JSP expert group agrees with you:). In XML syntax, the XML encoding should win out over . For non-XML jsps - I think respecting pageEncoding is a must, the jsp reader must scan the file to find the pageEncoding string - which is not trivial ( there is a reason why XML requires the encoding to be the first thing in the file, at the top, I would't bet on jasper implementing it correctly :-) In JSP syntax, the spec (Appendix D) says that pageEncoding should win (at least when there is no matching in web.xml :). What the patch breaks is that with it Jasper won't even look for the pageEncoding most of the time. Jasper looks like it does a pretty good job of guessing to set up the Reader that scans for the pageEncoding directive. And JFC seems to agree, since the patch is to use the guessed encoding rather than the one that was specified :). Costin On 3/17/06, Bill Barker <[EMAIL PROTECTED]> wrote: -Original Message- From: Jean-frederic Clere [mailto:[EMAIL PROTECTED] Sent: Friday, March 17, 2006 4:13 AM To: Tomcat Developers List Subject: Re: svn commit: r386315 - /tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/Pa rserController.java Bill Barker wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, March 16, 2006 3:55 AM To: tomcat-dev@jakarta.apache.org Subject: svn commit: r386315 - /tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/Pa rserController.java Author: jfclere Date: Thu Mar 16 03:54:29 2006 New Revision: 386315 URL: http://svn.apache.org/viewcvs?rev=386315&view=rev Log: If the encoding is not specified use the detected one. -1. If it gets to this point, the detected encoding is *wrong* (e.g. version="1.0" encoding="iso-8859-2" ?> in JSP syntax). Why wrong? Because the right encoding is the one specified in the <[EMAIL PROTECTED] pageEncoding="utf8"%>. +++ Connected to localhost. Escape character is '^]'. GET /try1.jsp http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> +++ This is about pageEncoding, so I don't see the relevance. I don't have access to an EBCDIC machine to know what the problem is, but this isn't the fix. Possibly a better way to guess the encoding of the Reader? Thinking to it the patch is not prefect but the old code is worse we have a piece of code that detects correctly the source encoding and detroy it... However, the old code adheres to the JSP spec, whereas your patch breaks the JSP spec (Appendix D). That automatically makes the old code better than your patch. In doParse() in ParserController.java the following happends parse() is called with pageEnc = sourceEnc jspConfigPageEnc = null isDefaultPageEncoding = false. But the line before the jspReader uses the sourceEnc to
Re: svn commit: r386315 - /tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/ParserController.java
Costin Manolache wrote: Sorry, I forgot there are 2 meanings of 'xml syntax' :-), I was thinking if the output is an xml file - with encoding in declaration, but in regular jsp. (well, the patch is not dealing with jspx anyway ) I was referring to the fact that is treated as template text, and pageEncoding (or web.xml ) takes precedence. In jsp-xml ( jspx ) it seems we report an error if the web.xml encoding doesn't match the encoding. I can't see many use cases for having an explicit encoding in the xml header, and yet the file read with a different encoding. The spec (JavaServer Pages 2.1 Specification (Proposed Final Draft 2) page 3-113 says: +++ The page character encoding of documents in XML syntax is now always detected in the XML specification. The pageEncoding attribute and/or page-encoding configuration element may be given, but must not disagree with the XML prolog. +++ What should we do if the disagreement happends? Costin On 3/17/06, Bill Barker <[EMAIL PROTECTED]> wrote: -Original Message- From: Costin Manolache [mailto:[EMAIL PROTECTED] Sent: Friday, March 17, 2006 11:57 AM To: Tomcat Developers List Subject: Re: svn commit: r386315 - /tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/Pa rserController.java In his example ( where both XML and JSP declare encodings ) - which one would win ? The patch only affects pages in JSP syntax, so the is just another piece of template text :). IMO the XML encoding should win i.e. if the file uses xml syntax and starts with , then jsp pageEncoding should be ignored. If a jsp is written using the XML syntax - it is supposed to follow the XML rules - there is no exception in the XML spec for jsps specifying their different syntax for encoding. The JSP expert group agrees with you:). In XML syntax, the XML encoding should win out over . For non-XML jsps - I think respecting pageEncoding is a must, the jsp reader must scan the file to find the pageEncoding string - which is not trivial ( there is a reason why XML requires the encoding to be the first thing in the file, at the top, I would't bet on jasper implementing it correctly :-) In JSP syntax, the spec (Appendix D) says that pageEncoding should win (at least when there is no matching in web.xml :). What the patch breaks is that with it Jasper won't even look for the pageEncoding most of the time. Jasper looks like it does a pretty good job of guessing to set up the Reader that scans for the pageEncoding directive. And JFC seems to agree, since the patch is to use the guessed encoding rather than the one that was specified :). Costin On 3/17/06, Bill Barker <[EMAIL PROTECTED]> wrote: -Original Message- From: Jean-frederic Clere [mailto:[EMAIL PROTECTED] Sent: Friday, March 17, 2006 4:13 AM To: Tomcat Developers List Subject: Re: svn commit: r386315 - /tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/Pa rserController.java Bill Barker wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, March 16, 2006 3:55 AM To: tomcat-dev@jakarta.apache.org Subject: svn commit: r386315 - /tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/Pa rserController.java Author: jfclere Date: Thu Mar 16 03:54:29 2006 New Revision: 386315 URL: http://svn.apache.org/viewcvs?rev=386315&view=rev Log: If the encoding is not specified use the detected one. -1. If it gets to this point, the detected encoding is *wrong* (e.g. version="1.0" encoding="iso-8859-2" ?> in JSP syntax). Why wrong? Because the right encoding is the one specified in the <[EMAIL PROTECTED] pageEncoding="utf8"%>. +++ Connected to localhost. Escape character is '^]'. GET /try1.jsp http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> +++ This is about pageEncoding, so I don't see the relevance. I don't have access to an EBCDIC machine to know what the problem is, but this isn't the fix. Possibly a better way to guess the encoding of the Reader? Thinking to it the patch is not prefect but the old code is worse we have a piece of code that detects correctly the source encoding and detroy it... However, the old code adheres to the JSP spec, whereas your patch breaks the JSP spec (Appendix D). That automatically makes the old code better than your patch. In doParse() in ParserController.java the following happends parse() is called with pageEnc = sourceEnc jspConfigPageEnc = null isDefaultPageEncoding = false. But the line before the jspReader us
Re: quick fix to be able to run configure on freebsd 6.0
Tomas Klockar wrote: Hello, this change makes it possible to run configure on freebsd 6.x ---8<8<---8< golf# pwd /usr/local/tomcat5.5/bin/jsvc-src golf# diff configure configure.old 2412,2416d2411 < freebsd6.?) < CFLAGS="$CFLAGS -DOS_FREEBSD -DDSO_DLFCN -D_THREAD_SAFE -pthread" < LDFLAGS="-pthread $LDFLAGS" < supported_os="freebsd" < ;; -8<--8<8<- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] freebsd6.x is already supported by support/apsupport.m4 in svn of jakarta daemon: +++ freebsd*) CFLAGS="$CFLAGS -DOS_FREEBSD -DDSO_DLFCN -D_THREAD_SAFE -pthread" LDFLAGS="-pthread $LDFLAGS" supported_os="freebsd" ;; +++ Time to make a new release of daemon? Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Broken link
Tomas Klockar wrote: On the status page for apache tomcat http://tomcat.apache.org/tomcat-5.5-doc/status.html the link to the open bugs at the bottem of the page is broken. regards /Tomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I have fixed it but I have noted that the 5.5 doc is twice in minotaur: +++ > find /www/tomcat.apache.org -name status.html /www/tomcat.apache.org/tomcat-5.5-doc/printer/status.html /www/tomcat.apache.org/tomcat-5.5-doc/status.html /www/tomcat.apache.org/tomcat-5.0-doc/printer/status.html /www/tomcat.apache.org/tomcat-5.0-doc/status.html /www/tomcat.apache.org/tomcat-5.5-doc-v5.5.15/printer/status.html /www/tomcat.apache.org/tomcat-5.5-doc-v5.5.15/status.html +++ Why and why 5.5.15? Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Found two compiler warnings at MAC OS X at tcnative/apr
Peter Rossbach wrote:
I got these two warnings:
/bin/sh /Users/peter/tools/local//build-1/libtool --silent --
mode=compile gcc -g -O2 -DHAVE_CONFIG_H -DDARWIN -
DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp -g -O2 -
DHAVE_OPENSSL -I/Users/peter/tomcat/develop/tomcat55/connectors/jni/
native/include -I/System/Library/Frameworks/JavaVM.framework/Versions/
1.5/Home/include -I/System/Library/Frameworks/JavaVM.framework/
Versions/1.5/Home/include/ -I/Users/peter/tools/local/include -I/
Users/peter/tools/local//include/apr-1 -o src/os.lo -c src/os.c &&
touch src/os.lo
src/os.c: In function 'Java_org_apache_tomcat_jni_OS_threadCurrent':
src/os.c:49: warning: cast from pointer to integer of different size
/bin/sh /Users/peter/tools/local//build-1/libtool --silent --
mode=compile gcc -g -O2 -DHAVE_CONFIG_H -DDARWIN -
DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp -g -O2 -
DHAVE_OPENSSL -I/Users/peter/tomcat/develop/tomcat55/connectors/jni/
native/include -I/System/Library/Frameworks/JavaVM.framework/Versions/
1.5/Home/include -I/System/Library/Frameworks/JavaVM.framework/
Versions/1.5/Home/include/ -I/Users/peter/tools/local/include -I/
Users/peter/tools/local//include/apr-1 -o src/ssl.lo -c src/ssl.c
&& touch src/ssl.lo
src/ssl.c: In function 'ssl_thread_id':
src/ssl.c:203: warning: cast from pointer to integer of different size
Source code
os.c
TCN_IMPLEMENT_CALL(jlong, OS, threadCurrent)(TCN_STDARGS)
{
UNREFERENCED_STDARGS;
return (jlong)apr_os_thread_current();
}
ssl.c
static unsigned long ssl_thread_id(void)
...
return (unsigned long)((jlong)apr_os_thread_current());
...
Found at after a long typedef search /usr/include/sys/_types.h
struct _opaque_pthread_attr_t { long __sig; char __opaque
[__PTHREAD_ATTR_SIZE__]; };
But I not clear what is the right cast or we need a spezial darwin
handling?
I don't think we need a special darwin handling: I think we can't cast a
apr_os_thread_t to an unsigned long.
Cheers
Jean-Frederic
Regards
Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: "Critical poller failure" when using tcnative
Remy Maucherat wrote: Mladen Turk wrote: Right. I was hoping to have the native release by the end of the week also. Since installer depends on outside natives, the native should be out before the 5.5.17. That's a good idea. There are some small issues with some compile warnings for MacOSX, but nothing critical. Jean-Frédéric said it was a cast problem. If sizeof(apr_os_thread_t) == sizeof(unsigned long) then no problem, if not there is a problem. I don't have access to a MacOSX machine for the moment so I can't check it. Cheers Jean-Frédéric 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: SSL-based SessionTracking/Management
Oliver Schoenwald wrote: Dear developers, I have developed an SSL-based SessionManagement for our university's e-learning system because I was unsuccessful to find any ability of Tomcat 5 to create and manage an SSLSession as in the JSSE-Specification. Several weeks of googling after such a feature and asking questions in the tomcat-user-mailingliste resulted in practically nothing. Because we wanted a session management without having to force our students to activate cookies and without having to do url-rewriting, I did my own development which resulted (after several refactorings) in our own SessionManagement. However, this SessionManagement is only a subpackage of our webapplication, which has also its own authentication mechanism due to other requirements that were set by our users. So far, it is a quite proprietary solution that might be changed to be integrated as an alternative SessionManagement component. Do you use client certificates? I wonder if there is someone or some people who are interested in SSL-based SessionManagement? Or maybe there is some well hidden development underway with the same objective? Maybe we could exchange some experience and ideas and even find a way to add SSL-based SessionManagement to coming Tomcat versions? If I should have been just blind to such a feature in Tomcat and there is already a working solution I apologize for this - in that case - unnecessary question in advance. In that case I would be happy if someone could point me to the right documentation or source code to at least find what I searched for before. Thank you, Oliver Schönwald University of Hagen Germany - 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: Memory leak? (issues.apache.org)
Jeff Turner wrote: Hi, For the last few months, issues.apache.org/jira has been running out of memory about once a week. We've finally got it running in a profiler, and are seeing most of the memory (eg. 486 of 572Mb) used up by char[] buffers in BodyContentImpl. Here is a sample GC Root -> Object trace: char[16777218] cb of org.apache.jasper.runtime.BodyContentImpl [0] of org.apache.jasper.runtime.BodyContentImpl[7] outs of org.apache.jasper.runtime.PageContextImpl [86] of java.lang.Object[101] pool of org.apache.jasper.util.SimplePool pool of org.apache.jasper.runtime.JspFactoryImpl deflt of javax.servlet.jsp.JspFactory [57] of java.lang.Object[641] elementData of java.util.Vector classes of org.apache.catalina.loader.StandardClassLoader [Other] There seems to be a constantly increasing number of BodyContentImpl objects in the system: 1 May: 93 Objects (126Mb) 2 May: 107 Objects (263Mb) 3 May: 492 Objects (486MB) (the first two were taken directly after a full gc) It appears to be a case of this bug: http://issues.apache.org/bugzilla/show_bug.cgi?id=37793 Perhaps this bug affects the ASF JIRA in particular (and not most people) because people occasionally request huge (20-30Mb) pages. There are 23 BodyContentImpls between 33Mb and 10Mb in the last dump, and due to the pooling, these all stick around taking up memory. Could anyone comment on this issue? Remy seemed to think it was 'as intended', and the bug is marked WONTFIX. I'm happy to provide yourkit memory dumps or access to the server if necessary. We're currently running 5.5.16. Reopen the bug, there seem to be something really wrong... Cheers Jean-Frederic Thanks! Jeff - 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: Memory leak? (issues.apache.org)
Jeff Turner wrote: Hi, For the last few months, issues.apache.org/jira has been running out of memory about once a week. We've finally got it running in a profiler, and are seeing most of the memory (eg. 486 of 572Mb) used up by char[] buffers in BodyContentImpl. Here is a sample GC Root -> Object trace: char[16777218] cb of org.apache.jasper.runtime.BodyContentImpl [0] of org.apache.jasper.runtime.BodyContentImpl[7] outs of org.apache.jasper.runtime.PageContextImpl [86] of java.lang.Object[101] pool of org.apache.jasper.util.SimplePool pool of org.apache.jasper.runtime.JspFactoryImpl deflt of javax.servlet.jsp.JspFactory [57] of java.lang.Object[641] elementData of java.util.Vector classes of org.apache.catalina.loader.StandardClassLoader [Other] There seems to be a constantly increasing number of BodyContentImpl objects in the system: 1 May: 93 Objects (126Mb) 2 May: 107 Objects (263Mb) 3 May: 492 Objects (486MB) (the first two were taken directly after a full gc) It appears to be a case of this bug: http://issues.apache.org/bugzilla/show_bug.cgi?id=37793 Perhaps this bug affects the ASF JIRA in particular (and not most people) because people occasionally request huge (20-30Mb) pages. There are 23 BodyContentImpls between 33Mb and 10Mb in the last dump, and due to the pooling, these all stick around taking up memory. Could anyone comment on this issue? Remy seemed to think it was 'as intended', and the bug is marked WONTFIX. I'm happy to provide yourkit memory dumps or access to the server if necessary. We're currently running 5.5.16. Have you try to set org.apache.jasper.runtime.JspFactoryImpl.USE_POOL to false? (adding -Dorg.apache.jasper.runtime.JspFactoryImpl.USE_POOL=false to CATALINA_OPTS environment variable). Cheers Jean-Frederic Thanks! Jeff - 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]
JK3 roadmap?
Hi, I have noted that nothing has happened in tomcat/connectors/trunk/jk3. Nearly 2 months without real road map nor clear specifications, what is wrong? Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK3 roadmap?
Rainer Jung wrote: Whenever I had a couple of hours I was doing small tests with scripting. I think the most valuable first step would be the transformation to APR. Unfortunately this is something I could hekp with, but I wouldn't want to lead, because my experience with APR programing is only medium. APR-izing is something I am willing to do even to lead... (I am APR committer since 1999!) Once APR would be there, I would start working on management threads. But APR is the necessary big first step (at least that's what I think) ... Me too Cheers Jean-Frederic Regards, Rainer Mladen Turk schrieb: jean-frederic clere wrote: I have noted that nothing has happened in tomcat/connectors/trunk/jk3. Nearly 2 months without real road map nor clear specifications, what is wrong? I don't think anything is wrong. We are waiting for the list of requirements, and any suggestion from yours or anybody else side is more then welcome. Regards, Mladen. - 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]
Re: Proposed simplification of CometEvent
Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: nice ultimatum :) let me go through both the proposals and look it over. after that I suggest we simply have/agree on a majority vote without vetoes to be able to move on properly. in the vote announcement, I think we should simply outline the differences so that folks understand that rather than getting confused in comet concepts. you and I can draft that outline together offline, I understand your answer as that your position on this proposal did not change. As far as I am concerned, proposals are consensus, not votes. I also don't think people are interested enough to vote. A vote proposal should be [VOTE] in the subject. Like [VOTE] Which Comet implementation/API to use. You just answer to an old thread so that doesn't cache the attention of community. Cheers Jean-Frederic 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: svn commit: r551809 - /tomcat/connectors/trunk/jk/native/common/jk_msg_buff.c
[EMAIL PROTECTED] wrote:
Author: mturk
Date: Thu Jun 28 23:32:27 2007
New Revision: 551809
URL: http://svn.apache.org/viewvc?view=rev&rev=551809
Log:
Fix potential overflow. The actual encoded string length is strlen + 3 (Two
bytes for len and one '\0')
Modified:
tomcat/connectors/trunk/jk/native/common/jk_msg_buff.c
Modified: tomcat/connectors/trunk/jk/native/common/jk_msg_buff.c
URL:
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_msg_buff.c?view=diff&rev=551809&r1=551808&r2=551809
==
--- tomcat/connectors/trunk/jk/native/common/jk_msg_buff.c (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_msg_buff.c Thu Jun 28 23:32:27
2007
@@ -173,7 +173,7 @@
}
len = (unsigned short)strlen(param);
-if (msg->len + len + 2 > msg->maxlen) {
+if (msg->len + len + 3 > msg->maxlen) {
return -1;
}
@@ -181,7 +181,7 @@
jk_b_append_int(msg, len);
/* We checked for space !! */
-strncpy((char *)msg->buf + msg->len, param, len + 1); /* including
\0 */
+memcpy(msg->buf + msg->len, param, len + 1); /* including \0 */
Why do you remove the (char *)?
Cheers
Jean-Frederic
#if (defined(AS400) && !defined(AS400_UTF8)) || defined(_OSD_POSIX)
/* convert from EBCDIC if needed */
jk_xlate_to_ascii((char *)msg->buf + msg->len, len + 1);
-
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: JK3 roadmap?
Jim Jagielski wrote: On Jun 27, 2007, at 11:27 AM, jean-frederic clere wrote: Rainer Jung wrote: Whenever I had a couple of hours I was doing small tests with scripting. I think the most valuable first step would be the transformation to APR. Unfortunately this is something I could hekp with, but I wouldn't want to lead, because my experience with APR programing is only medium. APR-izing is something I am willing to do even to lead... (I am APR committer since 1999!) Ummm... APR wasn't even created until Dec of 2000 I am getting old ;-) Cheers Jean-Frederic - 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: Feature request /Discussion: JK loadbalancer improvements for high load
Henri Gomez wrote: Something we should also check is the CPU load of the Tomcat instance. May be it will be usefull also to let users/admin add their own counters in the load estimation. If you want to add this to Tomcat remeber that stuff needs a JNI module to collect information from the OS/hardware and that is an OS depend code. Cheers Jean-Frederic For example, if some admins considers we should base the load-balancing on HTTP requests or SQL access, and they have these counters on their webapp applications, it will be usefull to be able to get them from Tomcat to send them back to jk balancer. It shouldn't be too hard and very welcome for many Tomcat sites 2007/7/4, Rainer Jung <[EMAIL PROTECTED]>: Hi, implementing a management communication between the lb and the backend is on the roadmap for jk3. It is somehow unlikely, that this will help in your situation, because when doing a GC the jvm will no longer respond to the management channel. Traditional Mark Sweep Compact GC is not distinguishable from the outside from a halt in the backend. Of course we could think of a webapp trying to use the JMX info on memory consumption to estimate GC activity in advance, but I doubt that this will be a stable solution. There are notifications, when GCs happen, but at the moment I'm not sure, if such events exist, before, or only after a GC. I think a first step (and a better solution) would be to use modern GC algorithms like Concurrent Mark Sweep, which will most of the time reduce the GC stop times to some 10s or 100s of milliseconds (depending on heap size). CMS comes with a cost, a little more memory needed and a little more CPU needed, but the dramatically decreased stop times are worth it. Also it is quite robust since about 1-2 years. Other components will not like long GC pauses as well, like for instance cluster replication. There you configure the longest pause you accept for missing heartbeat packets before assuming a node is dead. Assuming a node being dead because of GC pauses and then the node suddenly works without having noticed itself that it outer world has changed is a very bad situation too. What we plan as a first step for jk3 is putting mod_jk on the basis of the apache APR libraries. Then we can relatively easily use our own management threads to monitor the backend status and influence the balancing decisions. As long as we do everything on top of the request handling threads we can't do complex things in a stable way. Getting jk3 out of the door will take some longer time (maybe 6 to 12 months'for a release). People willing to help are welcome. Concerning the SLAs: it always makes sense to put a percentage limit on the maximum response times and error rates. A 100% below some limit clause will always be to expensive. But of course, if you can't reduce GC times and the GC runs to often, there will be no acceptable percentage for long running requests. Thank you for sharing your experiences at Langen with us! Regards, Rainer Yefym Dmukh wrote: > Hi all, > sorry for the stress but it seems that it is a time to come back to the > discussion related to the load balancing for JVM (Tomcat). > > Prehistory: > Recently we made benchmark and smoke tests of our product at the sun high > tech centre in Langen (Germany). > > As the webserver apache2.2.4 has been used, container -10xTomcat 5.5.25 > and as load balancer - JK connector 1.2.23 with busyness algorithm. > > Under the high load the strange behaviour was observed: some > tomcat workers temporary got the non-proportional load, often 10 times > higher then the others for the relatively long periods. As the result the > response times that usually stay under 500ms went up to 20+ sec, that in > its turn made the overall test results almost two time worst as > estimated. > > At the beginning we were quite confused, because we were > sure that it was not the problem of JVM configuration and supposed that > the reason is in LB logic of mod_jk, and the both suggestions were right. > > Actually the following was happening: the LB sends requests and gets the > session sticky, continuously sending the upcoming requests to the same > cluster node. At the certain period of time the JVM started the major > garbage collection (full gc) and spent, mentioned above, 20 seconds. At > the same time jk continued to send new requests and the sticky to node > requests that led us to the situation where the one node broke the SLA on > response times. > > I ^ve been searching the web for awhile to find the LoadBalancer > implementation that takes an account the GC activity and reduces the load > accordingly case JVM is close to the major collection, but nothing found. > > Once again the LB of JVMs under the load is really an issue for production > and with optimally distributed load you are able not only to lower the > costs, but also able to prevent bad customer experience, not to mention > bro
Removing the examples (JSP/servlet) in TC Binaries
Hi, The examples (servlet and JSP) have caused a list of security issues. I think we should remove them from the Tomcat binary packages (6.0 and 5.x at least). Any comments? Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat supporting PHP
Joe Nathan wrote: I am talking about in-built capability that people do NOT need to install heaps of cranky-installation software packages! You may try http://labs.jboss.com/wiki/Jbossweb and http://labs.jboss.com/file-access/default/members/jbossweb/freezone/modules/php/index.html Cheers Jean-Frederic regards. Yoav Shapira-2 wrote: Hey, On 7/14/07, Bill Barker <[EMAIL PROTECTED]> wrote: "Joe Nathan" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] I think if Tomcat also supports PHP scripts, it could be wonderful!. Google is your friend :) http://www.google.com/search?q=php+servlet. I don't think that there is much interest in hosting a PHP servlet in Tomcat however. Bill's right. I also wrote up (the initial version of) http://wiki.apache.org/tomcat/UsingPhp a while ago, if you're still interested in this approach. Yoav - 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: Tomcat supporting PHP
Hi, I am thinking that this thread goes to nowhere... To get some php stuff in TC you have 3 solutions: 1- FastCGI. 2- PHP engine embedded in in the JVM. 3- PHP rewritten in JAVA. 1 - That probably the best solution but you need a FastCGI proxy servlet (Could be a good application for the new Comet stuff). 2 - That also needs a servlet and a careful build of the php engine and it extensions. 3 - I don't think that the scope of the Tomcat project. Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat supporting PHP
Henri Gomez wrote: PHP rewritten in Java could be a good idea for the core but what about the various extensions ? That is a very hard part that needs JNI to load and to interface the API of the extensions. There are also very easily threads and memory models problems. Such a wrapper seems a huge thing to write. Cheers Jean-Frederic Of course it couldn't be a Tomcat project 2007/7/19, jean-frederic clere <[EMAIL PROTECTED]>: Hi, I am thinking that this thread goes to nowhere... To get some php stuff in TC you have 3 solutions: 1- FastCGI. 2- PHP engine embedded in in the JVM. 3- PHP rewritten in JAVA. 1 - That probably the best solution but you need a FastCGI proxy servlet (Could be a good application for the new Comet stuff). 2 - That also needs a servlet and a careful build of the php engine and it extensions. 3 - I don't think that the scope of the Tomcat project. Cheers Jean-Frederic - 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]
Re: svn commit: r557664 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/valves/SSLValve.java
Bill Barker wrote:
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 19, 2007 8:52 AM
To: [EMAIL PROTECTED]
Subject: svn commit: r557664 -
/tomcat/tc6.0.x/trunk/java/org/apache/catalina/valves/SSLValve.java
Author: jfclere
Date: Thu Jul 19 08:51:50 2007
New Revision: 557664
URL: http://svn.apache.org/viewvc?view=rev&rev=557664
Log:
This Valve is to extra the SSL informations from additional headers
When using Apache httpd as proxy they are added by
mod_headers and the following directives:
RequestHeader set SSL_CLIENT_CERT "%{SSL_CLIENT_CERT}s"
RequestHeader set SSL_CIPHER "%{SSL_CIPHER}s"
RequestHeader set SSL_SESSION_ID "%{SSL_SESSION_ID}s"
RequestHeader set SSL_CIPHER_USEKEYSIZE "%{SSL_CIPHER_USEKEYSIZE}s"
Out of curiosity, why not just use AJP/1.3?
One possible use is for example to use https between httpd and TC so
that the connection can be encrypted.
Cheers
Jean-Frederic
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Send trunk to the sandbox
Bill Barker wrote: > I'm so tired of this thread, so let's settle it once and for all. I'm > backing Remy's suggestion to send the current trunk to the sandbox: > [X] +1 Let's end the revolution I would also propose that we take an handling of releases similar to httpd. See http://svn.apache.org/repos/asf/httpd/httpd/ branches contains the productions branches and the experimental developpemnt branches. trunk contains the place where the commmun developement and the new agreed features and bugs fixes are going. To move something from the "experimental developpement branches" to trunk (or to a production branche) we vote it. (in a file named STATUS) once accepted (no -1) the stuff enters the production or trunk. If someone starts something in trunk and gets a -1 he should create a new branche with the new code and propose a vote to get it back in trunk. What does that means. http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ will be moved to http://svn.apache.org/repos/asf/tomcat/tc6.0.x/branches/comet_dev (or filip_dev) A new http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ (or better http://svn.apache.org/repos/asf/tomcat/trunk/) will be created there we put what we agree to put for the actual trunk (by voting). Everyone that when to try something could try it in a new branche. Comments? Cheers Jean-Frederic > [ ] +0 What revolution? > [ ] -1 Viva the revolultion > > My vote is +1. > > > > > - > 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: [VOTE] Send trunk to the sandbox
Remy Maucherat wrote: > jean-frederic clere wrote: >> Bill Barker wrote: >>> I'm so tired of this thread, so let's settle it once and for all. >>> I'm backing Remy's suggestion to send the current trunk to the sandbox: >>> [X] +1 Let's end the revolution >> >> I would also propose that we take an handling of releases similar to >> httpd. >> See http://svn.apache.org/repos/asf/httpd/httpd/ >> >> branches contains the productions branches and the experimental >> developpemnt branches. >> >> trunk contains the place where the commmun developement and the new >> agreed features and bugs fixes are going. >> To move something from the "experimental developpement branches" to >> trunk (or to a production branche) we vote it. (in a file named STATUS) >> once accepted (no -1) the stuff enters the production or trunk. If >> someone starts something in trunk and gets a -1 he should create a new >> branche with the new code and propose a vote to get it back in trunk. >> >> What does that means. >> http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ will be moved to >> http://svn.apache.org/repos/asf/tomcat/tc6.0.x/branches/comet_dev (or >> filip_dev) >> A new http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ (or better >> http://svn.apache.org/repos/asf/tomcat/trunk/) will be created there we >> put what we agree to put for the actual trunk (by voting). >> Everyone that when to try something could try it in a new branche. >> >> Comments? > > Since the community is a bit small, it could be useful to precise that a > single +1 (from the committer who proposes the commit) is enough for a > commit to go through, rather than the usual 3 +1s. Well my idea was to force two other committers to review a proposal before it gets/returns in the "stable/released" code. Allowing only one +1 from the initial committer to get the code in (or back) prevents this. Cheers Jean-Frederic > > 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: [VOTE] Move trunk to sandbox
Remy Maucherat wrote: Hi, Due to continuing independent development in trunk by Filip, I am calling for a second vote to move it to the sandbox, where Filip could continue developing his ideas in a non disruptive way. I think the whole thing has been debated pretty extensively in the previous vote. Following this, debate should take place to determine if a new main trunk is needed, and if commit procedure changes would be good (personally, I do like Jean-Frédéric's ideas). [ X] +1 Cheers Jean-Frederic [ ] 0 [ ] -1 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]
[VOTE] Make released versions RTC
Hi, I would also propose that we take an handling of release branches similar to httpd. The release branches are: /tomcat/tc6.0.x/trunk /tomcat/build/tc5.5.x/ /tomcat/container/tc5.5.x /tomcat/jasper/tc5.5.x/ (Note it uses /tomcat/connectors/trunk) /tomcat/build/branches/tc5.0.x /tomcat/container/branches/tc5.0.x /tomcat/connectors/branches/tc5.0.x /tomcat/jasper/branches/tc5.0.x The votes will get in a file named STATUS file and once accepted in a file named CHANGES. The proposal of backports/fixes should be a description of the feature/PR number and a link to a commit (in another branch or sandbox) or a patch (diff -u) against the branch. A proposal needs 3 +1 votes and no -1 to be accepted. The committer that makes the proposal is responsible to commit the new code (and move the proposal from STATUS to CHANGES) in the branch once accepted. [ ] +1 [ ] 0 [ ] -1 Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Make released versions RTC
Tim Funk wrote: > What is a change? Any commit? > > Is a change only for new features and bug fixes are out of scope? My idea is to have it for all commits but only on release branches. The idea is more to force people participating on the development of new feature and help to fixing bugs. Cheers Jean-Frederic > > -Tim > > jean-frederic clere wrote: >> Hi, >> >> I would also propose that we take an handling of release branches >> similar to httpd. >> >> The votes will get in a file named STATUS file and once accepted in a >> file named CHANGES. >> The proposal of backports/fixes should be a description of the >> feature/PR number and a link to a commit (in another branch or sandbox) >> or a patch (diff -u) against the branch. >> A proposal needs 3 +1 votes and no -1 to be accepted. The committer that >> makes the proposal is responsible to commit the new code (and move the >> proposal from STATUS to CHANGES) in the branch once accepted. > > > - > 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: svn commit: r575332 - in /tomcat/tc6.0.x/trunk: java/org/apache/naming/resources/FileDirContext.java webapps/docs/changelog.xml
Filip Hanik - Dev Lists wrote: > Mladen Turk wrote: >> Filip Hanik - Dev Lists wrote: >>> Mladen Turk wrote: This simply has to stop. >>> >>> taking trunk away, this turn of events is expected. I wish everyone >>> would have thought of that before we got caught up in the personal, >>> and not what is important, trunk debate. >>> >> >> I did, as well others did (I hope) >> >> I'll vote +1 for bringing trunk back any time when I see >> your TODO list. Sorry but without that Tomcat6 is not Tomact6 >> but rather your personal (and anyone else) playground. > bummer, I guess you never saw this > http://marc.info/?l=tomcat-dev&m=118646143216543&w=2 > even offered to maintain a WIKI page for this, so that anyone could add > their stuff to it. > however, as usual, this thread got pretty quickly shutdown, instead of > elaborating on what should go in, and expanding the list. I am not sure a WIKI is the best for a ROADMAP/TODO list. (except if it is possible to get an email when a page is modified). Better put it in the svn. Where? Well in /tomcat/sandbox/next/TODO or tomcat/sandbox/next/ROADMAP or 6xFeatures.txt (replace next by something better like atlanta for example see: /httpd/sandbox/amsterdam/). Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Review model take 2
+1 Cheers Jean-Frederic Remy Maucherat wrote: > Hi, > > Another more precise draft. > > Patches which would go to review would be: > - API changing patches (any protected or above signature change) on APIs > which are accessible to the user either from confirguration or > programmatically > - any other commit for which a committer asks for the RTC procedure > should be rollbacked if it hinders concurrent work or is to be included > in a release tag, and go through the RTC procedure > > The RTC procedure would include a STATUS file in the Tomcat svn listing > all pending "up to review" changes. A successful vote with a +3 margin > is required. A patch can remain under review for as long as the > committer wishes, and it should be allowed to freely "advertise" and > discuss the vote. > > The idea would be to force a consensus for commits which could have > significant implications, and help stage technical discussions (rather > than discussions about the validity of the disagreement). It would > introduce a small delay for committing certain patches and a minor > slowdown for development pace in theory, but in practice I've noticed > conflicts waste a lot more time. > > This would also mean it is possible to make a change that a number of > committers oppose (possibly, would veto) if enough committers are in > favor of it. > > 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: Review model take 2
Filip Hanik - Dev Lists wrote: > Remy Maucherat wrote: >> Hi, >> >> Another more precise draft. >> >> Patches which would go to review would be: >> - API changing patches (any protected or above signature change) on >> APIs which are accessible to the user either from confirguration or >> programmatically > yes, makes sense >> - any other commit for which a committer asks for the RTC procedure >> should be rollbacked if it hinders concurrent work or is to be >> included in a release tag, and go through the RTC procedure > -1. There is a huge risk for "I simply don't like it, revert it". > Anything that is to be rolled back, should be backed up by a technical > reason. So in this case, how do you define "it hinders concurrent work". > Either we do RTC or we don't, but having a vague definition in between, > doesn't make sense. That is not: "I simply don't like it, revert it" that is "I think it needs review, revert it and let's discuss it". I would proposed that the one that does the -1 should come with another fix in few days for a fix for a PR, another proposal for API/conf changes and participate to the discussion on the -1 otherwise the -1 would become is invalid. >> >> The RTC procedure would include a STATUS file in the Tomcat svn >> listing all pending "up to review" changes. A successful vote with a >> +3 margin is required. A patch can remain under review for as long as >> the committer wishes, and it should be allowed to freely "advertise" >> and discuss the vote. >> >> The idea would be to force a consensus for commits which could have >> significant implications, and help stage technical discussions (rather >> than discussions about the validity of the disagreement). It would >> introduce a small delay for committing certain patches and a minor >> slowdown for development pace in theory, but in practice I've noticed >> conflicts waste a lot more time. > The community has always been open to technical discussions, it's the > countless vetoes without technical justifications that became the major > pain in the rear. The problem is more the time that is spend to discuss the validity of -1 is lost time for me. It seems a reaction to a veto of a commit in the TC community is somehow wrong... The correct way should be "thank you for reviewing my commit, I will rollback and let's discuss a better solution" and not what happens those days. >> >> This would also mean it is possible to make a change that a number of >> committers oppose (possibly, would veto) if enough committers are in >> favor of it. > I don't really see the need of doing our own version of a semi RTC, > either we do RTC on release branches and CTR on trunk. > So I'd be -1 on this, the main reason, is that the definitions are not > common nor defined within the larger ASF community, hence the vagueness > would only arise for more debates. What Remy proposed is a RTC on demand I think we should try it and improve it while using it. Cheers Jean-Frederic > > Filip >> >> 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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Review model take 2
Remy Maucherat wrote: > jean-frederic clere wrote: >> Filip Hanik - Dev Lists wrote: >>> Remy Maucherat wrote: >>>> Hi, >>>> >>>> Another more precise draft. >>>> >>>> Patches which would go to review would be: >>>> - API changing patches (any protected or above signature change) on >>>> APIs which are accessible to the user either from confirguration or >>>> programmatically >>> yes, makes sense >>>> - any other commit for which a committer asks for the RTC procedure >>>> should be rollbacked if it hinders concurrent work or is to be >>>> included in a release tag, and go through the RTC procedure >>> -1. There is a huge risk for "I simply don't like it, revert it". >>> Anything that is to be rolled back, should be backed up by a technical >>> reason. So in this case, how do you define "it hinders concurrent work". >>> Either we do RTC or we don't, but having a vague definition in between, >>> doesn't make sense. >> >> That is not: "I simply don't like it, revert it" that is "I think it >> needs review, revert it and let's discuss it". >> I would proposed that the one that does the -1 should come with another >> fix in few days for a fix for a PR, another proposal for API/conf >> changes and participate to the discussion on the -1 otherwise the -1 >> would become is invalid. > > The patch does not need to be reverted when under review, except if > there's a need to tag a release or something similar. Well I see at least 3 reasons to revert it: - Prevent accidental inclusion in a release. - Allow a more easy testing and evaluation of a another patch that fixes the same thing. - Force the community to look for another solution. Cheers Jean-Frederic > In that case, > including such a patch would not be acceptable. The other case is if it > causes development issues, but it should be extremely rare (as API > changing patches would get reviewed before being committed). > > I also don't think any reason needs to be given for voting against a > particular patch under review. If only one committer votes "no", then > you need one additional "yes" (4 total), which sounds achievable. If two > committers vote "no" (most likely you would be in a veto situation at > the moment) then it's still doable if everybody else wants it. With 3 > against, the community is basically split, and it seems impossible to > follow through without changes to convince the other camp. > > The general idea is to be able to disagree with something without using > something absolute like the veto mechanism, since the only thing that is > going to be examined (at least at the moment) seems to be its validity. > Also, if a vote is tied to a justification, then any discussions will > immediately switch over from technical to "let's show the justification > is not valid, so that we can ignore it" mode. > > If it turns this new mechanism does not work, then I think new proposals > can be made to change it quite easily. > > 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: Review model take 2
Remy Maucherat wrote: > jean-frederic clere wrote: >> Well I see at least 3 reasons to revert it: >> - Prevent accidental inclusion in a release. >> - Allow a more easy testing and evaluation of a another patch that fixes >> the same thing. >> - Force the community to look for another solution. > > As much as possible, I would like to avoid reverting a patch until the > review is concluded (or there is passing review on a patch which > supersedes it), as it wastes time and is annoying to do. Ok. Reverting it doesn't force the ones that disagree to react quicky once reverted. Now for me that just makes another chapter in the "STATUS" file: "PATCHES being discussed". After a week those patches should be accepted or reverted. Reverted patches and corresponding discussions should stay in the "STATUS" until a solution is found. I would keep a passing margin of +3. Cheers Jean-Frederic > The main other > issues are to determine: > - how long a review should last (most likely, the usual one week would do) > - the passing margin (+3 could be +2, for example) > > 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: Review model take 2
William A. Rowe, Jr. wrote: > Remy Maucherat wrote: >> William A. Rowe, Jr. wrote: >>> jean-frederic clere wrote: >>>> Now for me that just makes another chapter in the "STATUS" file: >>>> "PATCHES being discussed". After a week those patches should be accepted >>>> or reverted. Reverted patches and corresponding discussions should stay >>>> in the "STATUS" until a solution is found. I would keep a passing margin >>>> of +3. >>> A higher bar to add a feature than to release the software? Plainly >>> absurd. >> Features additions are not mentioned in my proposal. We also use a +3 >> vote for releases. > > Maybe we are misusing words. A passing margin of +3 means three more +1's > than -1's; that means if you had 2 -1's you would seek 5 +1's to keep going > over the objection. That's what I referred to as absurd. I don't see why it is absurd when you have 2 -1 and 5 +1 but well 5 -1 and 8 +1 starts to show why you think it "absurd". So I think that " at least 3 +1's and more + than -" is acceptable for me. May be one additional duty for committers could be to cast vote on proposals when the PMC Chair requests it to reach enough votes so that a majority express their view. > > If you are talking about at least 3 +1's, more + than -, then that's being > realistic. JFC - did you really mean a margin? Yep that was what I meant at that time. Cheers Jean-Frederic > > Bill > > > - > 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: Review model take 2
William A. Rowe, Jr. wrote: > jean-frederic clere wrote: >> William A. Rowe, Jr. wrote: >> >>> If you are talking about at least 3 +1's, more + than -, then that's being >>> realistic. JFC - did you really mean a margin? >> Yep that was what I meant at that time. > > I'm really sorry I misunderstood you Jean-Frederic, I came from some financial > coding where I learned margin/markup/profit aren't the same formula after all > :) No problems ;-) We must find a way to solve conflicts and have rules for that. The rules must as prefect as possible so that there isn't any misunderstanding and acceptable for the community. Cheers Jean-Frederic > > Bill > > - > 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: Review model take 2
Filip Hanik - Dev Lists wrote: > Bill Barker wrote: >> "Filip Hanik - Dev Lists" <[EMAIL PROTECTED]> wrote in message >> news:[EMAIL PROTECTED] >> >>> jean-frederic clere wrote: >>> >>>> Remy Maucherat wrote: >>>> >>>> >>>>> jean-frederic clere wrote: >>>>> >>>>> >>>>>> Filip Hanik - Dev Lists wrote: >>>>>> >>>>>> >>>>>>> Remy Maucherat wrote: >>>>>>> >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Another more precise draft. >>>>>>>> >>>>>>>> Patches which would go to review would be: >>>>>>>> - API changing patches (any protected or above signature change) on >>>>>>>> APIs which are accessible to the user either from confirguration or >>>>>>>> programmatically >>>>>>>> >>>>>>>> >>>>>>> yes, makes sense >>>>>>> >>>>>>> >>>>>>>> - any other commit for which a committer asks for the RTC procedure >>>>>>>> should be rollbacked if it hinders concurrent work or is to be >>>>>>>> included in a release tag, and go through the RTC procedure >>>>>>>> >>>>>>>> >>>>>>> -1. There is a huge risk for "I simply don't like it, revert it". >>>>>>> Anything that is to be rolled back, should be backed up by a >>>>>>> technical >>>>>>> reason. So in this case, how do you define "it hinders concurrent >>>>>>> work". >>>>>>> Either we do RTC or we don't, but having a vague definition in >>>>>>> between, >>>>>>> doesn't make sense. >>>>>>> >>>>>>> >>>>>> That is not: "I simply don't like it, revert it" that is "I think it >>>>>> needs review, revert it and let's discuss it". >>>>>> I would proposed that the one that does the -1 should come with >>>>>> another >>>>>> fix in few days for a fix for a PR, another proposal for API/conf >>>>>> changes and participate to the discussion on the -1 otherwise the -1 >>>>>> would become is invalid. >>>>>> >>>>>> >>>>> The patch does not need to be reverted when under review, except if >>>>> there's a need to tag a release or something similar. >>>>> >>>>> >>>> Well I see at least 3 reasons to revert it: >>>> - Prevent accidental inclusion in a release. >>>> - Allow a more easy testing and evaluation of a another patch that >>>> fixes >>>> the same thing. >>>> - Force the community to look for another solution. >>>> >>>> >>> so to me this is spanking clear, that the process is vague, and >>> before anything like this is implemented, it should be as black and >>> white as RTC and CTR if it's gonna work >>> at this point, the vote doesn't make sense, as it is obvious folks >>> aren't clear on the process being voted on. >>> >>> >> >> And, yet again, Filip chooses to question the validity of the vote, >> instead of discussing ideas :(. Now I feel insulted as well, since >> I'm fully aware on the process being voted on. But if I lived with >> Jon in the same community, I can live with Filip ;-). >> > how can we vote, if the thread goes into discussion. The ASF clearly has > to methods of developing, CTR or RTC, > So there are two questions here > 1. Why do we need something in between > 2. This is the third time around this topic has been discussed, and > folks are still unclear on the process or the desire thereof, you might > be clear, but me, and others based on the thread for sure aren't. The > new model is not black and white, but it would have to be in order to work. If we are discussing how we should develop it is because CTR shows it limits... It doesn't define clearly how to handle a -1 on a commit and that is why the discussion turns into the validity of the -1 instead discussing the code. Cheers Jean-Frederic +++ CUT +++ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Review model take 2
Filip Hanik - Dev Lists wrote: > Costin Manolache wrote: >> On 9/20/07, Jim Jagielski <[EMAIL PROTECTED]> wrote: >> >>> On Sep 19, 2007, at 10:55 PM, Bill Barker wrote: >>> >>> TC 4.1.x and TC 5.5.x represented major changes to the core API, and resulted in much more stable Tomcat code. There is no such issue for TC 6.0.x (just a disagreement on the comet API, which we have already dealt with, and decided to let software-darwinism take it's course). >>> When I suggested a TC 6.0 and 6.5 dual approach, Costin said: >>> >>>"Strong -1 on this. Done that - didn't work so good, and it >>> doesn't solve >>>the core problem - it's not about 'cutting edge' versus 'stable',..." >>> >> >> >> >> Context needed :-) >> >> -1 was on having a TC6.5 as a way to resolve conflicts ( so some >> people can >> make broad >> changes in one and some in other without having to >> 'discuss'/argue/veto ). >> >> The transition between 5.5 to 6.0 ( AFAIK ) was based on '5.5 is mostly >> frozen, only important >> and select changes backported, all new activity on 6.0'. >> >> I also don't think a 6.5 is needed unless there is no huge >> architecture and >> API change, as it happened in 5.5->6.0, >> > well, we have the annotation changes needed for geronimo, that were not > allowed in 6.0 > personally, I think that was enough to keep trunk alive. > Let's say that I did have a huge architecture change, lets say, I want > to swap out ByteChunk/CharChunk for ByteBuffer/CharBuffer and also use > nio charset conversion, > then doing that in trunk is not so appropriate either. So I will do that > in sandbox, the right place for an experiment like that. Maybe it turns > out that it worked perfectly, and we want to put that into Tomcat, we > can't put it in 6.0, that would be insane, and we don't have a trunk, so > where do we put it? > > Removing trunk, pretty much halted any chances for future innovation, as > approved sandbox experiments have nowhere to go. To my point of view the goal is/was not to remove trunk for ever. The goal is/was to have a trunk where we all (or mostly all) agree on what we want in it. It needs a road map for the future and may be rules how to turn innovation in a stable product. It also needs more than 2 participants to prevent endless and useless disagreements. Cheers Jean-Frederic > >> but my 'strong -1' was for the reasons above. I don't mind having a >> 6.5 - >> if both Remy and Filip and all other >> people who are actively developing move to 6.5 so changes get the right >> review ( instead of 'that's my branch, that's yours' ) >> > the "my" vs "your" should have never happened, and when those terms were > coined, they should have been shutdown that very minute. > I never believed in those terms for sure. > > Filip > > > - > 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: Review model take 2
Henri Gomez wrote: > So what about RTC for core and CTR for extensions in incubator land ? Well see the result of the "[VOTE] Make released versions RTC". We need 2 things innovation (on a common trunk) and stability on released branches. That why I made the proposal "[VOTE] Make released versions RTC". CTR didn't seem to work on the "old" trunk and we have to prevent this happening again, therefore comes the idea of a "RTC on demand". Cheers Jean-Frederic > > 2007/9/21, Costin Manolache <[EMAIL PROTECTED]>: >> I have a strong feeling this is turning again into a debate over words, >> arcane details >> and abstract concepts ( 'what is a trunk' and how to increase innovation ) >> >> The real issue is quite simple, and not having a trunk or all the new >> process seems >> more like an attempt to solve it: >> >> We want tomcat evolution to be done by consensus or at least majority, not >> by one >> individual ( be it Remy or Filip or anyone else ) making decisions and >> changes to the core API without >> consultation and agreement from others ( and yes, most vetoes are probably >> invalid and >> bad - the changes are technically ok, and the veto is a blunt tool to >> express lack of consensus >> and frustration ). >> >> The whole veto / remove trunk / personal hurt feelings / CTR / RTC / process >> debate >> is just a way to avoid this from happening. >> >> Yes, we want innovation and change and contributions and all that - but that >> doesn't mean >> that anyone who can make a technically valid change ( i.e. where a veto >> would be invalid ) >> should make it - if it affects other people and it lacks consensus. >> >> That doesn't mean you can't add features ( to 6.0 or trunk or however you >> want to call it ), or you >> can't make big changes, or someone can block 'progress' or impose his own >> vision of progress. >> All those proposals evolve around how to involve more people in decision >> making and be as close >> to consensus as possible. >> >> I personally consider tomcat way overbloated - so I think I'm on the same >> side with Remy on voting against >> adding any new feature that could be done as a plugin, and I would be happy >> to see 'innovations' >> in tomcat removed from std and moved to separate plugins, until we're at the >> same size with jetty >> or other containers in the base distro. But I do understand Filip's >> frustration and the desire to try now >> things - and this should happen, not in sandbox but in 6.0 tree, except not >> in the core and with >> controlled API changes. >> >> >> Costin >> >> On 9/20/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: >>> Will f/w board since this follows from the 'no more trunk' comment which >>> some officers questioned. Please don't cc per-say, but feel free to f/w >>> a relevant response to [EMAIL PROTECTED] (it's bad form to crosspost a >>> message >>> with both public-and-private destinations). >>> >>> Bill Barker wrote: "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote in message > All that said, the topic of "no more trunk" came up at the board >>> meeting > today. I gave a very brief background and suggested that some of the > renewed interest by folks who had been silent throughout the Filip-Remy > trunk war is a hopeful sign; with renewed interest the project is very > likely to be able to manage itself successfully through these personal > and stylistic disagreements; the board is satisfied to see the project > try to work out these issues themselves as long as development once >>> again > is encouraged. TC 4.1.x and TC 5.5.x represented major changes to the core API, and resulted in much more stable Tomcat code. There is no such issue for TC 6.0.x (just a disagreement on the comet API, which we have already dealt with, and decided to let software-darwinism take it's course). Thus, >>> there is really no reason for a "trunk" at this time, at least until the >>> Servlet 3.0 spec comes out. If somebody wanted to make a [PROPOSAL] for major changes to the core TC 6.0.x API, then I can see setting up a "trunk" >>> again. But there is no such animal lurking at this time. >>> No doubt, these were significant departures from their previous code. >>> >>> But, are you suggesting that there is no need for trunk until there is an >>> idea you happen to champion? Present you with an idea that you like and >>> half the committee might decide to permit new development again? >>> >>> This is certainly turning the idea of "show me the code" on it's head. >>> >>> To give an example oft cited on this list, httpd maintains a trunk. It >>> might be released some day as-is, it might never be released. But it's >>> a staging ground to prove up an idea before injecting that idea into the >>> shipping stable version. It appears there is no such wilderness at >>> Tomcat. >>> >>> Sandboxes don't cut it. It's very clear sandboxes are one-man-shows at >>> Tomcat. As s
Re: Review model take 2
Filip Hanik - Dev Lists wrote: > It could be a simple as (as opposed to trying to reinvent the apache way) > > 1. Through out a vote for the 6.0.x/5.5.x/5.0.x/4.1.x branches RTC or CTR Every one should why Sun had forked from Tomcat... I am sure a RTC on stable branches would have prevent it. None needs a toy for production. Why do you think Apache httpd is still the best open source WEB server (see http://www.infoworld.com/slideshow/2007/09/114-best_of_open_so-5.html)? - Because stable branches are really stable why are they so stable because they use RTC. > 2. We'll all pay more attention to discussing a change prior to SVN > commit whether it is RTC or CTR > But we don't need a "new process" for this That is not a new process what we need is to define what to do if the consensus doesn't come out when the review ended in "please stop we need to discuss that commit/feature/fix". > 3. Bring back trunk as CTR, again, following the advice in step 2 (yes, > me included) yes we need a place for common innovation. > > And have it all over with. The reason I'm opposing here is that the > tomcat community is trying to (re)invent a new development process. > Trust me, if there was a better way, someone else would have probably > thought of it, it's not like we are the originators and demi gods of > programming. > The reason we are at the ASF, is to piggy back on the ASF ways, as > simple as that. Again something worked wrong you can say it is your fault (and tell it to everyone (including Remy)) but nothing prevents that happening again. Should we define a process to prevent that? For me yes. Cheers Jean-frederic > > Filip > > > > jkew wrote: >> Folks, >> >> I'm somewhat on the outside looking here, so I'm probably going to be >> a little naive: >> >> 1. It's really time to come to a conclusion on this, before people get >> too exhausted and give up. >> 2. Ideally everyone should compromise a little on a solution, but this >> doesn't always happen. >> 3. People really hate making decisions that are going to be set in >> stone, especially when they are emotionally involved. >> >> What about a trial period of three(or 'n') months for a review model? >> People who hate the review model may be more willing to compromise a >> bit more for a 'test' phase. The review model does not have to be set >> in stone, but we do need something in place until people can calm down. >> >> 1. Those who compromise more than others should be willing to give the >> new system an n month trial period to allow a new process a chance to >> settle w/o constant criticism. >> 2. Those who compromised less should be willing to change the system >> after the n month trial period. >> >> Whether it is Remy's plan or another, it is really important to codify >> some process at this point. I would rather not waste any more bits on >> this. I hate the idea of proposing anything at all in the middle of >> this discussion, but we have got to get past this. >> >> -John >> >> Remy Maucherat wrote: >>> Hi, >>> >>> Another more precise draft. >>> >>> Patches which would go to review would be: >>> - API changing patches (any protected or above signature change) on >>> APIs which are accessible to the user either from confirguration or >>> programmatically >>> - any other commit for which a committer asks for the RTC procedure >>> should be rollbacked if it hinders concurrent work or is to be >>> included in a release tag, and go through the RTC procedure >>> >>> The RTC procedure would include a STATUS file in the Tomcat svn >>> listing all pending "up to review" changes. A successful vote with a >>> +3 margin is required. A patch can remain under review for as long as >>> the committer wishes, and it should be allowed to freely "advertise" >>> and discuss the vote. >>> >>> The idea would be to force a consensus for commits which could have >>> significant implications, and help stage technical discussions >>> (rather than discussions about the validity of the disagreement). It >>> would introduce a small delay for committing certain patches and a >>> minor slowdown for development pace in theory, but in practice I've >>> noticed conflicts waste a lot more time. >>> >>> This would also mean it is possible to make a change that a number of >>> committers oppose (possibly, would veto) if enough committers are in >>> favor of it. >>> >>> 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] >> >> >> > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > ---
Re: Wiki diffs
Mark Thomas wrote: > All, > > I think the wiki is probably the best place to start drafting a new set > of commit guidelines to cover what branches we have (and what state they > are in), what is RTC, what is CTR, etc. Great. In the next steps we should create a ROADMAP the same way to define what we are going to put in trunk ;-) Cheers Jean-Frederic > > However, I didn't want to propose we use the wiki whilst we weren't > getting wiki diffs on the dev list. I have just fixed this so, my > suggestion is to use the wiki for this. > > Once we have the agreed guidelines, we can add them to the Tomcat web > pages, probably linked from get involved. > > Mark > > PS I would volunteer to write the first draft but I am meant to be on > holiday and if I spend any more time on my laptop tonight, I am going to > be in trouble ;) > > - > 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: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
+1 Cheers Jean-Frederic > >[ ] +1. Yes, the above works and addresses my concerns >as well as the problems which started this whole >thing. >[ ] 0. Whatever. >[ ] -1. The above does not work for the following reasons: > > The vote will run for 96 hours instead of the normal 72 because of > the weekend. Only binding votes will be counted, but non-binding > votes will be used to address wider concern/acceptance of > the proposal. > > > - > 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: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
Mark Thomas wrote: > Jim Jagielski wrote: >>[X] +1. Yes, the above works and addresses my concerns >>as well as the problems which started this whole >>thing. >>[ ] 0. Whatever. >>[ ] -1. The above does not work for the following reasons: >> > > With the following caveats: > > - There is only one dev branch. I am -1 for creating separate dev > branches for 3.3.x, 4.1.x, 5.0.x and 5.5.x on the grounds it is too much > overhead for branches that are in maintenance mode where 99% of the > patches will be ported from 6.x Apache httpd works that way. In case a patch can't fit in mail use people.apache.org to store the patch to review. Note that tomcat/tc6.0.x/ is a released branche and it should be RTC too. Cheers Jean-Frederic > > - Where a patch for 3, 4 or 5 is required that just doesn't make sense > in the dev branch then the patch is applied using RTC. > > - We review this process in 3 months time to see if it is providing the > expected benefits without excessive overheads. > > - We improve the "Which version?" web page to make clear which branches > are supported and at what level. I'll start a wiki page as a draft of this. > > - The "Get involved" pages are updated to document this process > > - > 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: [Tomcat Wiki] Update of "TomcatVersions" by markt
> @@ -55, +77 @@ > > ||Spec versions:||Servlet 2.5, JSP 2.1|| > ||Stable:||Yes|| > ||Enhancements:||TBD - currently Yes|| > - ||Bug Fixes:||Yes|| > + ||Bug Fixes:||TBD - currently Yes|| > - ||Security Fixes:||Yes|| > + ||Security Fixes:||TBD - currently Yes|| > + ||Process:||RTC|| > ||Listed on download pages||Yes|| > ||Release Manager:||Remy Maucherat (remm)|| > > + = Tomcat 6.2.x = > + ||Spec versions:||Servlet 2.5, JSP 2.1|| > + ||Stable:||Yes|| > + ||Enhancements:||Yes|| > + ||Bug Fixes:||Yes|| > + ||Security Fixes:||Yes|| > + ||Process:||RTC|| > + ||Listed on download pages||Yes|| > + ||Release Manager:||TBD|| > + Features: > + * 6.0.x plus > + * Geronimo API changes > + * TBD > + > + = Tomcat 6.3.x = > + ||Spec versions:||Servlet 2.5, JSP 2.1|| > + ||Stable:||No|| > + ||Enhancements:||Yes|| > + ||Bug Fixes:||Yes|| > + ||Security Fixes:||Yes|| > + ||Process:||CTR|| > + ||Listed on download pages||Yes|| > + ||Release Manager:||TBD|| > + Features: > + * 6.2.x plus > + * TBD > + Having a 6.2.x and a 6.3.x doesn't fit with the httpd way. I think that we should have a trunk based on the actual 6.0.x and discuss what we want to include in it. Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r579298 - /tomcat/tc6.0.x/trunk/STATUS
Filip Hanik - Dev Lists wrote:
> my suggestion, open a BZ item, attach the patch there, and have the
> STATUS file refer to that item
Or put it under people.apache.prg/~your_name/patches/bla.patch.
Cheers
Jean-Frederic
>
> Filip
>
> Filip Hanik - Dev Lists wrote:
>> are we really gonna put each patch (the contents of it) in the STATUS
>> file,
>> this will make the status file unusable pretty quick, wont it?
>>
>> Filip
>>
>> [EMAIL PROTECTED] wrote:
>>> Author: remm
>>> Date: Tue Sep 25 08:22:40 2007
>>> New Revision: 579298
>>>
>>> URL: http://svn.apache.org/viewvc?rev=579298&view=rev
>>> Log:
>>> - Patch update.
>>>
>>> Modified:
>>> tomcat/tc6.0.x/trunk/STATUS
>>>
>>> Modified: tomcat/tc6.0.x/trunk/STATUS
>>> URL:
>>> http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS?rev=579298&r1=579297&r2=579298&view=diff
>>>
>>> ==
>>>
>>> --- tomcat/tc6.0.x/trunk/STATUS (original)
>>> +++ tomcat/tc6.0.x/trunk/STATUS Tue Sep 25 08:22:40 2007
>>> @@ -15,7 +15,7 @@
>>>limitations under the License.
>>>
>>>
>>>
>>>
>>> -$Id: BUILDING.txt 562769 2007-08-04 22:08:32Z markt $
>>> +$Revision: $ $Date: $
>>>
>>> =
>>> Apache Tomcat 6.0 Patch Proposals
>>> @@ -26,7 +26,551 @@
>>>[ New proposals should be added at the end of the list ]
>>>
>>> * New cookie parser (third party contribution)
>>> - http://people.apache.org/~jfclere/patches/Cookies.java.patch
>>>+1:-1: jfclere: The tests must done another way.
>>> +
>>> +Index: java/org/apache/tomcat/util/http/Cookies.java
>>> +===
>>> +--- java/org/apache/tomcat/util/http/Cookies.java(revision 579106)
>>> java/org/apache/tomcat/util/http/Cookies.java(working copy)
>>> +@@ -45,7 +45,28 @@
>>> + boolean unprocessed=true;
>>> + + MimeHeaders headers;
>>> +-++
>>> ++/*
>>> ++List of Separator Characters (see isSeparator())
>>> ++Excluding the '/' char violates the RFC, but ++it looks
>>> like a lot of people put '/'
>>> ++in unquoted values: '/': ; //47 ++'\t':9 ' ':32 '\"':34
>>> '\'':39 '(':40 ')':41 ',':44 ':':58 ';':59 '<':60 ++'=':61 '>':62
>>> '?':63 '@':64 '[':91 '\\':92 ']':93 '{':123 '}':125
>>> ++*/
>>> ++public static final char SEPARATORS[] = { '\t', ' ', '\"',
>>> '\'', '(', ')', ',', ++':', ';', '<', '=', '>', '?', '@',
>>> '[', '\\', ']', '{', '}' };
>>> ++
>>> ++protected static final boolean separators[] = new boolean[128];
>>> ++static {
>>> ++for (int i = 0; i < 128; i++) {
>>> ++separators[i] = false;
>>> ++}
>>> ++for (int i = 0; i < SEPARATORS.length; i++) {
>>> ++separators[SEPARATORS[i]] = true;
>>> ++}
>>> ++}
>>> ++
>>> + /**
>>> + * Construct a new cookie collection, that will extract
>>> + * the information from headers.
>>> +@@ -182,181 +203,6 @@
>>> + }
>>> + }
>>> + +-/** Process a byte[] header - allowing fast processing of the
>>> +- * raw data
>>> +- */
>>> +-void processCookieHeader( byte bytes[], int off, int len )
>>> +-{
>>> +-if( len<=0 || bytes==null ) return;
>>> +-int end=off+len;
>>> +-int pos=off;
>>> +-+-int version=0; //sticky
>>> +-ServerCookie sc=null;
>>> +-+-
>>> +-while( pos>> +-byte cc;
>>> +-// [ skip_spaces name skip_spaces "=" skip_spaces value
>>> EXTRA ; ] *
>>> +-if( dbg>0 ) log( "Start: " + pos + " " + end );
>>> +-+-pos=skipSpaces(bytes, pos, end);
>>> +-if( pos>=end )
>>> +-return; // only spaces
>>> +-int startName=pos;
>>> +-if( dbg>0 ) log( "SN: " + pos );
>>> +-+-// Version should be the first token
>>> +-boolean isSpecial=false;
>>> +-if(bytes[pos]=='$') { pos++; isSpecial=true; }
>>> +-
>>> +-pos= findDelim1( bytes, startName, end); // " =;,"
>>> +-int endName=pos;
>>> +-// current = "=" or " " or DELIM
>>> +-pos= skipSpaces( bytes, endName, end ); +-
>>> if( dbg>0 ) log( "DELIM: " + endName + " " + (char)bytes[pos]);
>>> +-
>>> +-if(pos >= end ) {
>>> +-// it's a name-only cookie ( valid in RFC2109 )
>>> +-if( ! isSpecial ) {
>>> +-sc=addCookie();
>>> +-sc.getName().setBytes( bytes, startName,
>>> +- endName-startName );
>>> +-sc.getValue().setString("");
>>> +-sc.setVersion( version );
>>> +-if( dbg>0 ) log( "Name only, end: " + s
Re: Time to organise svn
Mark Thomas wrote: > William A. Rowe, Jr. wrote: >> Actually, the way it typically works at httpd-space (which your new >> policy is based on) is that you would next create 6.1.0 as a forever >> development branch. Committers apply each patch they believe belongs >> to the 6.2.0 release, and things are removed and readded as various >> votes and discussions proceed. > > OK. I think I have it now. Does the the following make more sense? > > svn cp https://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk > https://svn.apache.org/repos/asf/tomcat/tc6.1.x/trunk No. > > svn cp https://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk > https://svn.apache.org/repos/asf/tomcat/trunk > Yes that more similar to httpd so that probably a better solution. > and then > - Make all changes in trunk (CTR) We should have a roadmap of what we want to do before starting. > - Port those API changes we want in 6.2.x from trunk to 6.1.x (RTC) > - A beta release of 6.1.x tagging trunk. > - Once we are happy with 6.1.x, freeze it, create 6.2.x and do a > stable release 6.2.x will then be like the actual https://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk > - Continue to port non-API modifying changes from trunk to 6.2.x as RTC > - At some point in the future, trunk is branched to form 6.3.x which > is used as the basis for 6.4.x or 7.0.x We could have beta 6.3.x tags of trunk at that time. Cheers Jean-Frederic > > Mark > > > - > 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: Time to organise svn
William A. Rowe, Jr. wrote: > Mark Thomas wrote: >> William A. Rowe, Jr. wrote: >>> Actually, the way it typically works at httpd-space (which your new >>> policy is based on) is that you would next create 6.1.0 as a forever >>> development branch. Committers apply each patch they believe belongs >>> to the 6.2.0 release, and things are removed and readded as various >>> votes and discussions proceed. >> OK. I think I have it now. Does the the following make more sense? >> >> svn cp https://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk >> https://svn.apache.org/repos/asf/tomcat/tc6.1.x/trunk >> >> svn cp https://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk >> https://svn.apache.org/repos/asf/tomcat/trunk >> >> and then >> - Make all changes in trunk (CTR) >> - Port those API changes we want in 6.2.x from trunk to 6.1.x (RTC) >> - A beta release of 6.1.x >> - Once we are happy with 6.1.x, freeze it, create 6.2.x and do a >> stable release >> - Continue to port non-API modifying changes from trunk to 6.2.x as RTC >> - At some point in the future, trunk is branched to form 6.3.x which >> is used as the basis for 6.4.x or 7.0.x > > Yup, my only kibitz would be that you /might/ want to consider deferring > the creation of trunk for a week to copy it from 6.1.x. in order to let > people catch up with the backlog of patches, without having to apply them > in /both/ places at once :) The best is to start from a tagged version of tc-6.0.x. Cheers Jean-Frederic > > Bill > > - > 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: Time to organise svn
Remy Maucherat wrote: > Mark Thomas wrote: >> Next attempt. >> >> Taking account of the comments so far, a slightly modified proposal is >> below. >> >> svn cp https://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk >> https://svn.apache.org/repos/asf/tomcat/trunk >> >> svn cp https://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_14 >> https://svn.apache.org/repos/asf/tomcat/tc6.1.0/trunk > > Instead, I would propose to tag a new 6.0.15 candidate first. That is also what I proposed in my previous comment. Cheers Jean-Frederic > > 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: Time to organise svn
Filip Hanik - Dev Lists wrote: > Remy Maucherat wrote: >> jean-frederic clere wrote: >>> Remy Maucherat wrote: >>>> Mark Thomas wrote: >>>>> Next attempt. >>>>> >>>>> Taking account of the comments so far, a slightly modified proposal is >>>>> below. >>>>> >>>>> svn cp https://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk >>>>> https://svn.apache.org/repos/asf/tomcat/trunk >>>>> >>>>> svn cp >>>>> https://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_14 >>>>> https://svn.apache.org/repos/asf/tomcat/tc6.1.0/trunk >>>> Instead, I would propose to tag a new 6.0.15 candidate first. >>> >>> That is also what I proposed in my previous comment. >> >> Didn't see it, sorry. I propose tagging a 6.0.15 candidate on Monday. > Can we wait a bit, there are a few bug fixes that need to be caught up > on , and I also think we can improve upon the server.xml invalid > attribute implementation, the way I did the sandbox. I'll come up withe > patches for the bug What is the PR number? Cheers Jean-Frederic and the fixes for the invalid attribute thingy, and > put them in the status file > > Filip >> >> 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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Time to organise svn
Filip Hanik - Dev Lists wrote: > jean-frederic clere wrote: >> Filip Hanik - Dev Lists wrote: >> >>> Remy Maucherat wrote: >>> >>>> jean-frederic clere wrote: >>>> >>>>> Remy Maucherat wrote: >>>>> >>>>>> Mark Thomas wrote: >>>>>> >>>>>>> Next attempt. >>>>>>> >>>>>>> Taking account of the comments so far, a slightly modified >>>>>>> proposal is >>>>>>> below. >>>>>>> >>>>>>> svn cp https://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk >>>>>>> https://svn.apache.org/repos/asf/tomcat/trunk >>>>>>> >>>>>>> svn cp >>>>>>> https://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_14 >>>>>>> https://svn.apache.org/repos/asf/tomcat/tc6.1.0/trunk >>>>>>> >>>>>> Instead, I would propose to tag a new 6.0.15 candidate first. >>>>>> >>>>> That is also what I proposed in my previous comment. >>>>> >>>> Didn't see it, sorry. I propose tagging a 6.0.15 candidate on Monday. >>>> >>> Can we wait a bit, there are a few bug fixes that need to be caught up >>> on , and I also think we can improve upon the server.xml invalid >>> attribute implementation, the way I did the sandbox. I'll come up withe >>> patches for the bug >>> >> >> What is the PR number? >> > > > BZ 43478 > http://svn.apache.org/viewvc?rev=581384&view=rev +1 For this one. The stuff below I am -1 until more explanations. BTW: The comment of 581431 is "weird" no? What PR does it fix? Cheers Jean-Frederic > http://svn.apache.org/viewvc?rev=581422&view=rev > http://svn.apache.org/viewvc?rev=581431&view=rev > > Filip > >> Cheers >> >> Jean-Frederic >> >> and the fixes for the invalid attribute thingy, and >> >>> put them in the status file >>> >>> Filip >>> >>>> 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] >>> >>> >>> >> >> >> - >> 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]
Re: svn commit: r583858 - /tomcat/tc6.0.x/trunk/STATUS
Filip Hanik - Dev Lists wrote:
> to be clear, let me address your statements
>
> remm -1: removes support for the production APR connectors
> Absolutely not, doesn't change the way connectors are evaluated.
>
> remm -1: no real benefit of the patch
> The NIO connector attributes are now supported, the implementation is
> simpler and more flexible, and can be expanded to other components not
> supported today
I think I will -1:
There is the following in
java/org/apache/tomcat/util/IntrospectionUtils.java
+++
if (setPropertyMethod != null) {
Object params[] = new Object[2];
params[0] = name;
params[1] = value;
setPropertyMethod.invoke(o, params);
return true;
}
+++
Can't we try to check the Object returned by setPropertyMethod.invoke
and set the return code according to the value of the Object?
Cheers
Jean-Frederic
> furthermore, there are no exception cases anymore, like the
> o.a.c.connector.Connector object, is treated same way as before
>
> Filip
>
> Filip Hanik - Dev Lists wrote:
>> the patch doesn't change the behavior for the APR connector, can you
>> please explain what you mean?
>> apply the patch, try it out on your APR connector, and it should work
>> just like before
>> Filip
>>
>> [EMAIL PROTECTED] wrote:
>>> Author: remm
>>> Date: Thu Oct 11 08:44:34 2007
>>> New Revision: 583858
>>>
>>> URL: http://svn.apache.org/viewvc?rev=583858&view=rev
>>> Log:
>>> - Vote.
>>>
>>> Modified:
>>> tomcat/tc6.0.x/trunk/STATUS
>>>
>>> Modified: tomcat/tc6.0.x/trunk/STATUS
>>> URL:
>>> http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS?rev=583858&r1=583857&r2=583858&view=diff
>>>
>>> ==
>>>
>>> --- tomcat/tc6.0.x/trunk/STATUS (original)
>>> +++ tomcat/tc6.0.x/trunk/STATUS Thu Oct 11 08:44:34 2007
>>> @@ -50,4 +50,4 @@
>>> * to accept or reject the property
>>>
>>> http://people.apache.org/~fhanik/patches/digester-attribute-warnings.patch
>>>
>>>+1: fhanik
>>> - -1: + -1: remm (removes support for the production APR
>>> connectors, no real benefit of the patch)
>>>
>>>
>>>
>>> -
>>> 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]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r583858 - /tomcat/tc6.0.x/trunk/STATUS
Filip Hanik - Dev Lists wrote:
> jean-frederic clere wrote:
>> Filip Hanik - Dev Lists wrote:
>>
>>> to be clear, let me address your statements
>>>
>>> remm -1: removes support for the production APR connectors
>>> Absolutely not, doesn't change the way connectors are evaluated.
>>>
>>> remm -1: no real benefit of the patch
>>> The NIO connector attributes are now supported, the implementation is
>>> simpler and more flexible, and can be expanded to other components not
>>> supported today
>>>
>>
>> I think I will -1:
>> There is the following in
>> java/org/apache/tomcat/util/IntrospectionUtils.java
>> +++
>> if (setPropertyMethod != null) {
>> Object params[] = new Object[2];
>> params[0] = name;
>> params[1] = value;
>> setPropertyMethod.invoke(o, params);
>> return true;
>> }
>> +++
>> Can't we try to check the Object returned by setPropertyMethod.invoke
>> and set the return code according to the value of the Object?
>>
> actually, I want the boolean setProperty to have preferential treatment,
> ie, if it exists, then use it before the void.
Sure but what I am just telling is that we should try to return the
Boolean value in case a Boolean is returned.
>
> so what I mean, if you have the following in an object,
>
>public void setProperty(String name, String value) {
>public boolean setProperty(Object name, Object value) {
>
> then the method with a boolean return value should be called.
I don't think that we will ever have a code like the above and below
examples...
>
> however, you do bring up one point, if we have the following scenario
>
>public void setProperty(String name, String value) {
>public boolean setProperty(int name, int value) {
>
> the void method should be called, I have modified the patch to catch the
> IllegalArgumentException and try the other method if existing.
>
>> @@ -334,17 +335,37 @@
> 60c60,71
> < +return (Boolean) setPropertyMethodBool.invoke(o,
> params);
> ---
>> +try {
>> +return (Boolean)
> setPropertyMethodBool.invoke(o, params);
>> +}catch (IllegalArgumentException biae) {
>> +//the boolean method had the wrong
>> +//parameter types. lets try the other
>> +if (setPropertyMethodVoid!=null) {
>> +setPropertyMethodVoid.invoke(o, params);
>> +return true;
>> +}else {
>> +throw biae;
>> +}
>> +}
>
>
> your suggestion, would mean the method that actually gets called, would
> be at random, depending on what order the method array comes back in
> from the reflection API.
>
> the intro spector can of course be even more enhanced to check for
> argument types, but that is outside the scope of this patch.
Yes we both agree we need a better patch here, no?
Cheers
Jean-Frederic
>
> Filip
>> Cheers
>>
>> Jean-Frederic
>>
>>
>>
>>> furthermore, there are no exception cases anymore, like the
>>> o.a.c.connector.Connector object, is treated same way as before
>>>
>>> Filip
>>>
>>> Filip Hanik - Dev Lists wrote:
>>>
>>>> the patch doesn't change the behavior for the APR connector, can you
>>>> please explain what you mean?
>>>> apply the patch, try it out on your APR connector, and it should work
>>>> just like before
>>>> Filip
>>>>
>>>> [EMAIL PROTECTED] wrote:
>>>>
>>>>> Author: remm
>>>>> Date: Thu Oct 11 08:44:34 2007
>>>>> New Revision: 583858
>>>>>
>>>>> URL: http://svn.apache.org/viewvc?rev=583858&view=rev
>>>>> Log:
>>>>> - Vote.
>>>>>
>>>>> Modified:
>>>>> tomcat/tc6.0.x/trunk/STATUS
>>>>>
>>>>> Modified: tomcat/tc6.0.x/trunk/STATUS
>>>>> URL:
>>>>> http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS?rev=583858&r1=583857&r2=583858&view=diff
>>>>>
>>>>>
>>>>> ==
Re: svn commit: r585313 - /tomcat/tc6.0.x/trunk/STATUS
Rémy Maucherat wrote: > On Wed, 2007-10-17 at 07:28 -0400, Tim Funk wrote: >> There was a request in bugzilla to pass in a new env variable called >> JAVA_EXE (or similar). >> >> Could that be an acceptable alternative? Then it would make the bug >> submitter happy since he can symlink my_program_that_i_can_see_in_ps to >> java. > > That would be good too, with autodetection :) which java + dirname + testing files should do that easily I will make tries and propose a patch. Cheers Jean-Frederic > > 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: svn commit: r585313 - /tomcat/tc6.0.x/trunk/STATUS
Rainer Jung wrote: > jean-frederic clere wrote: >> Rémy Maucherat wrote: >>> On Wed, 2007-10-17 at 07:28 -0400, Tim Funk wrote: >>>> There was a request in bugzilla to pass in a new env variable called >>>> JAVA_EXE (or similar). >>>> >>>> Could that be an acceptable alternative? Then it would make the bug >>>> submitter happy since he can symlink my_program_that_i_can_see_in_ps >>>> to java. >>> That would be good too, with autodetection :) >> >> which java + dirname + testing files should do that easily I will make >> tries and propose a patch. > > In the unix world "env" is supposed to be more portable than "which" (5 > cents). There is often an utility name which: /usr/bin/which instead the buildin which. > > Explicitely set JAVA_*/JRE_* environment variables should have > preference over java binaries found in the PATH. For sure ;-) Cheers Jean-Frederic > > Regards, > > Rainer > > - > 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: [Fwd: [Security] - **Updated** Important vulnerability disclosed in Apache Tomcat webdav servlet]
jkew wrote: > Mark Thomas wrote: >> William L. Thomson Jr. wrote: >> >>> I take it down streams should run with the first patches to work around >>> this vulnerability till next release. I already applied the one liner, >>> kinda glad I did not apply the other last night ;) Please advise, >>> thanks. >>> >> >> You need a version of the second patch for a complete fix. If you want >> logging - apply my version, if you don't - apply Remy's. Both fix the >> problem, just in slightly different ways. >> >> > > I've been using Mark's patch, which I personally prefer right now. I'll > experiment with Remy's patch on Monday, but I have a slightly tangential > question: > > Q. Where should I put, and how should I build a unit test for the webdav > issue? I noticed that Jean-Frederic created a great unit test within > /test for the cookie issue, but I don't believe his patch was ever > committed. Is there a formal unit test framework for these issues? No yet but I think we should have tests for nearly everything. Cheers Jean-Frederic > > My existing test for the webdav issue is just a war file, but I'd like > something semi-permanent and manageable. I'm a little ignorant of of the > history here, so forgive me if I'm a little lost. >> We'll have to wait and see which way the voting goes for which patch >> gets incorporated into the code base. >> >> Mark >> >> - >> 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]
Re: svn commit: r588490 - /tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml
It would be nicer to commit in one single commit, the fix, the removal of the proposal in STATUS and the add in the changelog.xml Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Unit Test
jkew wrote: > I'm happy to see that you got the unit test checked in! Thanks again for your contribution. Cheers Jean-Frederic > > -John > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New tag
Rémy Maucherat wrote: > Hi, > > As the issue list seems relatively empty, I would like to tag 6.0.15 > soon, probably late tomorrow. +1 Cheers Jean-Frederic > > 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: svn commit: r588673 - in /tomcat/tc6.0.x/trunk: ./ test/ test/org/apache/catalina/tomcat/ test/org/apache/catalina/tomcat/util/ test/org/apache/catalina/tomcat/util/http/ webapps/docs/
Filip Hanik - Dev Lists wrote:
> isn't the .java file missing a "package
> org.apache.catalina.tomcat.util.http" declaration, also having both
> catalina and tomcat in the path, seems kind of redundant :)
Yep. I will change that after Remy's release.
Cheers
Jean-Frederic
>
> Filip
>
> [EMAIL PROTECTED] wrote:
>> Author: jfclere
>> Date: Fri Oct 26 07:51:23 2007
>> New Revision: 588673
>>
>> URL: http://svn.apache.org/viewvc?rev=588673&view=rev
>> Log:
>> Add the tests of the cookies.
>>
>> Added:
>> tomcat/tc6.0.x/trunk/test/build.xml
>> tomcat/tc6.0.x/trunk/test/org/apache/catalina/tomcat/
>> tomcat/tc6.0.x/trunk/test/org/apache/catalina/tomcat/util/
>> tomcat/tc6.0.x/trunk/test/org/apache/catalina/tomcat/util/http/
>>
>> tomcat/tc6.0.x/trunk/test/org/apache/catalina/tomcat/util/http/TestCookies.java
>>
>> Modified:
>> tomcat/tc6.0.x/trunk/STATUS
>> tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml
>>
>> Modified: tomcat/tc6.0.x/trunk/STATUS
>> URL:
>> http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS?rev=588673&r1=588672&r2=588673&view=diff
>>
>> ==
>>
>> --- tomcat/tc6.0.x/trunk/STATUS (original)
>> +++ tomcat/tc6.0.x/trunk/STATUS Fri Oct 26 07:51:23 2007
>> @@ -26,10 +26,6 @@
>>[ New proposals should be added at the end of the list ]
>>
>>
>> -* Tests for unit tests for the cookie issues.
>> http://people.apache.org/~jfclere/patches/CookiesTest.patch
>> - +1: fhanik, funkman, pero, jim
>> - -1:
>> -
>> * Guess java location from the PATH environment.
>> http://people.apache.org/~jfclere/patches/setclasspath.sh.patch
>>And improve fix for 37284.
>>+1: fhanik, remm, funkman, pero, jim
>>
>> Added: tomcat/tc6.0.x/trunk/test/build.xml
>> URL:
>> http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/test/build.xml?rev=588673&view=auto
>>
>> ==
>>
>> --- tomcat/tc6.0.x/trunk/test/build.xml (added)
>> +++ tomcat/tc6.0.x/trunk/test/build.xml Fri Oct 26 07:51:23 2007
>> @@ -0,0 +1,69 @@
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> + > + debug="${compile.debug}"
>> + deprecation="${compile.deprecation}"
>> + source="${compile.source}"
>> + optimize="${compile.optimize}">
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> + > fork="yes" failonerror="${test.failonerror}">
>> +
>> +
>> +
>> +
>> +
>> +
>>
>> Added:
>> tomcat/tc6.0.x/trunk/test/org/apache/catalina/tomcat/util/http/TestCookies.java
>>
>> URL:
>> http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/test/org/apache/catalina/tomcat/util/http/TestCookies.java?rev=588673&view=auto
>>
>> ==
>>
>> ---
>> tomcat/tc6.0.x/trunk/test/org/apache/catalina/tomcat/util/http/TestCookies.java
>> (added)
>> +++
>> tomcat/tc6.0.x/trunk/test/org/apache/catalina/tomcat/util/http/TestCookies.java
>> Fri Oct 26 07:51:23 2007
>> @@ -0,0 +1,258 @@
>> +/*
>> + * Licensed to the Apache Software Foundation (ASF) under one or more
>> + * contributor license agreements. See the NOTICE file distributed
>> with
>> + * this work for additional information regarding copyright ownership.
>> + * The ASF licenses this file to You under the Apache License,
>> Version 2.0
>> + * (the "License"); you may not use this file except in compliance with
>> + * the License. You may obtain a copy of the License at
>> + *
>> + * http://www.apache.org/licenses/LICENSE-2.0
>> + *
>> + * Unless required by applicable law or agreed to in writing, software
>> + * distributed under the License is distributed on an "AS IS" BASIS,
>> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
>> implied.
>> + * See the License for the specific language governing permissions and
>> + * limitations under the License.
>> + */
>> +
>> +import org.apache.tomcat.util.http.Cookies;
>> +import org.apache.tomcat.util.http.ServerCookie;
>> +
>> +import junit.framework.Test;
>> +import junit.framework.TestCase;
>> +import junit.framework.TestSuite;
>> +import junit.textui.TestRunner;
>> +
>> +import java.lang.Exception;
>> +
>> +
>> +public class TestCookies extends TestCase {
>> +public static void main( String args[] ) {
>> + TestRunner.run(suite());
>> +}
>> +public static Test suite() {
>> + TestSuite suite = new TestSuite();
>> + suite.addTest(new TestSuite(TestCookies.class));
>> + return suite;
>> +}
>> +/*
>> + int i = 1000;
>> + // These tests are not really representative +
>> while (i-- > 0) { + test("session=1234567890;name=\"John
>> Q. Public\";");
>>
Re: Time to organise svn - Take 3
Mark Thomas wrote: > Mark Thomas wrote: >> svn cp >> https://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_15 >> https://svn.apache.org/repos/asf/tomcat/tc6.1.0/trunk >> >> https://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_15 >> https://svn.apache.org/repos/asf/tomcat/trunk >> >> Changes to .../trunk with be CTR >> Changes to .../6.1.x/trunk will be RTC > > As per the previously published plan, I will create tomcat/tc6.1.x/trunk > and tomcat/trunk from the 6.0.15 tag. I plan to do this sometime on Friday > afternoon GMT. Why Friday? Shouldn't we wait until 6.0.15 (or 6.0.15 + n) is voted stable? Cheers Jean-Frederic > Any commits to 6.0.x/trunk between now and then I will apply > using CTR to trunk. > > Mark > > > - > 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: Time to organise svn - Take 3
Filip Hanik - Dev Lists wrote: > Mark Thomas wrote: >> jean-frederic clere wrote: >> >>> Why Friday? Shouldn't we wait until 6.0.15 (or 6.0.15 + n) is voted >>> stable? >>> >> >> We can do if that is the preference. My motivation is that I am keen >> to get >> back to a CTR codebase asap as I find only having RTC a real pain. >> > he he, I think everyone does, however two months ago you said > "I don't see a need for a separate 6.0.x and 6.1.x development at this > point. I have yet to see a convincing technical argument that there is > something sufficiently new and/or different to justify this overhead." > > has anything changed since before when we had trunk and 6.0.x, to the > point where we have more resources and more todos to maintain 6.0.x, > 6.1.x and trunk? This is one more branch than we used to have. > > wouldn't it be better to hold of on the 6.1.x until there is a feature > set for that release, and only have trunk. Otherwise we will have two > 6.0.x branches, just one is named 6.1.x but there is nothing different > with them Yep. I also prefer to have only trunk based on 6.0.15 I don't think we need 6.1.x for the moment. We should be able to make proposals for tc6.0.x back porting using commits from trunk for a while. Additional I think we should also create/prepare a ROADMAP in/for this trunk to discuss what the new features we want to put inside. Cheers Jean-Frederic > > > Filip > > - > 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: [VOTE] Release build 6.0.15
Filip Hanik - Dev Lists wrote: > I'm having problems with the cookie parsing > It is seems there are 2 problems... The version (only TCK will complain) and we are re escaping already escaped strings. I will prepare a patch later today. Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r595376 - /tomcat/current/tc5.5.x/STATUS
[EMAIL PROTECTED] wrote: > Author: pero > Date: Thu Nov 15 09:58:26 2007 > New Revision: 595376 > > URL: http://svn.apache.org/viewvc?rev=595376&view=rev > Log: > Add JDT Location change > > Modified: > tomcat/current/tc5.5.x/STATUS > > Modified: tomcat/current/tc5.5.x/STATUS > URL: > http://svn.apache.org/viewvc/tomcat/current/tc5.5.x/STATUS?rev=595376&r1=595375&r2=595376&view=diff > == > --- tomcat/current/tc5.5.x/STATUS (original) > +++ tomcat/current/tc5.5.x/STATUS Thu Nov 15 09:58:26 2007 > @@ -50,3 +50,10 @@ >http://people.apache.org/~markt/patches/2007-10-28-cookies-tc5.patch >+1: markt >-1: > + > +* JDT location return 404 > + http://people.apache.org/~fhanik/patches/jdt-loc.patch > + Backport from Tomcat 6 > + +1: pero > + -1: > + Well I don't see the need to change it there. The location is http://archive.eclipse.org/eclipse/downloads/drops/R-3.1.2-200601181600/eclipse-JDT-3.1.2.zip and it is still valid. Cheers Jean-Frederic > > > > - > 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: svn commit: r595376 - /tomcat/current/tc5.5.x/STATUS
Peter Rossbach wrote: > Strange, > > but with Revision 586865 I have test with the link and check in the JDT > 3.3.1 change at 27.10.07 Ok then. But I still think that the version change is a bit useless. Cheers Jean-Frederic > > Peter > > > > Am 15.11.2007 um 20:04 schrieb Filip Hanik - Dev Lists: > >> jean-frederic clere wrote: >>> [EMAIL PROTECTED] wrote: >>> >>>> Author: pero >>>> Date: Thu Nov 15 09:58:26 2007 >>>> New Revision: 595376 >>>> >>>> URL: http://svn.apache.org/viewvc?rev=595376&view=rev >>>> Log: >>>> Add JDT Location change >>>> >>>> Modified: >>>> tomcat/current/tc5.5.x/STATUS >>>> >>>> Modified: tomcat/current/tc5.5.x/STATUS >>>> URL: >>>> http://svn.apache.org/viewvc/tomcat/current/tc5.5.x/STATUS?rev=595376&r1=595375&r2=595376&view=diff >>>> >>>> == >>>> >>>> --- tomcat/current/tc5.5.x/STATUS (original) >>>> +++ tomcat/current/tc5.5.x/STATUS Thu Nov 15 09:58:26 2007 >>>> @@ -50,3 +50,10 @@ >>>>http://people.apache.org/~markt/patches/2007-10-28-cookies-tc5.patch >>>>+1: markt >>>>-1: >>>> + >>>> +* JDT location return 404 >>>> + http://people.apache.org/~fhanik/patches/jdt-loc.patch >>>> + Backport from Tomcat 6 >>>> + +1: pero >>>> + -1: + >>>> >>> >>> Well I don't see the need to change it there. The location is >>> http://archive.eclipse.org/eclipse/downloads/drops/R-3.1.2-200601181600/eclipse-JDT-3.1.2.zip >>> >>> and it is still valid. >>> >> the question with TC 5.5 is simply whether we want to upgrade to a >> later version of the JDT compiler for the next release >> >> Filip >>> Cheers >>> >>> Jean-Frederic >>> >>> >>>> >>>> - >>>> 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] >> >> > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r595376 - /tomcat/current/tc5.5.x/STATUS
Peter Rossbach wrote: > I review the tomcat 6 JDTCompiler class that only some formattings und > error handlings has change. > What is bad to use a newer JDT compiler version? That is ok for me ;-) Cheers Jean-Frederic > > regards, > Peter > > > Am 16.11.2007 um 14:09 schrieb jean-frederic clere: > >> Peter Rossbach wrote: >>> Strange, >>> >>> but with Revision 586865 I have test with the link and check in the JDT >>> 3.3.1 change at 27.10.07 >> >> Ok then. But I still think that the version change is a bit useless. >> >> Cheers >> >> Jean-Frederic >> >> >>> >>> Peter >>> >>> >>> >>> Am 15.11.2007 um 20:04 schrieb Filip Hanik - Dev Lists: >>> >>>> jean-frederic clere wrote: >>>>> [EMAIL PROTECTED] wrote: >>>>> >>>>>> Author: pero >>>>>> Date: Thu Nov 15 09:58:26 2007 >>>>>> New Revision: 595376 >>>>>> >>>>>> URL: http://svn.apache.org/viewvc?rev=595376&view=rev >>>>>> Log: >>>>>> Add JDT Location change >>>>>> >>>>>> Modified: >>>>>> tomcat/current/tc5.5.x/STATUS >>>>>> >>>>>> Modified: tomcat/current/tc5.5.x/STATUS >>>>>> URL: >>>>>> http://svn.apache.org/viewvc/tomcat/current/tc5.5.x/STATUS?rev=595376&r1=595375&r2=595376&view=diff >>>>>> >>>>>> >>>>>> == >>>>>> >>>>>> >>>>>> --- tomcat/current/tc5.5.x/STATUS (original) >>>>>> +++ tomcat/current/tc5.5.x/STATUS Thu Nov 15 09:58:26 2007 >>>>>> @@ -50,3 +50,10 @@ >>>>>> >>>>>> http://people.apache.org/~markt/patches/2007-10-28-cookies-tc5.patch >>>>>>+1: markt >>>>>>-1: >>>>>> + >>>>>> +* JDT location return 404 >>>>>> + http://people.apache.org/~fhanik/patches/jdt-loc.patch >>>>>> + Backport from Tomcat 6 >>>>>> + +1: pero >>>>>> + -1: + >>>>>> >>>>> >>>>> Well I don't see the need to change it there. The location is >>>>> http://archive.eclipse.org/eclipse/downloads/drops/R-3.1.2-200601181600/eclipse-JDT-3.1.2.zip >>>>> >>>>> >>>>> and it is still valid. >>>>> >>>> the question with TC 5.5 is simply whether we want to upgrade to a >>>> later version of the JDT compiler for the next release >>>> >>>> Filip >>>>> Cheers >>>>> >>>>> Jean-Frederic >>>>> >>>>> >>>>>> >>>>>> - >>>>>> 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] >>>> >>>> >>> >>> >> >> >> - >> 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: svn commit: r596761 - in /tomcat/tc6.0.x/trunk: ./ java/org/apache/catalina/core/ java/org/apache/catalina/startup/ java/org/apache/tomcat/util/net/ res/
[EMAIL PROTECTED] wrote:
> Author: jim
> Date: Tue Nov 20 10:19:00 2007
> New Revision: 596761
>
> URL: http://svn.apache.org/viewvc?rev=596761&view=rev
> Log:
> Fix BZ 43588 - hard coded 127.0.0.1 for localhost
>
> Modified:
> tomcat/tc6.0.x/trunk/STATUS.txt
> tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardServer.java
> tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/Catalina.java
> tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
> tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/BaseEndpoint.java
> tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/JIoEndpoint.java
> tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
> tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/PoolTcpEndpoint.java
> tomcat/tc6.0.x/trunk/res/tomcat.nsi
>
> Modified: tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/Catalina.java
> URL:
> http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/Catalina.java?rev=596761&r1=596760&r2=596761&view=diff
> ==
> --- tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/Catalina.java
> (original)
> +++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/Catalina.java Tue
> Nov 20 10:19:00 2007
> @@ -24,6 +24,7 @@
> import java.io.IOException;
> import java.io.InputStream;
> import java.io.OutputStream;
> +import java.net.InetAddress;
> import java.net.Socket;
> import java.util.ArrayList;
> import java.util.HashMap;
> @@ -416,7 +417,8 @@
>
> // Stop the existing server
> try {
> -Socket socket = new Socket("127.0.0.1", server.getPort());
> +String hostAddress =
> InetAddress.getByName("localhost").getHostAddress();
> +Socket socket = new Socket(hostAddress, server.getPort());
Why not using Socket socket = new Socket("localhost", server.getPort()); ?
Cheers
Jean-Frederic
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r596761 - in /tomcat/tc6.0.x/trunk: ./ java/org/apache/catalina/core/ java/org/apache/catalina/startup/ java/org/apache/tomcat/util/net/ res/
Filip Hanik - Dev Lists wrote:
> jean-frederic clere wrote:
>> [EMAIL PROTECTED] wrote:
>>
>>> Author: jim
>>> Date: Tue Nov 20 10:19:00 2007
>>> New Revision: 596761
>>>
>>> URL: http://svn.apache.org/viewvc?rev=596761&view=rev
>>> Log:
>>> Fix BZ 43588 - hard coded 127.0.0.1 for localhost
>>>
>>> Modified:
>>> tomcat/tc6.0.x/trunk/STATUS.txt
>>>
>>> tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardServer.java
>>> tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/Catalina.java
>>>
>>> tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
>>>
>>> tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/BaseEndpoint.java
>>>
>>> tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/JIoEndpoint.java
>>>
>>> tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
>>>
>>> tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/PoolTcpEndpoint.java
>>>
>>> tomcat/tc6.0.x/trunk/res/tomcat.nsi
>>>
>>>
>>
>>
>>> Modified:
>>> tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/Catalina.java
>>> URL:
>>> http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/Catalina.java?rev=596761&r1=596760&r2=596761&view=diff
>>>
>>> ==
>>>
>>> ---
>>> tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/Catalina.java
>>> (original)
>>> +++
>>> tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/Catalina.java
>>> Tue Nov 20 10:19:00 2007
>>> @@ -24,6 +24,7 @@
>>> import java.io.IOException;
>>> import java.io.InputStream;
>>> import java.io.OutputStream;
>>> +import java.net.InetAddress;
>>> import java.net.Socket;
>>> import java.util.ArrayList;
>>> import java.util.HashMap;
>>> @@ -416,7 +417,8 @@
>>>
>>> // Stop the existing server
>>> try {
>>> -Socket socket = new Socket("127.0.0.1", server.getPort());
>>> +String hostAddress =
>>> InetAddress.getByName("localhost").getHostAddress();
>>> +Socket socket = new Socket(hostAddress, server.getPort());
>>>
>>
>> Why not using Socket socket = new Socket("localhost",
>> server.getPort()); ?
>>
> :) save one line
> there is no difference, the Socket class will do the exact same
> translation.
> same code will get executed
Ok. I would have prefer to keep modifications to the minimum that is
more easy to review patches.
Cheers
Jean-Frederic
> Filip
>> Cheers
>>
>> Jean-Frederic
>>
>> -
>> 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]
Re: FW: Delays in mod_jk
Larry Reisler wrote: > Rainer -- > > I recently changed replaced the version of JBOSS Web we were using to > JBOSSWEB_2_0_0_GA_CP04. It included several patches to the AJP code. That > appears to have solved the problem. The FIN packets from the back end come > back immediately now. I'm guessing that the fix to JBPAPP-366 > (http://jira.jboss.org/jira/browse/JBPAPP-366) fixed this too. > > I still see the mod_jk architecture as problematic JBPAPP-366 is http://svn.apache.org/viewvc?rev=589062&view=rev that was a bug in the JAVA part not in mod_jk. Cheers Jean-Frederic > -- it would be better if cleaning up the sockets would occur on a different > thread and without the critical section locked. > > Larry > > -Original Message- > From: Larry Reisler [mailto:[EMAIL PROTECTED] > Sent: Monday, November 26, 2007 10:08 AM > To: Rainer Jung; Tomcat Developers List > Subject: RE: Delays in mod_jk > > Rainer -- > > I am using out of the box JBOSS 4.21 -- no special connector, and no firewall > between the httpd tier and the other tier. > > Indeed, I agree that the FIN packet from the back end is missing. It seems > to come much later in the dump (exactly 4 minutes later). I can't help but > think this is an issue on the JBOSS side, but I'm not sure where to go to try > to debug that. > > I will send you the full capture file separately by private Mail. > > Larry > > > -Original Message- > From: Rainer Jung [mailto:[EMAIL PROTECTED] > Sent: Sunday, November 25, 2007 4:35 PM > To: Tomcat Developers List > Subject: Re: Delays in mod_jk > > Hi Larry, > > I'm again investigating your problem report concerning 2 second pauses > during socket shutdown in JK maintenance. Sorry for the long pause, but > I want to see, if there is something we need to fix before 1.2.26 > related to this case. > > I couldn't reproduce the behaviour on Linux. Do you use a special > connector for AJP in JBoss, like Tomcats APR connector, or is it just > the plain Coyote connector? Is there a firewall in between httpd and > JBoss? If so, would it be possible to sniff again on both sides? > > Larry Reisler wrote: >> I got a trace using some of the settings you have below. I'm not >> quite sure how to get the whole thing to you, as it is fairly large, >> and I don't wish to post it to the mailing list. > > If you like, you can send it by private Mail. > >> In any event the relevant lines from one example of an interaction I >> am attaching below. 10.45.3.22 is the apache 2.2 server and >> 10.45.3.21 and 10.45.3.24 are the tomcat servers. The trace was >> taken from the apache server. There are numerous other examples of >> this type of interaction. >> >> 02:49:04.329952 IP 10.45.3.22.34977 > 10.45.3.21.8009: F >> 2991069804:2991069804(0) ack 1909717451 win 8244 > 865633671 2700468480> 02:49:04.370343 IP 10.45.3.21.8009 > >> 10.45.3.22.34977: . ack 1 win 1448 > 865633671> 02:49:06.329558 IP 10.45.3.22.34972 > 10.45.3.24.8009: F >> 2991428814:2991428814(0) ack 330342931 win 4624 > 865635671 4202573488> 02:49:06.369533 IP 10.45.3.24.8009 > >> 10.45.3.22.34972: . ack 1 win 2269 > 865635671> 02:49:08.329843 IP 10.45.3.22.35008 > 10.45.3.24.8009: S >> 3372523679:3372523679(0) win 5840 > 865637671 0,nop,wscale 2> 02:49:08.329961 IP 10.45.3.24.8009 > >> 10.45.3.22.35008: S 707449532:707449532(0) ack 3372523680 win 5792 >> >> 02:49:08.329972 IP 10.45.3.22.35008 > 10.45.3.24.8009: . ack 1 win >> 1460 02:49:08.330001 IP >> 10.45.3.22.35008 > 10.45.3.24.8009: P 1:821(820) ack 1 win 1460 >> 02:49:08.330023 IP >> 10.45.3.22.35008 > 10.45.3.24.8009: P 821:921(100) ack 1 win 1460 >> >> >> My analysis of this is as follows: 1) A request comes in to the >> apache server, which has two timed out socket connections to the >> tomcat servers on ports 34977 and 34972. At 02:49:04.329952 it sends >> a FIN packet to the tomcat server and receives a response at >> 02:49:04.370343. It then waits two seconds from the time it sent the >> FIN packet. 2) At 02:49:06.329558 it sends a FIN packet to the other >> tomcat server and receives a response at 02:49:06.369533. It then >> waits two seconds from the time it sent the FIN packet, and then >> creates a new socket (35008) on which it successfully sends the >> transaction. > > The tcpdump excerpt seems to be incomplete. After the FIN and the > accompanying ACK, the final FIN/ACK from the backend is missing. Does it > occur later in the dump? If not, there should be a RST or the connection > should still be in CLOSE_WAIT on the JBoss machine. > > Regards, > > Rainer > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bootstrap redirecting stdout/err via system.set
William L. Thomson Jr. wrote:
> Recently on Gentoo I was looking to improve how we start Tomcat.
> Specifically how we capture stdout/stderr output from Tomcat on start
> and redirect it to catalina.out.
Have to tried to use jsvc from http://commons.apache.org/daemon/ for that?
Cheers
Jean-Frederic
Presently due to our use of
> start-stop-daemon and some issues it comes with. We are using the normal
> redirection to capture the output. >> catalina.out 2>&1
>
> In getting feedback to alternatives to our present approach, like that
> suggested in comment #5 on the following bug[1]. Another inquired as to
> why Tomcat wasn't capturing and redirecting it's own stdout/stderr via
> system properties?
>
> Like how .home and .base are set now.
>
> public void setCatalinaHome(String s) {
> System.setProperty( "catalina.home", s );
> }
> public void setCatalinaBase(String s) {
> System.setProperty( "catalina.base", s );
> }
>
> Which would alleviate the need to capture and redirect that stuff
> externally of Tomcat. Is there a reason this is not currently done? Has
> this approach been considered before? Something like
>
> System.setOut(aPrintStream);
> System.setErr(aPrintStream);
>
> Where the location would be configurable via a var or etc with a default
> specified.
>
> Basically others are suggesting I write a wrapper class or etc to
> Bootstrap to set those properties there. I guess we could do that on
> Gentoo. But would like to get upstreams input there. Much less I would
> likely patch Bootstrap before wrapping it.
>
>
> http://bugs.gentoo.org/show_bug.cgi?id=162379
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bootstrap redirecting stdout/err via system.set
William L. Thomson Jr. wrote: > On Wed, 2007-11-28 at 09:29 +0100, jean-frederic clere wrote: >> William L. Thomson Jr. wrote: >>> Recently on Gentoo I was looking to improve how we start Tomcat. >>> Specifically how we capture stdout/stderr output from Tomcat on start >>> and redirect it to catalina.out. >> Have to tried to use jsvc from http://commons.apache.org/daemon/ for that? > > We presently use start-stop-daemon. Which has some --stdout --stderr > options coming. It nastily send that stuff to /dev/null, if the > --background flag is passed along. > > We had a long time bug/feature request for jsvc. I considered it, but > elected to not go that route. If people want Tomcat on port 80 they can > do port forwarding or etc. Which allows Tomcat to remaining running as a > non-root user or etc. Nor the need for jsvc to accomplish that. So it's > kinda moot. > > But I believe the argument is that applications should do their own > stderr/out redirection and not to it external of the app. As in not via > bash/shell redirection and sending that to a log file. The app should be > doing that internally. That is what daemon is doing. Cheers Jean-Frederic > > So if I am using start-stop-daemon, or jsvc. It doesn't really change > that aspect. > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tagging TOMCAT_NATIVE_1_1_12
Hi, I'll tag the tcnative to 1.1.12. The changes are the following between 1.1.12 and 1.1.11: +++ Improvement: Add support of J9VM based JVM. (jfclere) Improvement: Arrange licence in source files. (markt). Improvement: Add two new 'immediate' methods for sending the data. It is the responsibility of the Java callee to deal with the returned values and retry if the error was non-fatal. (mturk) Fix: Arrange the check of openssl version. It was failing on Linux. (jfclere) Fix: Prevent returning APR_SUCCESS when there is something wrong in ssl layer. Fix for PR: 44087 (jfclere) +++ It seems 1.1.10 was the latest release that has a tarball in http://archive.apache.org/dist/tomcat/tomcat-connectors/native/... Any comments? Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r606201 - in /tomcat/connectors/tags/other/TOMCAT_NATIVE_1_1_12: ./ jk/native/common/jk_util.c jk/native/common/portable.h jni/ jni/CHANGELOG.txt jni/native/ jni/native/src/sslnetwork
Rainer Jung wrote: > Hi Jean-Frederic, > > I think you accidentally committed two changes to mod_jk when tagging > tc-native. Oops I have rolled them back but that doesn't affect tcnative release code. Cheers Jean-Frederic > > Since I'm going to tag mod_jk, please let me know, if I can revert (or > revert yourself): > >> Modified: >> >> tomcat/connectors/tags/other/TOMCAT_NATIVE_1_1_12/jk/native/common/jk_util.c >> >> >> tomcat/connectors/tags/other/TOMCAT_NATIVE_1_1_12/jk/native/common/portable.h >> > > Regards, > > Rainer > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [TC6] Double AJP connector implementation
Mladen Turk wrote: Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: I don't have any preference either way, since we are pretty few active folks at the moment, the less code is usually better My plan was not to do that (org.apache.jk is not that huge) and keep people happy. Nevertheless, the Apache/IIS Config will need some rewrite anyhow. I suppose if we came up with the alternate solution for the Config generator, the org.apache.jk can be marked as dormant. Anyhow, I would like we have the org.apache.coyote.ajp as default AJP connector, both for APR and JIO. It would give more stability to both of them thought. That won't be bad... I am always testing org.apache.jk instead org.apache.coyote.ajp ;-) Cheers Jean-Frederic Regards, Mladen. - 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: svn commit: r467787 - in /tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net: NioChannel.java NioEndpoint.java SecureNioChannel.java SocketProperties.java
Peter Rossbach wrote: Hi, for other server os's I found: = For AIX: To see the current TCP_TIMEWAIT value, run the following command: /usr/sbin/no a | grep tcp_timewait To set the TCP_TIMEWAIT values to 15 seconds, run the following command: /usr/sbin/no o tcp_timewait =1 The tcp_timewait option is used to configure how long connections are kept in the timewait state. It is given in 15-second intervals, and the default is 1. For Linux: Set the timeout_timewait paramater using the following command: /sbin/sysctl -w net.ipv4.vs.timeout_timewait=30 This will set TME_WAIT for 30 seconds. No... My machine (debian 2.6.13) says: +++ [EMAIL PROTECTED]:~$ sudo /sbin/sysctl -w net.ipv4.vs.timeout_timewait=30 error: "net.ipv4.vs.timeout_timewait" is an unknown key +++ net.ipv4.tcp_fin_timeout is probably the thing to use: +++ [EMAIL PROTECTED]:~$ more /proc/sys/net/ipv4/tcp_fin_timeout 60 +++ Cheers Jean-Frederic For Solaris: Set the tcp_time_wait_interval to 3 milliseconds as follows: /usr/sbin/ndd -set /dev/tcp tcp_time_wait_interval 3 == Tipps for tuning mac os x 10.4 are very welcome :-( Regards Peter Roßbach [EMAIL PROTECTED] Am 26.10.2006 um 20:58 schrieb Filip Hanik - Dev Lists: That's some very good info, it looks like my system never does go over 30k and cleaning it up seems to be working really well. btw. do you know where I change the cleanup intervals for linux 2.6 kernel? I figured out what the problem was: Somewhere I have a lock/wait problem for example, this runs perfectly: ./ab -n 1 -c 100 http://localhost:$PORT/run.jsp?run=TEST$i If I change -c 100 (100 sockets) to -c 1, each JSP request takes 1 second. so what was happening in my test was running 1000 requests over 400 connections, then invoking 1 request over 1 connection, and repeat. Every time I did the single connection request, it does a 1sec delay, this cause the CPU to drop. So basically, the NIO connector sucks majorly if you are a single user :), I'll trace this one down. Filip Rainer Jung wrote: Hi Filip, the fluctuation reminds me of something: depending on the client behaviour connections will end up in TIME_WAIT state. Usually you run into trouble (throughput stalls) once you have around 30K of them. They will be cleaned up every now and then by the kernel (talking about the unix/Linux style mechanisms) and then throughput (and CPU usage) start again. With modern systems handling 10-20k requests per second one can run into trouble much faster, than the usual cleanup intervals. Check with "netstat -an" if you can see a lot of TIME_WAIT connections (thousands). If not it's something different :( Regards, Rainer Filip Hanik - Dev Lists schrieb: Remy Maucherat wrote: [EMAIL PROTECTED] wrote: Author: fhanik Date: Wed Oct 25 15:11:10 2006 New Revision: 467787 URL: http://svn.apache.org/viewvc?view=rev&rev=467787 Log: Documented socket properties Added in the ability to cache bytebuffers based on number of channels or number of bytes Added in nonGC poller events to lower CPU usage during high traffic I'm starting to get emails again, so sorry for not replying. I am testing with the default VM settings, which basically means that excessive GC will have a very visible impact. I am testing to optimize, not to see which connector would be faster in the real world (probably neither unless testing scalability), so I think it's reasonable. This fixes the paranormal behavior I was seeing on Windows, so the NIO connector works properly now. Great ! However, I still have NIO which is slower than java.io which is slower than APR. It's ok if some solutions are better than others on certain platforms of course. thanks for the feedback, I'm testing with larger files now, 100k+ and also see APR->JIO->NIO NIO has a very funny CPU telemetry graph, it fluctuates way to much, so I have to find where in the code it would do this, so there is still some work to do. I'd like to see a nearly flat CPU usage when running my test, but instead the CPU goes from 20-80% up and down, up and down. during my test (for i in $(seq 1 100); do echo -n "$i."; ./ab -n 1000 -c 400 http://localhost:$PORT/104k.jpg 2>1 |grep "Requests per"; done) my memory usage goes up to 40MB, then after a FullGC it goes down to 10MB again, so I wanna figure out where that comes from as well. My guess is that all that data is actually in the java.net.Socket classes, as I am seeing the same results with the JIO connector, but not with APR(cause APR allocates mem using pools) Btw, had to put in the byte[] buffer back into the InternalNioOutputBuffer.java, ByteBuffers are way to slow. With APR, I think the connections might be lingering to long as eventually, during my test, it stop accepting connections. Usually around the 89th iteration of the test. I'm gonna keep working on this for a bit, as I think I am getting to a point with the NIO
building TC 5.5.9 failed
Hi, I am not able to build 5.5.9, build failed with: +++ build-jasper: [echo] == Building: jasper build-only: [javac] Compiling 87 source files to /home/jfclere/jakarta- tomcat-5.5.9-src/jakarta-tomcat-5/build/classes [javac] /home/jfclere/jakarta-tomcat-5.5.9-src/jakarta-tomcat- jasper/jasper2/src/share/org/apache/jasper/compiler/JDTCompiler.java:194: cannot find symbol [javac] symbol : constructor NameEnvironmentAnswer (org.eclipse.jdt.internal.compiler.env.ICompilationUnit) [javac] location: class org.eclipse.jdt.internal.compiler.env.NameEnvironmentAnswer [javac] new NameEnvironmentAnswer (compilationUnit); [javac] ^ [javac] /home/jfclere/jakarta-tomcat-5.5.9-src/jakarta-tomcat- jasper/jasper2/src/share/org/apache/jasper/compiler/JDTCompiler.java:215: cannot find symbol [javac] symbol : constructor NameEnvironmentAnswer (org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader) [javac] location: class org.eclipse.jdt.internal.compiler.env.NameEnvironmentAnswer [javac] new NameEnvironmentAnswer (classFileReader); [javac] ^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] 2 errors +++ Where could I find the right version of eclipse-JDT-3.0.1.zip? Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Change in behaviour of uriworkermap.properties
On Tue, 2006-11-21 at 06:52 +0100, Mladen Turk wrote: > Rainer Jung wrote: > > > > E.g. if one empties the uriworkermap.properties, reloading it does not > > change the internal mount list. Temporarily adding and later removing an > > entry will not remove the entry. > > That's the entire point. > Once new entry is added it will be there for the server lifetime. > Of course it can be disabled with minus prefix. > > If one adds the mount point and then deletes it, other child > processes might not pick that up, but that's not how they > suppose to work. "Deletion" *must* be done only by prefixing > the mount points with minus. > I'm not even sure why I allow to have the new mounts at > the first place. > > > One could live with that (after we > > improve the docs). > > > > Sure. The entire idea of reloading a uriworkermap.properties > was to temporary disable some pre-existing mount. > > Anything else should be handled via graceful restart. > BTW, this was added only to help the IIS that doesn't have > the graceful restart concept. > > > I don't like the idea of splitting the static and dynamic > mount points. > The proper way to go would be to add the second shared memory > (database like) that would contain the mount points with > options to manage that via jkstatus. Anything else IMHO is > useless, because it can be done via simple restart, if one > needs to add/remove the whole bunch of new mounts in frequent > way. Yep. Static configuration is just a dynamic configuration that never changes. The right way to go is to have the configuration in shared memory the complex stuff is how to update it. I am trying to get something similar to work on mod_proxy and I need an external process to update the shared memory. Cheers Jean-Frederic > > > Regards, > Mladen. > > - > 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: [Proposal] Change in behaviour of uriworkermap.properties
On Tue, 2006-11-21 at 11:58 +0100, Rainer Jung wrote: > Henri Gomez schrieb: > > Why not just extends current jkstatus ? > > Mapping rules are kept process local. They are only shared, because the > first process generates them and afterwards all other processes inherit > them during fork. > > To make the rules manageable via jkstatus (everyone wants that, me too; > it's a much bigger task) we need to do two things: > > - use shared memory at least to exchange information about changes to > maping rules, so that the process that handles the jkstatus request is > able to distribute the changes. > > - also we need to think about virtual hosts: mapping rules are per > virtual host. At the moment, if you call jkstatus, you will only see the > rules defined for the virtual host, which you called with jkstatus. If > you want to have a central administration point, jkstatus must go > through all vhosts starting from the main server to produce the list, > and if you change something it might need to change it in a vhost that's > different from the vhost, the request runs in. > > This is no argument, that it is very hard to make these changes. It's > simply not in scope for the next release, which should get ready in very > few days, because we had a couple of nice bug fixes since 1.2.19. May be that is time to make a new branch: 1.3 for example ;-) Cheers Jean-Frederic > > Regards, > > Rainer > > > > > 2006/11/21, Rainer Jung <[EMAIL PROTECTED]>: > >> Jean-frederic Clere schrieb: > >> > On Tue, 2006-11-21 at 06:52 +0100, Mladen Turk wrote: > >> >> Rainer Jung wrote: > >> >>> E.g. if one empties the uriworkermap.properties, reloading it does > >> not > >> >>> change the internal mount list. Temporarily adding and later > >> removing an > >> >>> entry will not remove the entry. > >> >> That's the entire point. > >> > >> But this is not what a user expects from a change in a list. > >> > >> >> Once new entry is added it will be there for the server lifetime. > >> >> Of course it can be disabled with minus prefix. > >> >> > >> >> If one adds the mount point and then deletes it, other child > >> >> processes might not pick that up, but that's not how they > >> >> suppose to work. "Deletion" *must* be done only by prefixing > >> >> the mount points with minus. > >> >> I'm not even sure why I allow to have the new mounts at > >> >> the first place. > >> > >> OK, but you did. And my proposal comes in, because I want to fix this > >> behaviour exactly becauswe of the case, are adding and deleting rules. > >> > >> >> > >> >>> One could live with that (after we > >> >>> improve the docs). > >> >>> > >> >> Sure. The entire idea of reloading a uriworkermap.properties > >> >> was to temporary disable some pre-existing mount. > >> > >> I understand, but it can be used in a much more powerful way. > >> It's an external file with an easy syntax, so external monitor and > >> manage scripts can easily manipulate it's contents. > >> > >> >> > >> >> Anything else should be handled via graceful restart. > >> >> BTW, this was added only to help the IIS that doesn't have > >> >> the graceful restart concept. > >> > >> Graceful restarts can produce hanging processes under heavy load. You'll > >> notice slots in state "G" or "L" in the server-status. > >> > >> >> I don't like the idea of splitting the static and dynamic > >> >> mount points. > >> >> The proper way to go would be to add the second shared memory > >> >> (database like) that would contain the mount points with > >> >> options to manage that via jkstatus. Anything else IMHO is > >> >> useless, because it can be done via simple restart, if one > >> >> needs to add/remove the whole bunch of new mounts in frequent > >> >> way. > >> > > >> > Yep. Static configuration is just a dynamic configuration that never > >> > changes. The right way to go is to have the configuration in shared > >> > memory the complex stuff is how to update it. > >> > I am trying to get something similar to work on mod_proxy and I need an > >> > external proce
Re: [VOTE] Releasing Tomcat Connectors 1.2.20
[X] Stable - no major issues, no regressions Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r502649 - /tomcat/connectors/trunk/jk/native/common/jk_global.h
Rainer Jung wrote: I can't test on HP-UX, but maybe you (jfc) could try: The problem is that sys/socketvar.h can't be compiled using gcc and I think we don't need it HP-UX (for example APR doesn't include it). I will test the modifications in configure.in later. Cheers Jean-Frederic Index: configure.in === --- configure.in(revision 502659) +++ configure.in(working copy) @@ -139,6 +139,10 @@ dnl check for filio.h used on Solaris to define FIONREAD ioctl. AC_CHECK_HEADERS(sys/filio.h) +dnl check for socketvar.h and select.h not used on HPUX11 +AC_CHECK_HEADERS(sys/socketvar.h) +AC_CHECK_HEADERS(sys/select.h) + AC_DEFUN([JK_CHECK_SETSOCKOPT], [ AC_MSG_CHECKING(whether to use $1 with setsockopt()) AC_TRY_RUN([ Index: common/jk_global.h === --- common/jk_global.h (revision 502659) +++ common/jk_global.h (working copy) @@ -142,10 +142,10 @@ #include #include #include -#if !defined(_OSD_POSIX) && !defined(AS400) && !defined(CYGWIN) && !defined(HPUX11) +#if !defined(_OSD_POSIX) && !defined(AS400) && !defined(CYGWIN) && !defined(HAVE_SYS_SOCKETVAR_H) #include #endif -#if !defined(HPUX11) && !defined(AS400) +#if !defined(HAVE_SYS_SELECT_H) && !defined(AS400) #include #endif #endif Of course you would need to rebuild configure via buildconf.sh after changing configure.in. Regards, Rainer Jim Jagielski wrote: Don't we also have a HPUX11 specific check like the 2nd line after this one? Seems consistent to me :/ On Feb 2, 2007, at 12:14 PM, Rainer Jung wrote: Hi Jean-Frederic, shouldn't we be able to find out about the necessity to include it via configure? At least HP-UX should be able to use the configure mechanism. I think we mostly use the hard coded defines for the platforms, where we can't use the configure mechanism. Regards, Rainer [EMAIL PROTECTED] wrote: Author: jfclere Date: Fri Feb 2 08:27:53 2007 New Revision: 502649 URL: http://svn.apache.org/viewvc?view=rev&rev=502649 Log: Otherwise it doesn't compile with gcc on HPUX. Modified: tomcat/connectors/trunk/jk/native/common/jk_global.h Modified: tomcat/connectors/trunk/jk/native/common/jk_global.h URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_global.h?view=diff&rev=502649&r1=502648&r2=502649 == --- tomcat/connectors/trunk/jk/native/common/jk_global.h (original) +++ tomcat/connectors/trunk/jk/native/common/jk_global.h Fri Feb 2 08:27:53 2007 @@ -142,7 +142,7 @@ #include #include #include -#if !defined(_OSD_POSIX) && !defined(AS400) && !defined(CYGWIN) +#if !defined(_OSD_POSIX) && !defined(AS400) && !defined(CYGWIN) && !defined(HPUX11) #include #endif #if !defined(HPUX11) && !defined(AS400) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --kippdata informationstechnologie GmbH Bornheimer Str. 33a 53111 Bonn Tel.: 0228/98549-0 Fax: 0228/98549-50 www.kippdata.de === kippdata informationstechnologie GmbH Bornheimer Str. 33a D-53111 Bonn Tel.: +49/0228/98549-0 Fax: +49/0228/98549-50 www.kippdata.de - 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]
Re: [VOTE] Release build 5.5.23
Filip Hanik - Dev Lists wrote: Candidate binaries are available here: http://people.apache.org/~fhanik/tomcat/tomcat-5.5/v5.5.23/ According to the (slightly) updated release process, the 5.5.23 tag is: [ ] Broken [ ] Alpha [ ] Beta [ X] Stable Cheers Jean-Frederic Filip - 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]
