Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
Jan Luehe wrote: I noticed that if I send a request specifying HTTP/1.0 as the protocol version, and the response exceeds the output buffer, TC returns an HTTP/1.1 response with neither a Content-Length nor a Transfer-Encoding: chunked header. I would have expected it to include a Content-Length header. Would you agree? Of course not, this is completely valid. The server must: - return the highest protocol version it supports - close the connection to indicate the end of the response if the content-length is not set I'm wondering why you're desperately trying to find things to fix in Coyote HTTP/1.1, which AFAIK is quite good in terms of HTTP compliance. There are still things that can be improved in there, such as the compression support (but I plan to help, since I'm done with my 5.0.x feature list), but these are not critical features. If I could choose, I'd prefer you help fix issues on Jasper, since you know it well and there are still bugs to fix ;-) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
Marc Slemko wrote: On Mon, 14 Jul 2003, Jan Luehe wrote: I would have expected it to include a Content-Length header. Would you agree? It, umh, can't do that for dynamic content without buffering the whole response since it doesn't know how long it is. Not even that does work, actually. The problem occurs if the servlet flushes the response before closing it. If that happens, then part of the response must be sent right away, regardless of the response state. I don't know if you've seen that a lot (I have), but a lot of servlet authors do, at the end of their servlets, somthing like: out.flush(); out.close(); This forces use of chunking (or a connection close in HTTP/1.0 with keep-alive). Hence the main reason for chunked encoding and the requirement HTTP/1.1 clients support it. Any HTTP/1.1 client must support chunked encoding, if not then it is broken and really don't need to be taken into account. If someone doesn't want to support chunked encoding, they shouldn't be making HTTP/1.1 requests. Yes, that's the idea :) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
Speaking of jasper, I'm very sorry to interrupt again, and I know it's bad etiquette to repeat myself, but I have two patches to outstanding bugs in Jasper and I'm just asking for a little help navigating your CVS repository so I can make it easy for you to get them in. Details here: http://www.mail-archive.com/[EMAIL PROTECTED]/msg44405.html Regards, -David Remy Maucherat [EMAIL PROTECTED] wrote on 07/15/2003 03:39:20 AM: Jan Luehe wrote: I noticed that if I send a request specifying HTTP/1.0 as the protocol version, and the response exceeds the output buffer, TC returns an HTTP/1.1 response with neither a Content-Length nor a Transfer-Encoding: chunked header. I would have expected it to include a Content-Length header. Would you agree? Of course not, this is completely valid. The server must: - return the highest protocol version it supports - close the connection to indicate the end of the response if the content-length is not set I'm wondering why you're desperately trying to find things to fix in Coyote HTTP/1.1, which AFAIK is quite good in terms of HTTP compliance. There are still things that can be improved in there, such as the compression support (but I plan to help, since I'm done with my 5.0.x feature list), but these are not critical features. If I could choose, I'd prefer you help fix issues on Jasper, since you know it well and there are still bugs to fix ;-) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
David Wood wrote: Speaking of jasper, I'm very sorry to interrupt again, and I know it's bad etiquette to repeat myself, but I have two patches to outstanding bugs in Jasper and I'm just asking for a little help navigating your CVS repository so I can make it easy for you to get them in. Details here: http://www.mail-archive.com/[EMAIL PROTECTED]/msg44405.html I recommend you experiment more with CVS, which is a basic requirement for dealing with OSS projects. - source bundles are available - you should contribute patches for TC 5 if you can; you can send patches for TC 4.1, but they are less likely to be integrated Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
Let's be nice to each other, Remy. I want to help. My question was very specific. Why, when I check out TOMCAT_4_1_24, does it not match what's in your jakarta-tomcat-4.1.24-LE-jdk14.zip source bundle? The bugzilla #'s aren't closed, but I want to be sure these fixes are already in, and provide a more useful diff. Remy Maucherat [EMAIL PROTECTED] wrote on 07/15/2003 09:54:08 AM: David Wood wrote: Speaking of jasper, I'm very sorry to interrupt again, and I know it's bad etiquette to repeat myself, but I have two patches to outstanding bugs in Jasper and I'm just asking for a little help navigating your CVS repository so I can make it easy for you to get them in. Details here: http://www.mail-archive.com/[EMAIL PROTECTED]/msg44405.html I recommend you experiment more with CVS, which is a basic requirement for dealing with OSS projects. - source bundles are available - you should contribute patches for TC 5 if you can; you can send patches for TC 4.1, but they are less likely to be integrated Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
Marc, It can also be useful if you have a client that doesn't support chunked encoding - which is probably true for a _lot_ of scripting tools. If there is any other way to have the response not use chunked encoding, then I agree this is not needed. Do we still support HTTP/1.0 or some request header to disable the encoding? AFAIK, the HTTP/1.0 support for Tomcat-Coyote-Standalone is nearly identical to Apache/httpd. I noticed that if I send a request specifying HTTP/1.0 as the protocol version, and the response exceeds the output buffer, TC returns an HTTP/1.1 response with neither a Content-Length nor a Transfer-Encoding: chunked header. I would have expected it to include a Content-Length header. Would you agree? It, umh, can't do that for dynamic content without buffering the whole response since it doesn't know how long it is. Hence the main reason for chunked encoding and the requirement HTTP/1.1 clients support it. Any HTTP/1.1 client must support chunked encoding, if not then it is broken and really don't need to be taken into account. If someone doesn't want to support chunked encoding, they shouldn't be making HTTP/1.1 requests. just for the record, and I'll shut up after this. What you are saying is correct, but does not address the specific scenario I was testing. If you read my email again, you'll notice that my client was sending an HTTP/1.*0* request. What I was trying to test is if chunked encoding can be turned off if the client pretends to only support HTTP/1.0, since chunked encoding is a feature of HTTP/1.1. Remy has answered my question. Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
It can also be useful if you have a client that doesn't support chunked encoding - which is probably true for a _lot_ of scripting tools. If there is any other way to have the response not use chunked encoding, then I agree this is not needed. Do we still support HTTP/1.0 or some request header to disable the encoding? AFAIK, the HTTP/1.0 support for Tomcat-Coyote-Standalone is nearly identical to Apache/httpd. I noticed that if I send a request specifying HTTP/1.0 as the protocol version, and the response exceeds the output buffer, TC returns an HTTP/1.1 response with neither a Content-Length nor a Transfer-Encoding: chunked header. I would have expected it to include a Content-Length header. Would you agree? Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
On Mon, 14 Jul 2003, Jan Luehe wrote: It can also be useful if you have a client that doesn't support chunked encoding - which is probably true for a _lot_ of scripting tools. If there is any other way to have the response not use chunked encoding, then I agree this is not needed. Do we still support HTTP/1.0 or some request header to disable the encoding? AFAIK, the HTTP/1.0 support for Tomcat-Coyote-Standalone is nearly identical to Apache/httpd. I noticed that if I send a request specifying HTTP/1.0 as the protocol version, and the response exceeds the output buffer, TC returns an HTTP/1.1 response with neither a Content-Length nor a Transfer-Encoding: chunked header. I would have expected it to include a Content-Length header. Would you agree? It, umh, can't do that for dynamic content without buffering the whole response since it doesn't know how long it is. Hence the main reason for chunked encoding and the requirement HTTP/1.1 clients support it. Any HTTP/1.1 client must support chunked encoding, if not then it is broken and really don't need to be taken into account. If someone doesn't want to support chunked encoding, they shouldn't be making HTTP/1.1 requests. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
Bill Barker wrote: How about making the output buffer size limit configurable? (A value of -1 could mean indefinite growth, if people know what they are doing.) I also dislike the proposal, but since it's configurable, and off by default I can limit myself to -0. The biggest problem I see is that if people know what they are doing, then they would never dream of enabling the option :). I will vote -1 to the proposal: - this has no actual performance benefits that I can see - this is equivalent to a benchmark flag, where the server is slightly faster, but isn't useful for anything but throughtput testing (since the server would eventually just die) Do you see such a benchmark setting in the HTTPd ? I think not. I have nothing about people optimizing code, but the optimizations should have an actual usefulness (such as tag pools, which some people like). If the optimization makes the server unusable, then it shouldn't be there. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Saturday, July 12, 2003 12:21 AM Subject: Re: [5.0] [PROPOSAL] Make output buffer size limit configurable Bill Barker wrote: How about making the output buffer size limit configurable? (A value of -1 could mean indefinite growth, if people know what they are doing.) I also dislike the proposal, but since it's configurable, and off by default I can limit myself to -0. The biggest problem I see is that if people know what they are doing, then they would never dream of enabling the option :). I will vote -1 to the proposal: - this has no actual performance benefits that I can see - this is equivalent to a benchmark flag, where the server is slightly faster, but isn't useful for anything but throughtput testing (since the server would eventually just die) Do you see such a benchmark setting in the HTTPd ? I think not. I have nothing about people optimizing code, but the optimizations should have an actual usefulness (such as tag pools, which some people like). If the optimization makes the server unusable, then it shouldn't be there. Ok, you've convinced me. Changing my vote to -1. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
Remy Maucherat wrote: Bill Barker wrote: How about making the output buffer size limit configurable? (A value of -1 could mean indefinite growth, if people know what they are doing.) I also dislike the proposal, but since it's configurable, and off by default I can limit myself to -0. The biggest problem I see is that if people know what they are doing, then they would never dream of enabling the option :). I will vote -1 to the proposal: - this has no actual performance benefits that I can see - this is equivalent to a benchmark flag, where the server is slightly faster, but isn't useful for anything but throughtput testing (since the server would eventually just die) Do you see such a benchmark setting in the HTTPd ? I think not. I have nothing about people optimizing code, but the optimizations should have an actual usefulness (such as tag pools, which some people like). If the optimization makes the server unusable, then it shouldn't be there. It can also be useful if you have a client that doesn't support chunked encoding - which is probably true for a _lot_ of scripting tools. If there is any other way to have the response not use chunked encoding, then I agree this is not needed. Do we still support HTTP/1.0 or some request header to disable the encoding? Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
- Original Message - From: Costin Manolache [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, July 12, 2003 8:41 AM Subject: Re: [5.0] [PROPOSAL] Make output buffer size limit configurable Remy Maucherat wrote: Bill Barker wrote: How about making the output buffer size limit configurable? (A value of -1 could mean indefinite growth, if people know what they are doing.) I also dislike the proposal, but since it's configurable, and off by default I can limit myself to -0. The biggest problem I see is that if people know what they are doing, then they would never dream of enabling the option :). I will vote -1 to the proposal: - this has no actual performance benefits that I can see - this is equivalent to a benchmark flag, where the server is slightly faster, but isn't useful for anything but throughtput testing (since the server would eventually just die) Do you see such a benchmark setting in the HTTPd ? I think not. I have nothing about people optimizing code, but the optimizations should have an actual usefulness (such as tag pools, which some people like). If the optimization makes the server unusable, then it shouldn't be there. It can also be useful if you have a client that doesn't support chunked encoding - which is probably true for a _lot_ of scripting tools. If there is any other way to have the response not use chunked encoding, then I agree this is not needed. Do we still support HTTP/1.0 or some request header to disable the encoding? AFAIK, the HTTP/1.0 support for Tomcat-Coyote-Standalone is nearly identical to Apache/httpd. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
Remy,
Jan Luehe wrote:
Currently, the limit up to which the size of an
org.apache.coyote.tomcat5.OutputBuffer may grow is identical to the
original buffer size:
public OutputBuffer(int size) {
bb = new ByteChunk(size);
bb.setLimit(size);
...
cb = new CharChunk(size);
cb.setLimit(size);
}
As a result of this, if the response does not fit in the output
buffer, the buffer is flushed, and the response does no longer include
a Content-Length header. Instead, it includes a Transfer-Encoding
header whose value is chunked:
Transfer-Encoding: chunked
It may be useful (e.g., for some benchmarks such as TPC-W) to be able
to configure a connector such that the buffer size of its responses
grows infinitely, in which case the above setLimit calls would not
occur and the response would always include a Content-Length header,
no matter how big.
I am proposing a CoyoteConnector attribute outLimited (I am open to
other naming suggestions), whose possible values may be TRUE
(default) or FALSE: if TRUE, the output buffer size limit is set
to the output buffer size (current behaviour), and if FALSE, an
output buffer may grow infinitely.
Comments?
-1. The performance impact of chunking on the server side is zero. If
you client bench program is dumb and its performance degrades with
chunking, fine, but please keep this optimization for SunOne ;-) Your
change basically does an automatic DoS condition on the server (simply
request a big file and boom).
How about making the output buffer size limit configurable?
(A value of -1 could mean indefinite growth, if people know what they
are doing.)
Jan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
- Original Message -
From: Jan Luehe [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Friday, July 11, 2003 10:11 AM
Subject: Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
Remy,
Jan Luehe wrote:
Currently, the limit up to which the size of an
org.apache.coyote.tomcat5.OutputBuffer may grow is identical to the
original buffer size:
public OutputBuffer(int size) {
bb = new ByteChunk(size);
bb.setLimit(size);
...
cb = new CharChunk(size);
cb.setLimit(size);
}
As a result of this, if the response does not fit in the output
buffer, the buffer is flushed, and the response does no longer include
a Content-Length header. Instead, it includes a Transfer-Encoding
header whose value is chunked:
Transfer-Encoding: chunked
It may be useful (e.g., for some benchmarks such as TPC-W) to be able
to configure a connector such that the buffer size of its responses
grows infinitely, in which case the above setLimit calls would not
occur and the response would always include a Content-Length header,
no matter how big.
I am proposing a CoyoteConnector attribute outLimited (I am open to
other naming suggestions), whose possible values may be TRUE
(default) or FALSE: if TRUE, the output buffer size limit is set
to the output buffer size (current behaviour), and if FALSE, an
output buffer may grow infinitely.
Comments?
-1. The performance impact of chunking on the server side is zero. If
you client bench program is dumb and its performance degrades with
chunking, fine, but please keep this optimization for SunOne ;-) Your
change basically does an automatic DoS condition on the server (simply
request a big file and boom).
How about making the output buffer size limit configurable?
(A value of -1 could mean indefinite growth, if people know what they
are doing.)
I also dislike the proposal, but since it's configurable, and off by default
I can limit myself to -0. The biggest problem I see is that if people know
what they are doing, then they would never dream of enabling the option :).
Jan
-
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]
[5.0] [PROPOSAL] Make output buffer size limit configurable
Currently, the limit up to which the size of an
org.apache.coyote.tomcat5.OutputBuffer may grow is identical to the
original buffer size:
public OutputBuffer(int size) {
bb = new ByteChunk(size);
bb.setLimit(size);
...
cb = new CharChunk(size);
cb.setLimit(size);
}
As a result of this, if the response does not fit in the output
buffer, the buffer is flushed, and the response does no longer include
a Content-Length header. Instead, it includes a Transfer-Encoding
header whose value is chunked:
Transfer-Encoding: chunked
It may be useful (e.g., for some benchmarks such as TPC-W) to be able
to configure a connector such that the buffer size of its responses
grows infinitely, in which case the above setLimit calls would not
occur and the response would always include a Content-Length header,
no matter how big.
I am proposing a CoyoteConnector attribute outLimited (I am open to
other naming suggestions), whose possible values may be TRUE (default)
or FALSE: if TRUE, the output buffer size limit is set to the output
buffer size (current behaviour), and if FALSE, an output buffer may
grow infinitely.
Comments?
Jan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
Jan Luehe wrote:
Currently, the limit up to which the size of an
org.apache.coyote.tomcat5.OutputBuffer may grow is identical to the
original buffer size:
public OutputBuffer(int size) {
bb = new ByteChunk(size);
bb.setLimit(size);
...
cb = new CharChunk(size);
cb.setLimit(size);
}
As a result of this, if the response does not fit in the output
buffer, the buffer is flushed, and the response does no longer include
a Content-Length header. Instead, it includes a Transfer-Encoding
header whose value is chunked:
Transfer-Encoding: chunked
It may be useful (e.g., for some benchmarks such as TPC-W) to be able
to configure a connector such that the buffer size of its responses
grows infinitely, in which case the above setLimit calls would not
occur and the response would always include a Content-Length header,
no matter how big.
I am proposing a CoyoteConnector attribute outLimited (I am open to
other naming suggestions), whose possible values may be TRUE (default)
or FALSE: if TRUE, the output buffer size limit is set to the output
buffer size (current behaviour), and if FALSE, an output buffer may
grow infinitely.
Comments?
-1. The performance impact of chunking on the server side is zero. If
you client bench program is dumb and its performance degrades with
chunking, fine, but please keep this optimization for SunOne ;-) Your
change basically does an automatic DoS condition on the server (simply
request a big file and boom).
Remy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs
What about using external entities? ie: ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; [ !ENTITY jspservlet system jspservlet.xml ] then, between the servlet and servlet mapping sections jspservlet; -SMD - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, March 21, 2003 6:05 AM Subject: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs Hi, It is not very convinient or easy to insert the declarations for compiled JSPs into the webapp's web.xml file. It also has the disadvantage of adding a lot of mess in the web.xml, which the user may not like. For that reason, I propose that Tomcat parses a new (optional) XML file, with the same DTD as web.xml, which would contain declarations identical to web.xml, and which would be used for declaring the compiled JSPs. I propose naming that file compiledjsp.xml. An additional advantage is that it would allow Tomcat to precompile webapps as they are deployed (otherwise, nasty XML manipulation is needed to do that, and I think overwriting the originial web.xml during deployment is bad). Maybe someone has a better solution for this problem. Any comments ? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs
On Fri, 21 Mar 2003, Remy Maucherat wrote: Date: Fri, 21 Mar 2003 12:05:26 +0100 From: Remy Maucherat [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs Hi, It is not very convinient or easy to insert the declarations for compiled JSPs into the webapp's web.xml file. It also has the disadvantage of adding a lot of mess in the web.xml, which the user may not like. For that reason, I propose that Tomcat parses a new (optional) XML file, with the same DTD as web.xml, which would contain declarations identical to web.xml, and which would be used for declaring the compiled JSPs. I propose naming that file compiledjsp.xml. An additional advantage is that it would allow Tomcat to precompile webapps as they are deployed (otherwise, nasty XML manipulation is needed to do that, and I think overwriting the originial web.xml during deployment is bad). Maybe someone has a better solution for this problem. Any comments ? Many app servers have private deployment descriptors for extra information, similar to what Remy is proposing -- indeed, one could claim that Tomcat does this already with how we use $CATALINA_HOME/conf/web.xml to set default behavior (well, at least until Costin's recent patch :-). However, I think it would be bad policy to implement Remy's suggestion for the incorporation of JSPC output framgments, for several reasons: * Applications that would depend on this behavior are no longer portable to other containers, whereas (as Costin points out) a webapp that includes jasper-runtime.jar will run on any compliant servlet container. * Most extra info deployment descriptors contain customized elements that are not in the standard deployment descriptor's DTD or schema -- that is not the case for the elements we are talking about here. * IMHO, the deployment descriptor should be viewed as an output of a development process, rather than an input -- just as you package .class files (created from .java files) for all your bean classes. It is straightforward to create an Ant build.xml file (or whatever) that assembles fragments provided by the application developer, plus fragments generated by JSPC, into the ultimate web.xml file packaged in the webapp. The developer should never even have to look at the merged version of this file (in the same way that developers using an IDE-type tool that auto-generates web.xml files avoids the need to look at it). Remy Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs
Craig R. McClanahan wrote: Many app servers have private deployment descriptors for extra information, similar to what Remy is proposing -- indeed, one could claim that Tomcat does this already with how we use $CATALINA_HOME/conf/web.xml to set default behavior (well, at least until Costin's recent patch :-). Not sure what patch you're talking about, it should still work. I only added code to deal with the case when the default web.xml is not found ( i.e. no defaults - all config in the app WEB-INF/web.xml ). * IMHO, the deployment descriptor should be viewed as an output of a development process, rather than an input -- just as you package .class files (created from .java files) for all your bean classes. It is straightforward to create an Ant build.xml file (or whatever) that assembles fragments provided by the application developer, plus fragments generated by JSPC, into the ultimate web.xml file packaged in the webapp. The developer should never even have to look at the merged version of this file (in the same way that developers using an IDE-type tool that auto-generates web.xml files avoids the need to look at it). +1 - except that I'm not sure we use the same vocabulary :-) The .WAR and WEB-INF/web.xml are the output of the development process, shiped to the deployer. Deployment descriptor should be part of the deployment process - that includes TOMCAT/webapps/myapp.xml and any other deployment files we may generate or use as part of the deployment. Web.xml is a deployment descriptor too - and is one input in the deployment process. Many servlet containers use a WEB-INF/CONTAINER.xml deployment descriptor, part of the .WAR. IMHO that's a very bad practice - it allows the .war to control the URL or other properties, and this may affect the security in some cases. In tomcat5 - I think we should reduce the use of tomcat-specific deployment and config files, we already have JMX that abstracts the config, and we should try to be consistent ( i.e. use some generic JMX config file ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs
Hi, It is not very convinient or easy to insert the declarations for compiled JSPs into the webapp's web.xml file. It also has the disadvantage of adding a lot of mess in the web.xml, which the user may not like. For that reason, I propose that Tomcat parses a new (optional) XML file, with the same DTD as web.xml, which would contain declarations identical to web.xml, and which would be used for declaring the compiled JSPs. I propose naming that file compiledjsp.xml. An additional advantage is that it would allow Tomcat to precompile webapps as they are deployed (otherwise, nasty XML manipulation is needed to do that, and I think overwriting the originial web.xml during deployment is bad). Maybe someone has a better solution for this problem. Any comments ? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs
Remy, I think it would be nice to have a pre-compilier like JspC used to be. The precompile part of the jsp spec is just not that handy when trying to do builds and having ant tasks pass or fail based on the jsp and compiling jsp pages into servelts is not an option for everyone. John -Original Message- From: Chris Brown [mailto:[EMAIL PROTECTED] Sent: Friday, March 21, 2003 6:43 AM To: Tomcat Developers List Subject: Re: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs Hi Remy, It might be worth COPYING the original web.xml at deployment time, to make a runtime-web.xml, to do what you propose, leaving the original web.xml untouched. This way, you can add the declarations for compiled JSPs, and -- as a bonus -- allow clean modification of things like init-params for servlets, filters, and the context itself. Such modifications could be done in the admin webapp. If the application is redeployed, or at least if web.xml is modified, then a new copy of web.xml can be made, merging in the modifications made to the older (now obsolete) copy, and of course, the declarations for the compiled JSPs. I'm all for deploying applications as simply as possible, letting end-users customise things from nice graphical interfaces without touching configuration files directly. Many less experienced individuals screw up web.xml when attempting to modify stuff, and it implies unpacking WARs, and looking through lots of confusing application structure (where's web.xml? what's xml anyway? why doesn't tomcat start now that I've typed an apostrophie in the servlet's init-param...?) - Chris - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, March 21, 2003 12:05 PM Subject: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs Hi, It is not very convinient or easy to insert the declarations for compiled JSPs into the webapp's web.xml file. It also has the disadvantage of adding a lot of mess in the web.xml, which the user may not like. For that reason, I propose that Tomcat parses a new (optional) XML file, with the same DTD as web.xml, which would contain declarations identical to web.xml, and which would be used for declaring the compiled JSPs. I propose naming that file compiledjsp.xml. An additional advantage is that it would allow Tomcat to precompile webapps as they are deployed (otherwise, nasty XML manipulation is needed to do that, and I think overwriting the originial web.xml during deployment is bad). Maybe someone has a better solution for this problem. Any comments ? Remy - 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: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs
John Trollinger wrote: Remy, I think it would be nice to have a pre-compilier like JspC used to be. The precompile part of the jsp spec is just not that handy when trying to do builds and having ant tasks pass or fail based on the jsp and compiling jsp pages into servelts is not an option for everyone. You can do that by using a script and compile your JSPs indivudually. The community decided webapp mode is meant for webapp compilation. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs
Remy Maucherat wrote: Hi, It is not very convinient or easy to insert the declarations for compiled JSPs into the webapp's web.xml file. It also has the disadvantage of adding a lot of mess in the web.xml, which the user may not like. For that reason, I propose that Tomcat parses a new (optional) XML file, with the same DTD as web.xml, which would contain declarations identical to web.xml, and which would be used for declaring the compiled JSPs. I propose naming that file compiledjsp.xml. An additional advantage is that it would allow Tomcat to precompile webapps as they are deployed (otherwise, nasty XML manipulation is needed to do that, and I think overwriting the originial web.xml during deployment is bad). Maybe someone has a better solution for this problem. Any comments ? I don't think it is a good idea. That won't be standard, and I don't think this is a good reason to extend it. The precompilation should be part of the deployment or pre-deployment step - the developer shouldn't see the modified web.xml. I agree that using ant replace is a hack - the right solution would be to read the XML with DOM, insert the elements in the right place, and save back ( DOM - so we don't loose comments ). Or even read it as a file, and use regexp. No problem if we save the original web.xml in the process. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs
Costin Manolache wrote: Remy Maucherat wrote: Hi, It is not very convinient or easy to insert the declarations for compiled JSPs into the webapp's web.xml file. It also has the disadvantage of adding a lot of mess in the web.xml, which the user may not like. For that reason, I propose that Tomcat parses a new (optional) XML file, with the same DTD as web.xml, which would contain declarations identical to web.xml, and which would be used for declaring the compiled JSPs. I propose naming that file compiledjsp.xml. An additional advantage is that it would allow Tomcat to precompile webapps as they are deployed (otherwise, nasty XML manipulation is needed to do that, and I think overwriting the originial web.xml during deployment is bad). Maybe someone has a better solution for this problem. Any comments ? I don't think it is a good idea. That won't be standard, and I don't think this is a good reason to extend it. The precompilation should be part of the deployment or pre-deployment step - the developer shouldn't see the modified web.xml. I agree that using ant replace is a hack - the right solution would be to read the XML with DOM, insert the elements in the right place, and save back ( DOM - so we don't loose comments ). Or even read it as a file, and use regexp. No problem if we save the original web.xml in the process. I see modifying the original web.xml as a problem. If you don't want the explicit extra XML file, I would instead create a new extra deployment descriptor in the work directory during the deploy procedure. That way, the feature is hidden, but you can't deploy the compiled webapp to another server without modifying the deployment descritptor yourself. An additional note: I think the order of elements is irrelevant with the new spec, so that simplifies things. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, March 21, 2003 3:05 AM Subject: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs Hi, It is not very convinient or easy to insert the declarations for compiled JSPs into the webapp's web.xml file. It also has the disadvantage of adding a lot of mess in the web.xml, which the user may not like. For that reason, I propose that Tomcat parses a new (optional) XML file, with the same DTD as web.xml, which would contain declarations identical to web.xml, and which would be used for declaring the compiled JSPs. I propose naming that file compiledjsp.xml. I think that parsing two web.xml files is plenty. There is no reason to add a third. Also, since it is possible to use Jasper with other containers, adding a non-standard feature like this makes that harder to do. An additional advantage is that it would allow Tomcat to precompile webapps as they are deployed (otherwise, nasty XML manipulation is needed to do that, and I think overwriting the originial web.xml during deployment is bad). I agree with Costin here. It should be easy enough to read web.xml as DOM and save the changes. Maybe someone has a better solution for this problem. Any comments ? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs
Could an alternate hack be to modify JspServlet to allow an additional init parameter which would be the file which contains the mapping of the precompiled jsp's? The config file could just be the web.xml snippet generated by the precompilation process. This way web.xml isn't touched and if Jasper is used in another container, then all is OK? -Tim Bill Barker wrote: I think that parsing two web.xml files is plenty. There is no reason to add a third. Also, since it is possible to use Jasper with other containers, adding a non-standard feature like this makes that harder to do. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs
The main point is to _not_ hack anything, but just use the standard. If you precompile your app - and include jasper-runtime.jar in WEB-INF/lib - the result should work in _any_ container - the precompiled jsps are _just_ regular servlets that happen to use a lib and extend from a base class. That used to work - I haven't tested it recently but it should still work. The result of precompilation must remain a webapplication that is not specific to tomcat ( or worse - to a specific version of tomcat, as would be the case here, I assume such a change won't be backported to 4.0 !). We have a standard way to declare the servlets that result from jsp precompile, we have a standard way to declare the mappings - and I see no good reason to invent another mechanism to do this. I don't like web.xml - and in 2.4 is even worse than it ever was ( with the XML Schema it enters a whole new level of complexity and uglyness). However it is good enough for this use case - and it is the standard. Costin Tim Funk wrote: Could an alternate hack be to modify JspServlet to allow an additional init parameter which would be the file which contains the mapping of the precompiled jsp's? The config file could just be the web.xml snippet generated by the precompilation process. This way web.xml isn't touched and if Jasper is used in another container, then all is OK? -Tim Bill Barker wrote: I think that parsing two web.xml files is plenty. There is no reason to add a third. Also, since it is possible to use Jasper with other containers, adding a non-standard feature like this makes that harder to do. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs
Costin Manolache wrote: The main point is to _not_ hack anything, but just use the standard. If you precompile your app - and include jasper-runtime.jar in WEB-INF/lib - the result should work in _any_ container - the precompiled jsps are _just_ regular servlets that happen to use a lib and extend from a base class. That used to work - I haven't tested it recently but it should still work. The result of precompilation must remain a webapplication that is not specific to tomcat ( or worse - to a specific version of tomcat, as would be the case here, I assume such a change won't be backported to 4.0 !). We have a standard way to declare the servlets that result from jsp precompile, we have a standard way to declare the mappings - and I see no good reason to invent another mechanism to do this. I don't like web.xml - and in 2.4 is even worse than it ever was ( with the XML Schema it enters a whole new level of complexity and uglyness). However it is good enough for this use case - and it is the standard. Hey, I think I like the longer version better. During deploy, we do: - hack web.xml - copy jasper-runtime.jar to /WEB-INF/lib So we can keep jasper-compiler.jar in /server/lib ? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs
Remy Maucherat wrote: I agree that using ant replace is a hack - the right solution would be to read the XML with DOM, insert the elements in the right place, and save back ( DOM - so we don't loose comments ). Or even read it as a file, and use regexp. No problem if we save the original web.xml in the process. I see modifying the original web.xml as a problem. Not sure what you mean by original web.xml. From the point of view of tomcat, the original is the modified web.xml which includes declarations for all jsps. What you mean by original - i.e. the incomplete web.xml that relied on tomcat-specific JspServlet to function - is a development artifact. If you don't want the explicit extra XML file, I would instead create a new extra deployment descriptor in the work directory during the deploy procedure. That way, the feature is hidden, but you can't deploy the compiled webapp to another server without modifying the deployment descritptor yourself. An additional note: I think the order of elements is irrelevant with the new spec, so that simplifies things. It is not in the old spec - and it is a good practice to maintain backward compatibility, i.e. people will probably develop apps that run in 2.3 and 2.4 containers for a while. Not to mention that the order is irrelevant only in the 2.4 web.xml which also uses schema. I plan to stick with the 2.3 descriptor for a while, xml schema is one of the worst technologies that I know. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs
Remy Maucherat wrote: Costin Manolache wrote: The main point is to _not_ hack anything, but just use the standard. If you precompile your app - and include jasper-runtime.jar in WEB-INF/lib - the result should work in _any_ container - the precompiled jsps are _just_ regular servlets that happen to use a lib and extend from a base class. That used to work - I haven't tested it recently but it should still work. The result of precompilation must remain a webapplication that is not specific to tomcat ( or worse - to a specific version of tomcat, as would be the case here, I assume such a change won't be backported to 4.0 !). We have a standard way to declare the servlets that result from jsp precompile, we have a standard way to declare the mappings - and I see no good reason to invent another mechanism to do this. I don't like web.xml - and in 2.4 is even worse than it ever was ( with the XML Schema it enters a whole new level of complexity and uglyness). However it is good enough for this use case - and it is the standard. Hey, I think I like the longer version better. During deploy, we do: - hack web.xml - copy jasper-runtime.jar to /WEB-INF/lib So we can keep jasper-compiler.jar in /server/lib ? I don't know. jasper-compiler is needed only to support development use cases, it obviously shouldn't be used on production servers. We are mixing 2 very different use cases here: - development - you don't need to precompile and jasper-compiler is neede - production - it's crazy to not precompile, and jasper-compiler serves no purpose ( and it may be safer to not have it ). A javac compiler is also not need, and probably a lot of other jars and features that are not used can be disabled. If we figure out how to .ser the web.xml and all the other descriptors - to optimize startup time - you can even run the production server without using an xml parser. IMO precompilation happens _before_ deploy - it is part of the build process, and results in a standard .war file that can be deployed in any container. The deploy stage can generate tomcat-specific files ( like .ser, expand jars from the .war, move files around or distribute them in a cluster, etc). We could have a step that precompiles and JSP - in case the original .war didn't precompile, and in this case we can generate whatever file format we want ( preferably .ser - it's much faster ). However the important case for jspc is the previous one ( i.e. precompile the app before you ship, as part of the build process ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs
Costin Manolache wrote: Remy Maucherat wrote: I don't know. jasper-compiler is needed only to support development use cases, it obviously shouldn't be used on production servers. We are mixing 2 very different use cases here: - development - you don't need to precompile and jasper-compiler is neede - production - it's crazy to not precompile, and jasper-compiler serves no purpose ( and it may be safer to not have it ). A javac compiler is also not need, and probably a lot of other jars and features that are not used can be disabled. If we figure out how to .ser the web.xml and all the other descriptors - to optimize startup time - you can even run the production server without using an xml parser. IMO precompilation happens _before_ deploy - it is part of the build process, and results in a standard .war file that can be deployed in any container. The deploy stage can generate tomcat-specific files ( like .ser, expand jars from the .war, move files around or distribute them in a cluster, etc). We could have a step that precompiles and JSP - in case the original .war didn't precompile, and in this case we can generate whatever file format we want ( preferably .ser - it's much faster ). However the important case for jspc is the previous one ( i.e. precompile the app before you ship, as part of the build process ). Ok, so the deployer shouldn't do anything in addition to what it does right now, then ? That's fine by me, it works good enough, and I've documented how to use the Ant script :) I think I should add copying jasper-runtime.jar to /WEB-INF/lib, then. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Refactored mapper
On Thu, 2002-08-15 at 15:37, Remy Maucherat wrote: [...] Yes, but welcome files for non physical resources cannot be implemented (since you have no way of asking a servlet if it can or cannot process a resource). I'll implement something which works and which is very close to what the spec requires. Again, I have sent many messages to the spec leads about this issue without any result, so I give up ... I don't completely understand the issue(s), but consider this, servlet-mapping servlet-nameBooServlet/servlet-name url-pattern/*.boo/url-pattern /servlet-mapping welcome-file-list welcome-fileindex.jsp/welcome-file welcome-fileindex.boo/welcome-file /welcome-file-list Is the problem that by the time the 'welcome file logic' gets a chance to handle the request, the logic that would have been able to pass this request off to a servlet is way too far up the call stack?It is almost like the DefaultServlet would need to open a connection to the loopback and check each welcome file URI to find one that gets to something useful (this is just a mental exercise, don't get excited I wouldn't think of implementing this.) Cheers, -bob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Refactored mapper
Bob Herrmann wrote: On Thu, 2002-08-15 at 15:37, Remy Maucherat wrote: [...] Yes, but welcome files for non physical resources cannot be implemented (since you have no way of asking a servlet if it can or cannot process a resource). I'll implement something which works and which is very close to what the spec requires. Again, I have sent many messages to the spec leads about this issue without any result, so I give up ... I don't completely understand the issue(s), but consider this, servlet-mapping servlet-nameBooServlet/servlet-name url-pattern/*.boo/url-pattern /servlet-mapping welcome-file-list welcome-fileindex.jsp/welcome-file welcome-fileindex.boo/welcome-file /welcome-file-list Is the problem that by the time the 'welcome file logic' gets a chance to handle the request, the logic that would have been able to pass this request off to a servlet is way too far up the call stack?It is almost like the DefaultServlet would need to open a connection to the loopback and check each welcome file URI to find one that gets to something useful (this is just a mental exercise, don't get excited I wouldn't think of implementing this.) It means that in that case, no matter what the URL is (as long as it ends with a '/'), it will end up to your_url/index.boo, which isn't good since it may be completely stupid (and your other entries in the welcome file list would get ignored), unless you have a way to verify that it is intelligent to forward to index.boo (it's easy to do for physical files, as you can check to see if it exists, but you can't do it in the general case). So it's possible to implement what is in the spec for physical files *or* for exact servlet mappings (where you consider that if a servlet is mapped to an exact URL without wildcards, and that you match that URL with a welcome file, you can assume it's a good idea to redirect). However, it's not possible for non physical resources (which is a new requirement). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Refactored mapper
On Thu, 2002-08-15 at 18:38, Patrick Luby wrote: Remy and Costin, I found the following draft wording that is being considered for the Servlet 2.4 spec. The exact wording may change, but the context should stay the same. Are there any unimplementable pieces in this proposed wording: The wording in the 4th paragraph in section 9.10 of the Servlet 2.4 spec may change to: The web server must append each welcome file in the order specified in the deployment descriptor to the partial request and check whether a [static] resource [or servlet] in the WAR is mapped to that request URI. The web container must send the request to the first resource in the WAR that matches [in the order of 1. a static resource, 2. a servlet that matches exactly, 3. a servlet that matches according to the path mapping rule]. Patrick Humm... how does this help? First, note that the extension mapping is not mentioned, so things like *.jsp, *.boo are not relevant to welcome files. Consider this, servlet-mapping servlet-nameBooServlet/servlet-name url-pattern/boo/*/url-pattern /servlet-mapping servlet-mapping servlet-nameFooServlet/servlet-name url-pattern/boo/foo/*/url-pattern /servlet-mapping servlet-mapping servlet-nameExServlet/servlet-name url-patternexactMatch/url-pattern /servlet-mapping welcome-file-list welcome-fileindex.html/welcome-file welcome-file/boo/AlwaysGoesHere/welcome-file welcome-file/boo/foo/NeverGetsHere/welcome-file welcome-fileexactMatch/welcome-file welcome-fileindex.jsp/welcome-file !-- how come extension mapping is ok here? or is it not ok. -- /welcome-file-list Somewhat confused (typical), Bob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Refactored mapper
Bob Herrmann wrote: On Thu, 2002-08-15 at 18:38, Patrick Luby wrote: Remy and Costin, I found the following draft wording that is being considered for the Servlet 2.4 spec. The exact wording may change, but the context should stay the same. Are there any unimplementable pieces in this proposed wording: The wording in the 4th paragraph in section 9.10 of the Servlet 2.4 spec may change to: The web server must append each welcome file in the order specified in the deployment descriptor to the partial request and check whether a [static] resource [or servlet] in the WAR is mapped to that request URI. The web container must send the request to the first resource in the WAR that matches [in the order of 1. a static resource, 2. a servlet that matches exactly, 3. a servlet that matches according to the path mapping rule]. Patrick Humm... how does this help? First, note that the extension mapping is not mentioned, so things like *.jsp, *.boo are not relevant to welcome files. Consider this, servlet-mapping servlet-nameBooServlet/servlet-name url-pattern/boo/*/url-pattern /servlet-mapping servlet-mapping servlet-nameFooServlet/servlet-name url-pattern/boo/foo/*/url-pattern /servlet-mapping servlet-mapping servlet-nameExServlet/servlet-name url-patternexactMatch/url-pattern /servlet-mapping welcome-file-list welcome-fileindex.html/welcome-file welcome-file/boo/AlwaysGoesHere/welcome-file welcome-file/boo/foo/NeverGetsHere/welcome-file welcome-fileexactMatch/welcome-file welcome-fileindex.jsp/welcome-file !-- how come extension mapping is ok here? or is it not ok. -- /welcome-file-list Somewhat confused (typical), And imagine what users will say ;-) Basically, I read it as not using extension mapping for non physical resources, but only for physical resources (otherwise the default home page of Tomcat when you set it up won't work, which is a problem IMO ;-)). It now looks doable with the standalone Tomcat. It may still be unimplementable through Apache, though. My wish would be that only physical resources can be used as welcome files, so that the spec is implementable through a native webserver. (Quite frankly, the use case for the rest is very limited, and very confusing; plus it would impose a complex wording in the spec - still not right in that version) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Refactored mapper
Remy, Remy Maucherat wrote: It now looks doable with the standalone Tomcat. It may still be unimplementable through Apache, though. My wish would be that only physical resources can be used as welcome files, so that the spec is implementable through a native webserver. (Quite frankly, the use case for the rest is very limited, and very confusing; plus it would impose a complex wording in the spec - still not right in that version) I really don't like this spec change either. After carefully reading the revised wording, it still seems that spec is saying if I can't find any of the listed static welcome files, start looking for anything that can serve up a response. OK, maybe I am being overly dramatic, but it seems that the spec is trying to apply complex pattern matching rules to when the user requests the / resource and the webapp is missing all of the static welcome file resources. As far as I can tell, the only time the servlet mapping gets used is when the webapp has, for example /index.html as a welcome file and then then the webapp developer forget to put a index.html file in the webapp. Am I missing some bigger and better feature? Or is this spec trying to solve a problem that can be easily handled with the existing welcome file behavior? Patrick -- Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Refactored mapper
On Fri, 16 Aug 2002, Remy Maucherat wrote: The wording in the 4th paragraph in section 9.10 of the Servlet 2.4 spec may change to: The web server must append each welcome file in the order specified in the deployment descriptor to the partial request and check whether a [static] resource [or servlet] in the WAR is mapped to that request URI. The web container must send the request to the first resource in the WAR that matches [in the order of 1. a static resource, 2. a servlet that matches exactly, 3. a servlet that matches according to the path mapping rule]. Patrick Humm... how does this help? First, note that the extension mapping is not mentioned, so things like *.jsp, *.boo are not relevant to welcome files. Very good point Bob. The new wording brakes other pieces. My wish would be that only physical resources can be used as welcome files, so that the spec is implementable through a native webserver. (Quite frankly, the use case for the rest is very limited, and very confusing; plus it would impose a complex wording in the spec - still not right in that version) +1 My view of the correct behavior ( and others have spent more time with that than me, and they should speak ): - first check for static files. If one is found, that'll do it. That's what the server does - if the file is present. Normal extension mapping will be used on the file. - check for exact or prefix mappings. That will cover precompiled JSPs. - don't check for extension mapping if no physical file is present. There is no way to know if an extension-mapped resource actually exist - so any way you turn it, it can't be used for welcome files without some extra info. The file existence can do that. Keep in mind that extension mapping is a fundamental concept from web servers that was screwed in the servlet spec - no existing server does extension mapping without a physical file. PathInfo is just another victim of 'redefining' and 'extending' a de-facto standard. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Refactored mapper
On Fri, 16 Aug 2002, Patrick Luby wrote: I really don't like this spec change either. After carefully reading the revised wording, it still seems that spec is saying if I can't find any of the listed static welcome files, start looking for anything that can serve up a response. OK, maybe I am being overly dramatic, but it seems that the spec is trying to apply complex pattern matching rules to when the user requests the / resource and the webapp is missing all of the static welcome file resources. As far as I can tell, the only time the servlet mapping gets used is when the webapp has, for example /index.html as a welcome file and then then the webapp developer forget to put a index.html file in the webapp. Or index.jsp ? If index.jsp has been precompiled - you need path mapping. What if you have struts and index.do ? With no real file in the dir, but some definition in an xml file ? Am I missing some bigger and better feature? Or is this spec trying to solve a problem that can be easily handled with the existing welcome file behavior? There is no 'existing welcome file behavior' in the servlet spec. The spec has allways been broken, and people just ignored it and implemented what the web servers are doing and users expect. The root of the problem is the extension mapping definition that can't check for existence of the resource ( since the resource is no longer there ). You either exclude extension mapping, or allow only 'normal' extension mapping ( the one used by web servers ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[5.0] [PROPOSAL] Refactored mapper
Hi, I have been hinting at rewriting the main Catalina mapper for Tomcat 5. The proposal is designed to improve performance, avoid generating uneeded garbage String objects, and optimize the welcome files processing. The following changes are proposed: - Expose the decoded URI MessageBytes in the main Request interface of Catalina, so that the mapper doesn't have to pay the b2c cost - Implement the new mappers as a separate set of classes in j-t-c/util/../mapper The new mappers will use exclusively bytes to match contexts/servlets and will rewrite the original URIs to handle welcome files without sending a redirect back to the client (in most cases). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[5.0] [PROPOSAL] Validation/NamespaceAware
Hi, based on the mailling list feedback, I would like to propose the following solution for the XML Parser DTD/Schema validation/namespace aware problems: - Add the following attributes in server.xml under the HOST element: xmlValidation=false xmlNamespaceAware=false and set them equal to false by default. This way, peoples will be able to turn it on only if they need it, using the AdminTool or directly in the server.xml file. It will still let the door open for: - have a separate validation program that can be run on a webapp _before_ it is deployed on tomcat (Costin) - keeping validation available when required (Steve) - etc. Thanks, -- Jeanfrancois -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Validation/NamespaceAware
Jean-François, I would vote +1 as long as these two HOST attributes are optional attributes. In other words, if they are missing from server.xml, both default to false. I think that is what you are proposing but I just wanted to make sure. Patrick Jean-francois Arcand wrote: Hi, based on the mailling list feedback, I would like to propose the following solution for the XML Parser DTD/Schema validation/namespace aware problems: - Add the following attributes in server.xml under the HOST element: xmlValidation=false xmlNamespaceAware=false and set them equal to false by default. This way, peoples will be able to turn it on only if they need it, using the AdminTool or directly in the server.xml file. It will still let the door open for: - have a separate validation program that can be run on a webapp _before_ it is deployed on tomcat (Costin) - keeping validation available when required (Steve) - etc. Thanks, -- Jeanfrancois -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- _ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Refactored mapper
Bob Herrmann wrote: On Thu, 2002-08-15 at 13:23, Remy Maucherat wrote: Hi, I have been hinting at rewriting the main Catalina mapper for Tomcat 5. The proposal is designed to improve performance, avoid generating uneeded garbage String objects, and optimize the welcome files processing. FYI, The 2.4 spec seems to allow servlets to handle welcome file processing too. Not sure I understand this completely, but I am looking into it (with an eye towards implementing something to satisfy the 2.4 Spec's servlets as providers of welcome files. Perhaps welcome page would be better than 'welcome file.', but I digress) Yes, but welcome files for non physical resources cannot be implemented (since you have no way of asking a servlet if it can or cannot process a resource). I'll implement something which works and which is very close to what the spec requires. Again, I have sent many messages to the spec leads about this issue without any result, so I give up ... Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Validation/NamespaceAware
Jean-francois Arcand wrote: Hi, based on the mailling list feedback, I would like to propose the following solution for the XML Parser DTD/Schema validation/namespace aware problems: - Add the following attributes in server.xml under the HOST element: xmlValidation=false xmlNamespaceAware=false and set them equal to false by default. This way, peoples will be able to turn it on only if they need it, using the AdminTool or directly in the server.xml file. Awesome :) We should also add those attributes to the default server.xml (in addition to adding checkboxes on the Host page in the admin) so that people know that they exist. It will still let the door open for: - have a separate validation program that can be run on a webapp _before_ it is deployed on tomcat (Costin) - keeping validation available when required (Steve) - etc. - Doing a TC 3.3 style trick along with background deployment I think that one looks cool :) Thanks a lot, Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Refactored mapper
On Thu, 15 Aug 2002, Remy Maucherat wrote: Yes, but welcome files for non physical resources cannot be implemented (since you have no way of asking a servlet if it can or cannot process a resource). I'll implement something which works and which is very close to what the spec requires. Again, I have sent many messages to the spec leads about this issue without any result, so I give up ... The current specification is not implementable for Apache ( or any other web server ) - and it breaks every pattern that was used in the web. I don't know if we have any representative in the expert group or what's the procedure that apache follows in voting for JCP specs - but if this is not resolved I'll do my best to find out. I'm also curious to who is representing apache ( if any ) in the JSP spec - I'm still strugling to understand how the TLD stuff happened and nobody noticed or complained in any way - the whole 'config in web.xml' model is now screwed, with any file ( including jars ) potentially storing config for web applications. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Validation/NamespaceAware
Big +1 ! We can have a small ant-based script that can validate a webapp - find all the XMLs and TLDs and run schema and DTD validation on it. Another nice thing we could do - if someone has the time - is adding 'Serializable' to Context and all other config objects and saving a snapshot. Then reuse the dependency checking from jasper and check if any of the files changed ( web.xml, jars, tlds ). On the first load or on change we could validate - and for the rest just load the .ser object. But it is not easy - turning validation off by default until we have a way to avoid duplicated validation is a good solution. Costin On Thu, 15 Aug 2002, Jean-francois Arcand wrote: Hi, based on the mailling list feedback, I would like to propose the following solution for the XML Parser DTD/Schema validation/namespace aware problems: - Add the following attributes in server.xml under the HOST element: xmlValidation=false xmlNamespaceAware=false and set them equal to false by default. This way, peoples will be able to turn it on only if they need it, using the AdminTool or directly in the server.xml file. It will still let the door open for: - have a separate validation program that can be run on a webapp _before_ it is deployed on tomcat (Costin) - keeping validation available when required (Steve) - etc. Thanks, -- Jeanfrancois -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Refactored mapper
[EMAIL PROTECTED] wrote: The current specification is not implementable for Apache ( or any other web server ) - and it breaks every pattern that was used in the web. I don't know if we have any representative in the expert group or what's the procedure that apache follows in voting for JCP specs - but if this is not resolved I'll do my best to find out. I have heard that Pier is in the Expert Group. But I could be wrong. I think the Servlet 2.4 spec is going Public Final Draft this month (not sure exactly when), but you can e-mail the expert group directly at: [EMAIL PROTECTED] Also, the latest draft of the spec is at: http://www.jcp.org/jsr/detail/154.jsp Patrick -- _ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Refactored mapper
Remy and Costin, I found the following draft wording that is being considered for the Servlet 2.4 spec. The exact wording may change, but the context should stay the same. Are there any unimplementable pieces in this proposed wording: The wording in the 4th paragraph in section 9.10 of the Servlet 2.4 spec may change to: The web server must append each welcome file in the order specified in the deployment descriptor to the partial request and check whether a [static] resource [or servlet] in the WAR is mapped to that request URI. The web container must send the request to the first resource in the WAR that matches [in the order of 1. a static resource, 2. a servlet that matches exactly, 3. a servlet that matches according to the path mapping rule]. Patrick [EMAIL PROTECTED] wrote: On Thu, 15 Aug 2002, Remy Maucherat wrote: Yes, but welcome files for non physical resources cannot be implemented (since you have no way of asking a servlet if it can or cannot process a resource). I'll implement something which works and which is very close to what t spec requires. Again, I have sent many messages to the spec leads about this issue without any result, so I give up ... The current specification is not implementable for Apache ( or any other web server ) - and it breaks every pattern that was used in the web. I don't know if we have any representative in the expert group or what's the procedure that apache follows in voting for JCP specs - but if this is not resolved I'll do my best to find out. I'm also curious to who is representing apache ( if any ) in the JSP spec - I'm still strugling to understand how the TLD stuff happened and nobody noticed or complained in any way - the whole 'config in web.xml' model is now screwed, with any file ( including jars ) potentially storing config for web applications. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- _ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Refactored mapper
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, August 15, 2002 10:23 AM Subject: [5.0] [PROPOSAL] Refactored mapper Hi, I have been hinting at rewriting the main Catalina mapper for Tomcat 5. The proposal is designed to improve performance, avoid generating uneeded garbage String objects, and optimize the welcome files processing. The following changes are proposed: - Expose the decoded URI MessageBytes in the main Request interface of Catalina, so that the mapper doesn't have to pay the b2c cost - Implement the new mappers as a separate set of classes in j-t-c/util/../mapper I'm hoping that this doesn't imply a dependency in j-t-c/util on o.a.c.Mapper. It's mostly the TC3.3 build that I'm worried about. The new mappers will use exclusively bytes to match contexts/servlets and will rewrite the original URIs to handle welcome files without sending a redirect back to the client (in most cases). +1 (i.e. I'm willing to help out, if you want). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Apache Tomcat 5.0 Proposal
Sorry for the late vote. I've been on vacation for last two weeks. But for the record, you have my +1. Thanks, Amy Remy Maucherat wrote: After trying to address the concerns raised by the proposal draft, I would like to call for a vote on it, now that the discussions have died down. ballot [ ] +1 I support the proposal, and will help implement it [ ] +0 I support the proposal [ ] -0 I do not support the proposal [ ] -1 I am against the proposal being implemented, because: /ballot The vote will run for one full week until July 9th. Users and other contributors may vote, but only committers have binding votes. Remy Proposal for Apache Tomcat 5.0 == Introduction: This document is a proposal for the next major release of Apache Tomcat, Apache Tomcat 5.0. Apache Tomcat 5.0 will improve on the Apache Tomcat 3.3 and Apache Tomcat 4.1 architectures, by making them simpler, more flexible and more modular, while at the same time adding support for the new Servlet API 2.4 and JSP 2.0 specifications, currently under development by the Java Community Process. The major goals for Apache Tomcat 5.0 are to: - improve scalability, reliability and performance over previous versions - have simpler/cleaner code, so more people can get involved - merge of the various ideas in 3.x and 4.x - get the community togheter - provide maximum modularity and compliance to the standards - make it easy to continue to maintain the existing codebases Testing will occur to make sure the stated robustness and performance goals are met by Tomcat 5.0. This proposal also tries to take advantage of the lessons learned while optimizing and maintaining Tomcat. Note: The development of Apache Tomcat 4.1.x will continue in parallel to the implementation of this proposal. General architecture: An improved version of Coyote 1.0, called Coyote 2.0, will be used as the Apache Tomcat 5.0 core. Coyote is currently considered a connector for Tomcat 3.3 and 4.x, and is under development in the jakarta-tomcat-connectors repository. Coyote 1.0 includes: - Protocol handlers for AJP 1.3, HTTP/1.1 and JNI - Adapter for Tomcat 3.3 - Adapter for Tomcat 4.x Extensibility capabilities will be added to Coyote, as well as JMX management features, and if possible, addional protocol handlers (like WARP 1.0). The Servlet API 2.4 specification will be implemented in a new version of Catalina, called Catalina 2.0. A new version of the Coyote adapter will be written for it if mandated by API changes. Components which duplicate functionality provided by Coyote will be removed, including the old connectors. On the JSP side, Jasper 2 will be updated to support JSP 2.0, will be renamed to Jasper 3, and is the proposed Jasper codebase. It provides many improvements over Jasper 1 included in Tomcat 3.x and Tomcat 4.0.x, including good tag library handling, and near zero overhead when compared to an equivalent hand coded servlet. Jasper 2 will also undergo additional optimizations. Apache Tomcat 5.0 will be made by default of the following components: - Coyote 2.0 - core - Catalina 2.0 - Servlet API 2.4 implementation - Jasper 2 - JSP 2.0 implementation Many other configurations are also possible, and it is expected that advanced users take advantage of it to make Tomcat better suit their needs. It is also possible that new special purpose components, like a bare bones Servlet API implementation, be developed to address the embedded market. Due to the scope of this work, this initial Proposal only plans the implementation and support of the default configuration described above. Changes over Apache Tomcat 4.1.x: A lot of the Apache Tomcat 5.0 code will be based on the Apache Tomcat 4.1.x codebase. Tomcat 5.0 will also be able to use the Tomcat 3.3.x code. The following major changes and additions are proposed to the current Apche Tomcat code, and related dependencies: A) Removal of the org.apache.catalina.connector.* This package is currently deprecated in Tomcat 4.1 because of its implementation inefficiencies, and general bad design. It is thus proposed that it is removed in Tomcat 5.0. B) Addition of new loader code for the commons-daemon subproject It is proposed that, in an attempt to solve the problems with using startup scripts, as well as adding additional features oriented towards reliability (including the capability to restart Tomcat automatically should the JVM crashes or experience memory management related problems), the launcher code which will be developed as part of commons-daemon be adopted. This code will be based in part on the launcher code used for the Sun Web Services Pack, and in part on the Wrapper project code (available at
Re: [VOTE] Apache Tomcat 5.0 Proposal
Probably a little late: [X] +1 I support the proposal, and will help implement it [ ] +0 I support the proposal [ ] -0 I do not support the proposal [ ] -1 I am against the proposal being implemented, because: Actually, I'm probably closer to a +0 for the next few weeks, slowly transitioning back into being able to help implement after that. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tomcat 5.0 Proposal
The final count for the vote is: +1s: 12 +0s: 2 The Tomcat 5.0 Proposal is now offcially adopted. I suggest that the emails related to 5.0 buisness be prefixed with [5.0]. I will post an email about the organization of the various branches and new repositories soon. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
5.0 Proposal voting status
There is currently: - 12 binding +1s - 2 +0s For those who didn't vote yet, the voting will end today. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Apache Tomcat 5.0 Proposal
+1 Remy Maucherat wrote: After trying to address the concerns raised by the proposal draft, I would like to call for a vote on it, now that the discussions have died down. ballot [ ] +1 I support the proposal, and will help implement it [ ] +0 I support the proposal [ ] -0 I do not support the proposal [ ] -1 I am against the proposal being implemented, because: /ballot The vote will run for one full week until July 9th. Users and other contributors may vote, but only committers have binding votes. Remy Proposal for Apache Tomcat 5.0 == Introduction: This document is a proposal for the next major release of Apache Tomcat, Apache Tomcat 5.0. Apache Tomcat 5.0 will improve on the Apache Tomcat 3.3 and Apache Tomcat 4.1 architectures, by making them simpler, more flexible and more modular, while at the same time adding support for the new Servlet API 2.4 and JSP 2.0 specifications, currently under development by the Java Community Process. The major goals for Apache Tomcat 5.0 are to: - improve scalability, reliability and performance over previous versions - have simpler/cleaner code, so more people can get involved - merge of the various ideas in 3.x and 4.x - get the community togheter - provide maximum modularity and compliance to the standards - make it easy to continue to maintain the existing codebases Testing will occur to make sure the stated robustness and performance goals are met by Tomcat 5.0. This proposal also tries to take advantage of the lessons learned while optimizing and maintaining Tomcat. Note: The development of Apache Tomcat 4.1.x will continue in parallel to the implementation of this proposal. General architecture: An improved version of Coyote 1.0, called Coyote 2.0, will be used as the Apache Tomcat 5.0 core. Coyote is currently considered a connector for Tomcat 3.3 and 4.x, and is under development in the jakarta-tomcat-connectors repository. Coyote 1.0 includes: - Protocol handlers for AJP 1.3, HTTP/1.1 and JNI - Adapter for Tomcat 3.3 - Adapter for Tomcat 4.x Extensibility capabilities will be added to Coyote, as well as JMX management features, and if possible, addional protocol handlers (like WARP 1.0). The Servlet API 2.4 specification will be implemented in a new version of Catalina, called Catalina 2.0. A new version of the Coyote adapter will be written for it if mandated by API changes. Components which duplicate functionality provided by Coyote will be removed, including the old connectors. On the JSP side, Jasper 2 will be updated to support JSP 2.0, will be renamed to Jasper 3, and is the proposed Jasper codebase. It provides many improvements over Jasper 1 included in Tomcat 3.x and Tomcat 4.0.x, including good tag library handling, and near zero overhead when compared to an equivalent hand coded servlet. Jasper 2 will also undergo additional optimizations. Apache Tomcat 5.0 will be made by default of the following components: - Coyote 2.0 - core - Catalina 2.0 - Servlet API 2.4 implementation - Jasper 2 - JSP 2.0 implementation Many other configurations are also possible, and it is expected that advanced users take advantage of it to make Tomcat better suit their needs. It is also possible that new special purpose components, like a bare bones Servlet API implementation, be developed to address the embedded market. Due to the scope of this work, this initial Proposal only plans the implementation and support of the default configuration described above. Changes over Apache Tomcat 4.1.x: A lot of the Apache Tomcat 5.0 code will be based on the Apache Tomcat 4.1.x codebase. Tomcat 5.0 will also be able to use the Tomcat 3.3.x code. The following major changes and additions are proposed to the current Apche Tomcat code, and related dependencies: A) Removal of the org.apache.catalina.connector.* This package is currently deprecated in Tomcat 4.1 because of its implementation inefficiencies, and general bad design. It is thus proposed that it is removed in Tomcat 5.0. B) Addition of new loader code for the commons-daemon subproject It is proposed that, in an attempt to solve the problems with using startup scripts, as well as adding additional features oriented towards reliability (including the capability to restart Tomcat automatically should the JVM crashes or experience memory management related problems), the launcher code which will be developed as part of commons-daemon be adopted. This code will be based in part on the launcher code used for the Sun Web Services Pack, and in part on the Wrapper project code (available at SF.net), if we manage to come to an agreement
Re: [VOTE] Apache Tomcat 5.0 Proposal
As long as the interfaces don't change too much (especially, Container and Component, all the rest I don't care). We started out process of stripping out for good all the stuff distributed with TC4x, working on some new startup classes and so on (and looking over at the excellent work made by MinTC, and what Scarab is doing on that front)... If you want to be flamed heavily check out http://dev.betaversion.org/ Welcome to Jerry ;) BTW, emulation is allways great till it didn't turn in flam wars. I'll try to track both TC 5.0 and Jerry -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Apache Tomcat 5.0 Proposal
+1. I'll populate jasper2 and servlet-api with initial changes for JSP2.0 support. Date: Tue, 02 Jul 2002 16:57:20 -0700 From: Remy Maucherat [EMAIL PROTECTED] Subject: [VOTE] Apache Tomcat 5.0 Proposal To: Tomcat Developers List [EMAIL PROTECTED] After trying to address the concerns raised by the proposal draft, I would like to call for a vote on it, now that the discussions have died down. ballot [ ] +1 I support the proposal, and will help implement it [ ] +0 I support the proposal [ ] -0 I do not support the proposal [ ] -1 I am against the proposal being implemented, because: /ballot The vote will run for one full week until July 9th. Users and other contributors may vote, but only committers have binding votes. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Apache Tomcat 5.0 Proposal
On Tue, 2 Jul 2002, Remy Maucherat wrote: After trying to address the concerns raised by the proposal draft, I would like to call for a vote on it, now that the discussions have died down. ballot [X] +1 I support the proposal, and will help implement it [ ] +0 I support the proposal [ ] -0 I do not support the proposal [ ] -1 I am against the proposal being implemented, because: /ballot The vote will run for one full week until July 9th. Users and other contributors may vote, but only committers have binding votes. Remy -- Denis Benoit [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Apache Tomcat 5.0 Proposal
Remy Maucherat [EMAIL PROTECTED] wrote: ballot [ ] +1 I support the proposal, and will help implement it [X] +0 I support the proposal [ ] -0 I do not support the proposal [ ] -1 I am against the proposal being implemented, because: /ballot As long as the interfaces don't change too much (especially, Container and Component, all the rest I don't care). We started out process of stripping out for good all the stuff distributed with TC4x, working on some new startup classes and so on (and looking over at the excellent work made by MinTC, and what Scarab is doing on that front)... If you want to be flamed heavily check out http://dev.betaversion.org/ Pier -- [Perl] combines all the worst aspects of C and Lisp: a billion of different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Apache Tomcat 5.0 Proposal
On Tue, 2002-07-02 at 19:57, Remy Maucherat wrote: After trying to address the concerns raised by the proposal draft, I would like to call for a vote on it, now that the discussions have died down. ballot [X] +1 I support the proposal, and will help implement it [ ] +0 I support the proposal [ ] -0 I do not support the proposal [ ] -1 I am against the proposal being implemented, because: Willing to help in any way I can. Cheers, -bob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] Apache Tomcat 5.0 Proposal
ballot [X] +1 I support the proposal, and will help implement it [ ] +0 I support the proposal [ ] -0 I do not support the proposal [ ] -1 I am against the proposal being implemented, because: /ballot -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] Apache Tomcat 5.0 Proposal
ballot [X] +1 I support the proposal, and will help implement it [ ] +0 I support the proposal [ ] -0 I do not support the proposal [ ] -1 I am against the proposal being implemented, because: /ballot MT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] Apache Tomcat 5.0 Proposal
-Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 02, 2002 7:57 PM To: Tomcat Developers List Subject: [VOTE] Apache Tomcat 5.0 Proposal After trying to address the concerns raised by the proposal draft, I would like to call for a vote on it, now that the discussions have died down. ballot [x] +1 I support the proposal, and will help implement it [ ] +0 I support the proposal [ ] -0 I do not support the proposal [ ] -1 I am against the proposal being implemented, because: /ballot The vote will run for one full week until July 9th. Users and other contributors may vote, but only committers have binding votes. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] Apache Tomcat 5.0 Proposal
ballot [x] +1 I support the proposal, and will help implement it [ ] +0 I support the proposal [ ] -0 I do not support the proposal [ ] -1 I am against the proposal being implemented, because: /ballot -Shailendra -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] Apache Tomcat 5.0 Proposal
+1 Saludos , Ignacio J. Ortega -Mensaje original- De: Remy Maucherat [mailto:[EMAIL PROTECTED]] Enviado el: 3 de julio de 2002 1:57 Para: Tomcat Developers List Asunto: [VOTE] Apache Tomcat 5.0 Proposal After trying to address the concerns raised by the proposal draft, I would like to call for a vote on it, now that the discussions have died down. ballot [ ] +1 I support the proposal, and will help implement it [ ] +0 I support the proposal [ ] -0 I do not support the proposal [ ] -1 I am against the proposal being implemented, because: /ballot The vote will run for one full week until July 9th. Users and other contributors may vote, but only committers have binding votes. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Apache Tomcat 5.0 Proposal
+1 on proposal. I have a lot of interested in coding and/or writing documentation for Tomcat 5.0. I'll look for opportunities to jump in, but if someone has any Tomcat 4.x or Tomcat 5 projects awaiting a coder or a tech. writer, please do let me know. On Tuesday, July 2, 2002, at 05:57 PM, Remy Maucherat wrote: After trying to address the concerns raised by the proposal draft, I would like to call for a vote on it, now that the discussions have died down. ballot [ ] +1 I support the proposal, and will help implement it [ ] +0 I support the proposal [ ] -0 I do not support the proposal [ ] -1 I am against the proposal being implemented, because: /ballot The vote will run for one full week until July 9th. Users and other contributors may vote, but only committers have binding votes. Remy Proposal for Apache Tomcat 5.0 == Introduction: This document is a proposal for the next major release of Apache Tomcat, Apache Tomcat 5.0. Apache Tomcat 5.0 will improve on the Apache Tomcat 3.3 and Apache Tomcat 4.1 architectures, by making them simpler, more flexible and more modular, while at the same time adding support for the new Servlet API 2.4 and JSP 2.0 specifications, currently under development by the Java Community Process. The major goals for Apache Tomcat 5.0 are to: - improve scalability, reliability and performance over previous versions - have simpler/cleaner code, so more people can get involved - merge of the various ideas in 3.x and 4.x - get the community togheter - provide maximum modularity and compliance to the standards - make it easy to continue to maintain the existing codebases Testing will occur to make sure the stated robustness and performance goals are met by Tomcat 5.0. This proposal also tries to take advantage of the lessons learned while optimizing and maintaining Tomcat. Note: The development of Apache Tomcat 4.1.x will continue in parallel to the implementation of this proposal. General architecture: An improved version of Coyote 1.0, called Coyote 2.0, will be used as the Apache Tomcat 5.0 core. Coyote is currently considered a connector for Tomcat 3.3 and 4.x, and is under development in the jakarta-tomcat-connectors repository. Coyote 1.0 includes: - Protocol handlers for AJP 1.3, HTTP/1.1 and JNI - Adapter for Tomcat 3.3 - Adapter for Tomcat 4.x Extensibility capabilities will be added to Coyote, as well as JMX management features, and if possible, addional protocol handlers (like WARP 1.0). The Servlet API 2.4 specification will be implemented in a new version of Catalina, called Catalina 2.0. A new version of the Coyote adapter will be written for it if mandated by API changes. Components which duplicate functionality provided by Coyote will be removed, including the old connectors. On the JSP side, Jasper 2 will be updated to support JSP 2.0, will be renamed to Jasper 3, and is the proposed Jasper codebase. It provides many improvements over Jasper 1 included in Tomcat 3.x and Tomcat 4.0.x, including good tag library handling, and near zero overhead when compared to an equivalent hand coded servlet. Jasper 2 will also undergo additional optimizations. Apache Tomcat 5.0 will be made by default of the following components: - Coyote 2.0 - core - Catalina 2.0 - Servlet API 2.4 implementation - Jasper 2 - JSP 2.0 implementation Many other configurations are also possible, and it is expected that advanced users take advantage of it to make Tomcat better suit their needs. It is also possible that new special purpose components, like a bare bones Servlet API implementation, be developed to address the embedded market. Due to the scope of this work, this initial Proposal only plans the implementation and support of the default configuration described above. Changes over Apache Tomcat 4.1.x: A lot of the Apache Tomcat 5.0 code will be based on the Apache Tomcat 4.1.x codebase. Tomcat 5.0 will also be able to use the Tomcat 3.3.x code. The following major changes and additions are proposed to the current Apche Tomcat code, and related dependencies: A) Removal of the org.apache.catalina.connector.* This package is currently deprecated in Tomcat 4.1 because of its implementation inefficiencies, and general bad design. It is thus proposed that it is removed in Tomcat 5.0. B) Addition of new loader code for the commons-daemon subproject It is proposed that, in an attempt to solve the problems with using startup scripts, as well as adding additional features oriented towards reliability (including the capability to restart Tomcat automatically should the JVM crashes or experience memory management related problems), the launcher code which will be developed as part of commons-daemon be
Re: [VOTE] Apache Tomcat 5.0 Proposal
On Wed, 2002-07-03 at 09:57, Remy Maucherat wrote: ballot [ ] +1 I support the proposal, and will help implement it [X] +0 I support the proposal [ ] -0 I do not support the proposal [ ] -1 I am against the proposal being implemented, because: /ballot Which might actually turn out to be +0.01 ;-) Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Apache Tomcat 5.0 Proposal
ballot [X] +1 I support the proposal, and will help implement it [ ] +0 I support the proposal [ ] -0 I do not support the proposal [ ] -1 I am against the proposal being implemented, because: /ballot -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[VOTE] Apache Tomcat 5.0 Proposal
After trying to address the concerns raised by the proposal draft, I would like to call for a vote on it, now that the discussions have died down. ballot [ ] +1 I support the proposal, and will help implement it [ ] +0 I support the proposal [ ] -0 I do not support the proposal [ ] -1 I am against the proposal being implemented, because: /ballot The vote will run for one full week until July 9th. Users and other contributors may vote, but only committers have binding votes. Remy Proposal for Apache Tomcat 5.0 == Introduction: This document is a proposal for the next major release of Apache Tomcat, Apache Tomcat 5.0. Apache Tomcat 5.0 will improve on the Apache Tomcat 3.3 and Apache Tomcat 4.1 architectures, by making them simpler, more flexible and more modular, while at the same time adding support for the new Servlet API 2.4 and JSP 2.0 specifications, currently under development by the Java Community Process. The major goals for Apache Tomcat 5.0 are to: - improve scalability, reliability and performance over previous versions - have simpler/cleaner code, so more people can get involved - merge of the various ideas in 3.x and 4.x - get the community togheter - provide maximum modularity and compliance to the standards - make it easy to continue to maintain the existing codebases Testing will occur to make sure the stated robustness and performance goals are met by Tomcat 5.0. This proposal also tries to take advantage of the lessons learned while optimizing and maintaining Tomcat. Note: The development of Apache Tomcat 4.1.x will continue in parallel to the implementation of this proposal. General architecture: An improved version of Coyote 1.0, called Coyote 2.0, will be used as the Apache Tomcat 5.0 core. Coyote is currently considered a connector for Tomcat 3.3 and 4.x, and is under development in the jakarta-tomcat-connectors repository. Coyote 1.0 includes: - Protocol handlers for AJP 1.3, HTTP/1.1 and JNI - Adapter for Tomcat 3.3 - Adapter for Tomcat 4.x Extensibility capabilities will be added to Coyote, as well as JMX management features, and if possible, addional protocol handlers (like WARP 1.0). The Servlet API 2.4 specification will be implemented in a new version of Catalina, called Catalina 2.0. A new version of the Coyote adapter will be written for it if mandated by API changes. Components which duplicate functionality provided by Coyote will be removed, including the old connectors. On the JSP side, Jasper 2 will be updated to support JSP 2.0, will be renamed to Jasper 3, and is the proposed Jasper codebase. It provides many improvements over Jasper 1 included in Tomcat 3.x and Tomcat 4.0.x, including good tag library handling, and near zero overhead when compared to an equivalent hand coded servlet. Jasper 2 will also undergo additional optimizations. Apache Tomcat 5.0 will be made by default of the following components: - Coyote 2.0 - core - Catalina 2.0 - Servlet API 2.4 implementation - Jasper 2 - JSP 2.0 implementation Many other configurations are also possible, and it is expected that advanced users take advantage of it to make Tomcat better suit their needs. It is also possible that new special purpose components, like a bare bones Servlet API implementation, be developed to address the embedded market. Due to the scope of this work, this initial Proposal only plans the implementation and support of the default configuration described above. Changes over Apache Tomcat 4.1.x: A lot of the Apache Tomcat 5.0 code will be based on the Apache Tomcat 4.1.x codebase. Tomcat 5.0 will also be able to use the Tomcat 3.3.x code. The following major changes and additions are proposed to the current Apche Tomcat code, and related dependencies: A) Removal of the org.apache.catalina.connector.* This package is currently deprecated in Tomcat 4.1 because of its implementation inefficiencies, and general bad design. It is thus proposed that it is removed in Tomcat 5.0. B) Addition of new loader code for the commons-daemon subproject It is proposed that, in an attempt to solve the problems with using startup scripts, as well as adding additional features oriented towards reliability (including the capability to restart Tomcat automatically should the JVM crashes or experience memory management related problems), the launcher code which will be developed as part of commons-daemon be adopted. This code will be based in part on the launcher code used for the Sun Web Services Pack, and in part on the Wrapper project code (available at SF.net), if we manage to come to an agreement with the Wrapper developers. C) Extensions to Coyote It is proposed that Coyote 2.0 include the following changes over Coyote 1.0: - The current hook mechanism used in Coyote 1.0 will be extended to be more generic and
Re: [VOTE] Apache Tomcat 5.0 Proposal
On Tue, 2 Jul 2002, Remy Maucherat wrote: After trying to address the concerns raised by the proposal draft, I would like to call for a vote on it, now that the discussions have died down. ballot [X] +1 I support the proposal, and will help implement it [ ] +0 I support the proposal [ ] -0 I do not support the proposal [ ] -1 I am against the proposal being implemented, because: /ballot The vote will run for one full week until July 9th. Users and other contributors may vote, but only committers have binding votes. I won't read the mail for the rest of the week ( I'll be back next Mon ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: 5.0 proposal
I can't commit to developing this (I'd love to, I have some ideas, but I don't have the time...), but hopefully it might interest someone and they can develop it... When deploying webapps as WAR files, especially generic webapps, it's not always very practical to request that an administrator manually unpacks the WAR file, locates the web.xml file, and updates context or servlet parameters. Perhaps the admin/manager webapp could list all context/servlet parameters for a given webapp, and allow their values to be changed. This isn't a way to modify web.xml directly, more a way to store values to override whatever's in web.xml. That way, if a new copy of the webapp is installed in the server, the overriding values would still be retained and can override the updated web.xml, without requiring to be reentered. It's by no means a critical feature, but it's nice to have. - Chris B. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: HA tomcat ( was: RE: 5.0 proposal)
Thanks for the encouraged news. We've been using Tomcat in our product for a while now. Now, I need to set it up with support for minimum 100K simultaneous connection to our server side. 100K simultaneous connection ! I doubt any hardware/software/os (even on high system) could handle that. And no mather if the server code is in native or in java. May be you was thinking 100K by days ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: 5.0 proposal
- Original Message - From: Pier Fumagalli [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, June 24, 2002 9:49 PM Subject: Re: 5.0 proposal [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Mon, 24 Jun 2002, Pier Fumagalli wrote: That's why counts where not right on my side of the border... I don't recall vetoing the proposal... I just complained vehemently that I'd prefer to see 4.0 out of the door and stable rather than a 4.1 and a 5.0... 4.0 is out of door - the release happened long ago. So did 4.0.1... 4.0.4. 4.1 is getting close - and it should be more stable and better than 4.0.4. And 5.0 should be more stable and better than 4.1 and 3.3. And 6.0 will probably be better than 5.0. If you are interested in maintaining and improving 4.0.4 - just volunteer as release manager for the branch, you have my +1 on it. I can't be a RM for 4.0.4 because I would simply remove 70% of the code, and kiddies would start crying their butts off because they don't have the manager application, or JSP support :) But if anyone is interested I'd like to explore the opportunity of a Tomcat-HA (high-availability or hard-edition), based on 4.0 without the crap in there, and straightening out the request-response model... +100! As somebody who also intends to use Tomcat in production (around 10 different sites with a reasonable load, maybe 1/4 of vnunet) this would be very helpful to me. You mentioned a couple of specific things you would like to do. Would it be possible for you elaborate a little more. Regards, Arshad -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: 5.0 proposal
Pier Fumagalli wrote: Remy Maucherat [EMAIL PROTECTED] wrote: I don't see that much to remove. I assume JNDI is the ever popular target, but I didn't notice it causing major problems (either performance or reliability), so I'd say it's not worth it. Actually, I have a complaint... 4.1.3 tries to write into my conf directory: especially the tomcat-users.xml.new file (and since the directory is read only, the VM falls over). Call it defensive administration, but I don't want my engine to write a single file if it's not where I tell him to do: /tmp. And for sure it must not attempt to modify my tomcat-users.xml. Only _root_ can do that, and if this is one of those things you call features, I call it a big huge security hole. Craig calls it a feature, so talk with him :) The new realm does that. If you look at the server.xml, you will notice you can still use the classic memory realm from 4.0 which doesn't do that instead of the new user database realm. Attached there is a nice output of my logfile. Plus, about that random BOUND socket I had, I noticed it's a leftover somehow in some friggin' initialization stage... My ports are 8005 (control) and 8080 (http/coyote) When I start up the thing it's all clear. I start 4.1.2 and notice: Local Address Remote Address Swind Send-Q Rwind Recv-Q State --- --- - -- - -- - localhost.8080 localhost.47420 32768 0 32768 0 TIME_WAIT localhost.47422 localhost.47421 32768 0 32768 0 TIME_WAIT *.8080 *.* 0 0 24576 0 LISTEN Why in the world is TC first of all opening a serversocket on port 47421? (this port number always varies) what's going on here? I don't get that kind of odd behavior on Windows/Cygwin, so I can't help much here. No extra port gets bound in my configuration. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: 5.0 proposal
Hi all, I was interested to read the differing opinions on 5.0 or not, and I was interested to hear Pier say that he did not think tomcat was an option in a production system. We have been using tomcat 3.2.3 (an out of date version I know) and while it performs it very well under a light load, some strange things start to happen when our site gets busy the only solution seems to be to shut down and restart tomcat (I know that this it not supposed to required on a regular basis is it ?). I wont bother describing exactly what happens because we are using an older version and some of the issues may have been resolved, but we do get some unexpected behaviour under high loads. Long and short : as a user of tomcat, i would be far more appreciative of a so called high-availability or hard-edition than an new feature rich version. Just because thats of most use (I think) to me though :-) -Original Message- From: Arshad Mahmood [mailto:[EMAIL PROTECTED]] Sent: 25 June 2002 09:12 To: Tomcat Developers List Subject: Re: 5.0 proposal - Original Message - From: Pier Fumagalli [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, June 24, 2002 9:49 PM Subject: Re: 5.0 proposal [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Mon, 24 Jun 2002, Pier Fumagalli wrote: That's why counts where not right on my side of the border... I don't recall vetoing the proposal... I just complained vehemently that I'd prefer to see 4.0 out of the door and stable rather than a 4.1 and a 5.0... 4.0 is out of door - the release happened long ago. So did 4.0.1... 4.0.4. 4.1 is getting close - and it should be more stable and better than 4.0.4. And 5.0 should be more stable and better than 4.1 and 3.3. And 6.0 will probably be better than 5.0. If you are interested in maintaining and improving 4.0.4 - just volunteer as release manager for the branch, you have my +1 on it. I can't be a RM for 4.0.4 because I would simply remove 70% of the code, and kiddies would start crying their butts off because they don't have the manager application, or JSP support :) But if anyone is interested I'd like to explore the opportunity of a Tomcat-HA (high-availability or hard-edition), based on 4.0 without the crap in there, and straightening out the request-response model... +100! As somebody who also intends to use Tomcat in production (around 10 different sites with a reasonable load, maybe 1/4 of vnunet) this would be very helpful to me. You mentioned a couple of specific things you would like to do. Would it be possible for you elaborate a little more. Regards, Arshad -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information, visit http://www.messagelabs.com _ This message from All-Hotels has been checked for all known viruses by the MessageLabs Virus Scanning Service. For further information visit: http://www.messagelabs.com/stats.asp -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: 5.0 proposal
Steven Wood wrote: Hi all, I was interested to read the differing opinions on 5.0 or not, and I was interested to hear Pier say that he did not think tomcat was an option in a production system. We have been using tomcat 3.2.3 (an out of date version I know) and while it performs it very well under a light load, some strange things start to happen when our site gets busy the only solution seems to be to shut down and restart tomcat (I know that this it not supposed to required on a regular basis is it ?). I wont bother describing exactly what happens because we are using an older version and some of the issues may have been resolved, but we do get some unexpected behaviour under high loads. I am really sorry, but you have only yourself to blame for not at least upgrading to Tomcat 3.3.x, which is the HA version of Tomcat 3.2. Long and short : as a user of tomcat, i would be far more appreciative of a so called high-availability or hard-edition than an new feature rich version. Just because thats of most use (I think) to me though :-) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: 5.0 proposal
I'm also very interested in hearing more about Tomcat HA. Speaking about HIGH AVAILABILITY, is linked to reliability and scalabitity. reliability should be provided by Tomcat core but scalability should be provided by some sorts of software between end-user and Tomcat's core. As I said yesterday, it could be achieved by : - request dispatcher to multiples Tomcat Instance JVM (mod_jk does that and mod_jk2 will push it farther) - tomcat instance datas replications, may be introduced by external APIs like spread or javagroups (javagroups has been used in TC 4.0 but due to its GPL license couldn't be added to Tomcat 4.0) But reliability should cover the full chain : - link between end-user / tomcat - tomcat core - java web application - remote applications / databases (SQL backend, JMS, links to proprietary applications) In my opinion, TC 5.0 should provide a stable core, and offer replication support (via spread/javagroup). Others parts link between end-user and tomcat, should fall in connectors land. Java web applications in on webapp developpers land. Remote Apps / SQL stability depends on SQL JDBC drivers, JMS or proprietary comm layers, and of course on availabity of remote apps/databases. - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Steven Wood [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 25, 2002 10:41 AM To: 'Tomcat Developers List' Subject: RE: 5.0 proposal Hi all, I was interested to read the differing opinions on 5.0 or not, and I was interested to hear Pier say that he did not think tomcat was an option in a production system. We have been using tomcat 3.2.3 (an out of date version I know) and while it performs it very well under a light load, some strange things start to happen when our site gets busy the only solution seems to be to shut down and restart tomcat (I know that this it not supposed to required on a regular basis is it ?). I wont bother describing exactly what happens because we are using an older version and some of the issues may have been resolved, but we do get some unexpected behaviour under high loads. Long and short : as a user of tomcat, i would be far more appreciative of a so called high-availability or hard-edition than an new feature rich version. Just because thats of most use (I think) to me though :-) -Original Message- From: Arshad Mahmood [mailto:[EMAIL PROTECTED]] Sent: 25 June 2002 09:12 To: Tomcat Developers List Subject: Re: 5.0 proposal - Original Message - From: Pier Fumagalli [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, June 24, 2002 9:49 PM Subject: Re: 5.0 proposal [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Mon, 24 Jun 2002, Pier Fumagalli wrote: That's why counts where not right on my side of the border... I don't recall vetoing the proposal... I just complained vehemently that I'd prefer to see 4.0 out of the door and stable rather than a 4.1 and a 5.0... 4.0 is out of door - the release happened long ago. So did 4.0.1... 4.0.4. 4.1 is getting close - and it should be more stable and better than 4.0.4. And 5.0 should be more stable and better than 4.1 and 3.3. And 6.0 will probably be better than 5.0. If you are interested in maintaining and improving 4.0.4 - just volunteer as release manager for the branch, you have my +1 on it. I can't be a RM for 4.0.4 because I would simply remove 70% of the code, and kiddies would start crying their butts off because they don't have the manager application, or JSP support :) But if anyone is interested I'd like to explore the opportunity of a Tomcat-HA (high-availability or hard-edition), based on 4.0 without the crap in there, and straightening out the request-response model... +100! As somebody who also intends to use Tomcat in production (around 10 different sites with a reasonable load, maybe 1/4 of vnunet) this would be very helpful to me. You mentioned a couple of specific things you would like to do. Would it be possible for you elaborate a little more. Regards, Arshad -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information, visit http://www.messagelabs.com _ This message from All-Hotels has been checked for all known viruses by the MessageLabs Virus Scanning Service. For further information visit: http://www.messagelabs.com/stats.asp -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED
RE: 5.0 proposal
I am really sorry, but you have only yourself to blame for not at least upgrading to Tomcat 3.3.x, which is the HA version of Tomcat 3.2. yip, I know, i'm dowloading it as i send this :-) -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: 25 June 2002 09:45 To: Tomcat Developers List Subject: Re: 5.0 proposal Steven Wood wrote: Hi all, I was interested to read the differing opinions on 5.0 or not, and I was interested to hear Pier say that he did not think tomcat was an option in a production system. We have been using tomcat 3.2.3 (an out of date version I know) and while it performs it very well under a light load, some strange things start to happen when our site gets busy the only solution seems to be to shut down and restart tomcat (I know that this it not supposed to required on a regular basis is it ?). I wont bother describing exactly what happens because we are using an older version and some of the issues may have been resolved, but we do get some unexpected behaviour under high loads. I am really sorry, but you have only yourself to blame for not at least upgrading to Tomcat 3.3.x, which is the HA version of Tomcat 3.2. Long and short : as a user of tomcat, i would be far more appreciative of a so called high-availability or hard-edition than an new feature rich version. Just because thats of most use (I think) to me though :-) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information, visit http://www.messagelabs.com _ This message from All-Hotels has been checked for all known viruses by the MessageLabs Virus Scanning Service. For further information visit: http://www.messagelabs.com/stats.asp -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
random BOUND socket (was Re: 5.0 proposal).
Remy Maucherat wrote: Pier Fumagalli wrote: Remy Maucherat [EMAIL PROTECTED] wrote: I don't see that much to remove. I assume JNDI is the ever popular target, but I didn't notice it causing major problems (either performance or reliability), so I'd say it's not worth it. Actually, I have a complaint... 4.1.3 tries to write into my conf directory: especially the tomcat-users.xml.new file (and since the directory is read only, the VM falls over). Call it defensive administration, but I don't want my engine to write a single file if it's not where I tell him to do: /tmp. And for sure it must not attempt to modify my tomcat-users.xml. Only _root_ can do that, and if this is one of those things you call features, I call it a big huge security hole. Craig calls it a feature, so talk with him :) The new realm does that. If you look at the server.xml, you will notice you can still use the classic memory realm from 4.0 which doesn't do that instead of the new user database realm. Attached there is a nice output of my logfile. Plus, about that random BOUND socket I had, I noticed it's a leftover somehow in some friggin' initialization stage... My ports are 8005 (control) and 8080 (http/coyote) When I start up the thing it's all clear. I start 4.1.2 and notice: Local Address Remote Address Swind Send-Q Rwind Recv-Q State --- --- - -- - -- - localhost.8080 localhost.47420 32768 0 32768 0 TIME_WAIT localhost.47422 localhost.47421 32768 0 32768 0 TIME_WAIT *.8080 *.* 0 0 24576 0 LISTEN Why in the world is TC first of all opening a serversocket on port 47421? (this port number always varies) what's going on here? I don't get that kind of odd behavior on Windows/Cygwin, so I can't help much here. No extra port gets bound in my configuration. I do see the following on my Linux: +++ tcp0 0 :::127.0.0:http-alt :::127.0.0.1:32893 TIME_WAIT tcp0 0 :::127.0.0.1:32892 :::127.0.0.1:8005 TIME_WAIT tcp0 0 :::127.0.0.1:32894 :::127.0.0.1:8009 TIME_WAIT tcp0 0 ::1:32891 ::1:32890 TIME_WAIT +++ The last line varies: +++ tcp0 0 ::1:32889 ::1:32888 TIME_WAIT +++ When Tomcat is stopped I do not have it. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: 5.0 proposal
Arshad Mahmood [EMAIL PROTECTED] wrote: +100! As somebody who also intends to use Tomcat in production (around 10 different sites with a reasonable load, maybe 1/4 of vnunet) this would be very helpful to me. You mentioned a couple of specific things you would like to do. Would it be possible for you elaborate a little more. Arshad, you don't count... You work with me! :) :) :) :) Pier -- [Perl] combines all the worst aspects of C and Lisp: a billion of different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: random BOUND socket (was Re: 5.0 proposal).
jean-frederic clere [EMAIL PROTECTED] wrote: I do see the following on my Linux: +++ tcp0 0 :::127.0.0:http-alt :::127.0.0.1:32893 TIME_WAIT tcp0 0 :::127.0.0.1:32892 :::127.0.0.1:8005 TIME_WAIT tcp0 0 :::127.0.0.1:32894 :::127.0.0.1:8009 TIME_WAIT tcp0 0 ::1:32891 ::1:32890 TIME_WAIT +++ The last line varies: +++ tcp0 0 ::1:32889 ::1:32888 TIME_WAIT +++ When Tomcat is stopped I do not have it. It seems that you are actually observing my same odd behavior... On Solaris, when the TIME_WAIT expires, one of those sockets becomes BOUND, as if noone ever closed it... Pier -- [Perl] combines all the worst aspects of C and Lisp: a billion of different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: random BOUND socket (was Re: 5.0 proposal).
We add a timeout features in mod_jk 1.2.0 to close sockets after some time of inactivity :) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Pier Fumagalli [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 25, 2002 4:41 PM To: Tomcat Developers List Subject: Re: random BOUND socket (was Re: 5.0 proposal). jean-frederic clere [EMAIL PROTECTED] wrote: I do see the following on my Linux: +++ tcp0 0 :::127.0.0:http-alt :::127.0.0.1:32893 TIME_WAIT tcp0 0 :::127.0.0.1:32892 :::127.0.0.1:8005 TIME_WAIT tcp0 0 :::127.0.0.1:32894 :::127.0.0.1:8009 TIME_WAIT tcp0 0 ::1:32891 ::1:32890 TIME_WAIT +++ The last line varies: +++ tcp0 0 ::1:32889 ::1:32888 TIME_WAIT +++ When Tomcat is stopped I do not have it. It seems that you are actually observing my same odd behavior... On Solaris, when the TIME_WAIT expires, one of those sockets becomes BOUND, as if noone ever closed it... Pier -- [Perl] combines all the worst aspects of C and Lisp: a billion of different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: 5.0 proposal
Pier could you detail what should be a Tomcat HA, and how it could fit in TC 5.0 proposal ? As far as I can remember it was voted -1... What about TC 5.0 with HA capability ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
HA tomcat ( was: RE: 5.0 proposal)
On Tue, 25 Jun 2002, GOMEZ Henri wrote: Pier could you detail what should be a Tomcat HA, and how it could fit in TC 5.0 proposal ? As far as I can remember it was voted -1... What about TC 5.0 with HA capability ? TC5.0 will have a 'higher availability' then 4.1 which is better than 4.0. Same goes for 3.3 versus 3.2, and so on. rant -stop reading if you're not interested in flames -- I am trying as hard as possible to remain calm and on the subject when discussing with 'angry' Pier - but the FUD he is using is unbelievable. He can't use tomcat4.0 in production ? Maybe he's trying to do that with mod_webapp ( with no load balancing AFAIK, and 'auto configuration' ). And he complains about features - well, Apache is full of features, and most people know how to not enable the modules that they don't need on a production site. Now he proposes a HA tomcat - as if all our efforts in so far has been in adding useless features and nobody else cares about HA. Well, if you would pay attention a lot of work is beeing put in improving the lb ( an essential factor for HA ), in adding management ( guess what - JMX is not only for configuration, but also for getting runtime info and notifications ), and in improving the low-level objects to beter deal with the load ( that's coyote ) plus for 5.0 a simpler core that would allow more modularity ( coyote again ). And the solution he proposes: removing 'useless' features like jasper or JMX. Well, I know quite a few people who managed to get tomcat in production on a variety of sites ( including very large loads). Even with tomcat3.2 - a generation behind the current 3.3 and 4.0. They do that using load balancing and customizing the installation. Unfortunately Pier's tomcat4.0 doesn't support load balancing, and it seems he's having problems with the admin module of 4.1. Well, send a patch - or just disable the offending module in your code. Tomcat out-of-box is feature full and more intended for developers ( who greatly outnumber the 'production sites'). If you read the 5.0 proposal, it allows ( or includes ) the ability to release customized tomcats. Of course, nobody stops Pier on working on whatever he wants - a -1 means he can't do it in the main branch and he can't use the name 'tomcat', but the proposal/ area has allwasy been open. If he can get a 'higher availability' than we'll get with 5.0 - great, we'll all be happy. But now Pier treatens he'll just leave us oprhapns ( without a father). I certainly hope he's not serious with that, and if he does - I hope he'll return. And in the meantime he may try to learn to be a bit more polite and modest - and control his frustrations. /rant Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: 5.0 proposal
GOMEZ Henri [EMAIL PROTECTED] wrote: Pier could you detail what should be a Tomcat HA, and how it could fit in TC 5.0 proposal ? As far as I can remember it was voted -1... What about TC 5.0 with HA capability ? Well... It's a matter of code... Given that there is not one line of code in there, it's really hard to fit it into a proposal... We need to switch Servlet Engine by the fall (meaning that we'll have a working prototype by the end of July). I can cram out some code in the public, and make it available to see what I mean by HA. As I'm discovering the wonders of subversion, I placed a little repository up on Nagoya to work on the proposal: It is available here: http://nagoya.apache.org/svn/jakarta-tomcat-ha/ If you guys don't want to see it associated with the Apache name, just let me know and I will move it off on my (Betaversion or VNU) servers. Pier -- [Perl] combines all the worst aspects of C and Lisp: a billion of different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: 5.0 proposal
On Tue, 25 Jun 2002, Pier Fumagalli wrote: http://nagoya.apache.org/svn/jakarta-tomcat-ha/ If you guys don't want to see it associated with the Apache name, just let me know and I will move it off on my (Betaversion or VNU) servers. If possible, please also change the name - unless ASF gives you permission to use tomcat name in your product. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: HA tomcat ( was: RE: 5.0 proposal)
Although Pier is sometimes harsh with his words he does have some valid points. I would be nice for tomcat to be somewhat modular so if all you want is a servlet engine just get those components. This also goes with moving the CVS repositories.. so you can get only the modules you want and build the parts of tomcat that you need with out all the overhead. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 25, 2002 1:07 PM To: Tomcat Developers List Subject: HA tomcat ( was: RE: 5.0 proposal) On Tue, 25 Jun 2002, GOMEZ Henri wrote: Pier could you detail what should be a Tomcat HA, and how it could fit in TC 5.0 proposal ? As far as I can remember it was voted -1... What about TC 5.0 with HA capability ? TC5.0 will have a 'higher availability' then 4.1 which is better than 4.0. Same goes for 3.3 versus 3.2, and so on. rant -stop reading if you're not interested in flames -- I am trying as hard as possible to remain calm and on the subject when discussing with 'angry' Pier - but the FUD he is using is unbelievable. He can't use tomcat4.0 in production ? Maybe he's trying to do that with mod_webapp ( with no load balancing AFAIK, and 'auto configuration' ). And he complains about features - well, Apache is full of features, and most people know how to not enable the modules that they don't need on a production site. Now he proposes a HA tomcat - as if all our efforts in so far has been in adding useless features and nobody else cares about HA. Well, if you would pay attention a lot of work is beeing put in improving the lb ( an essential factor for HA ), in adding management ( guess what - JMX is not only for configuration, but also for getting runtime info and notifications ), and in improving the low-level objects to beter deal with the load ( that's coyote ) plus for 5.0 a simpler core that would allow more modularity ( coyote again ). And the solution he proposes: removing 'useless' features like jasper or JMX. Well, I know quite a few people who managed to get tomcat in production on a variety of sites ( including very large loads). Even with tomcat3.2 - a generation behind the current 3.3 and 4.0. They do that using load balancing and customizing the installation. Unfortunately Pier's tomcat4.0 doesn't support load balancing, and it seems he's having problems with the admin module of 4.1. Well, send a patch - or just disable the offending module in your code. Tomcat out-of-box is feature full and more intended for developers ( who greatly outnumber the 'production sites'). If you read the 5.0 proposal, it allows ( or includes ) the ability to release customized tomcats. Of course, nobody stops Pier on working on whatever he wants - a -1 means he can't do it in the main branch and he can't use the name 'tomcat', but the proposal/ area has allwasy been open. If he can get a 'higher availability' than we'll get with 5.0 - great, we'll all be happy. But now Pier treatens he'll just leave us oprhapns ( without a father). I certainly hope he's not serious with that, and if he does - I hope he'll return. And in the meantime he may try to learn to be a bit more polite and modest - and control his frustrations. /rant Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: HA tomcat ( was: RE: 5.0 proposal)
On Tue, 25 Jun 2002, John Trollinger wrote: Date: Tue, 25 Jun 2002 13:19:40 -0400 From: John Trollinger [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: 'Tomcat Developers List' [EMAIL PROTECTED] Subject: RE: HA tomcat ( was: RE: 5.0 proposal) Although Pier is sometimes harsh with his words he does have some valid points. I would be nice for tomcat to be somewhat modular so if all you want is a servlet engine just get those components. I'd say both the 3.3 and 4.0/4.1 architectures are already pretty modular -- is there something specific that you consider monolithic that should be factored apart? Or is it just that finer-grained build.xml targets would do what you want? This also goes with moving the CVS repositories.. so you can get only the modules you want and build the parts of tomcat that you need with out all the overhead. The Apache infrastructure folks (well, at least some of them) tend to frown on multiple CVS repositories for a single project, and they've got a point -- the number of CVS repositories has nothing to do with how many deliverable distributions you can create from them. For example, the jakarta-commons and jakarta-taglibs repositories each host lots of independently released packages, while a single Tomcat release combines code from 5-10 independent repositories. Craig -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 25, 2002 1:07 PM To: Tomcat Developers List Subject: HA tomcat ( was: RE: 5.0 proposal) On Tue, 25 Jun 2002, GOMEZ Henri wrote: Pier could you detail what should be a Tomcat HA, and how it could fit in TC 5.0 proposal ? As far as I can remember it was voted -1... What about TC 5.0 with HA capability ? TC5.0 will have a 'higher availability' then 4.1 which is better than 4.0. Same goes for 3.3 versus 3.2, and so on. rant -stop reading if you're not interested in flames -- I am trying as hard as possible to remain calm and on the subject when discussing with 'angry' Pier - but the FUD he is using is unbelievable. He can't use tomcat4.0 in production ? Maybe he's trying to do that with mod_webapp ( with no load balancing AFAIK, and 'auto configuration' ). And he complains about features - well, Apache is full of features, and most people know how to not enable the modules that they don't need on a production site. Now he proposes a HA tomcat - as if all our efforts in so far has been in adding useless features and nobody else cares about HA. Well, if you would pay attention a lot of work is beeing put in improving the lb ( an essential factor for HA ), in adding management ( guess what - JMX is not only for configuration, but also for getting runtime info and notifications ), and in improving the low-level objects to beter deal with the load ( that's coyote ) plus for 5.0 a simpler core that would allow more modularity ( coyote again ). And the solution he proposes: removing 'useless' features like jasper or JMX. Well, I know quite a few people who managed to get tomcat in production on a variety of sites ( including very large loads). Even with tomcat3.2 - a generation behind the current 3.3 and 4.0. They do that using load balancing and customizing the installation. Unfortunately Pier's tomcat4.0 doesn't support load balancing, and it seems he's having problems with the admin module of 4.1. Well, send a patch - or just disable the offending module in your code. Tomcat out-of-box is feature full and more intended for developers ( who greatly outnumber the 'production sites'). If you read the 5.0 proposal, it allows ( or includes ) the ability to release customized tomcats. Of course, nobody stops Pier on working on whatever he wants - a -1 means he can't do it in the main branch and he can't use the name 'tomcat', but the proposal/ area has allwasy been open. If he can get a 'higher availability' than we'll get with 5.0 - great, we'll all be happy. But now Pier treatens he'll just leave us oprhapns ( without a father). I certainly hope he's not serious with that, and if he does - I hope he'll return. And in the meantime he may try to learn to be a bit more polite and modest - and control his frustrations. /rant Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: 5.0 proposal
- Original Message - From: Pier Fumagalli [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, June 25, 2002 3:36 PM Subject: Re: 5.0 proposal Arshad Mahmood [EMAIL PROTECTED] wrote: +100! As somebody who also intends to use Tomcat in production (around 10 different sites with a reasonable load, maybe 1/4 of vnunet) this would be very helpful to me. You mentioned a couple of specific things you would like to do. Would it be possible for you elaborate a little more. Arshad, you don't count... You work with me! :) :) :) :) Pier, This is for my own sites not for vnu (my commitments are very limited to vnu anyway). I intend to go with Tomcat 4.1 into production in the next couple of weeks (volume will be insignificant for the first site) so I intend to spend quite a bit of time trying to iron out bugs/problems and scaling issues. As such I have the time to spare to work on the Tomcat enhancements to make it more scalable/reliable. I am very keen to hear your ideas. Regards, Arshad -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: 5.0 proposal
I'm interested in this Tomcat HA also. If you have a plan, please send it out. I'm willing to help. GOMEZ Henri wrote: As somebody who also intends to use Tomcat in production (around 10 different sites with a reasonable load, maybe 1/4 of vnunet) this would be very helpful to me. You mentioned a couple of specific things you would like to do. Would it be possible for you elaborate a little more. Arshad, you don't count... You work with me! :) :) :) :) Pier could you detail what should be a Tomcat HA, and how it could fit in TC 5.0 proposal ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: HA tomcat ( was: RE: 5.0 proposal)
On Tue, 25 Jun 2002, John Trollinger wrote: Although Pier is sometimes harsh with his words he does have some valid points. I would be nice for tomcat to be somewhat modular so if all you want is a servlet engine just get those components. This also goes with moving the CVS repositories.. so you can get only the modules you want and build the parts of tomcat that you need with out all the overhead. I run tomcat on my sharp Zaurus, using a J2ME VM - it's the developer edition, with about 16M heap ( out of 32 M RAM ). The whole installation is below 1.5M ( well, with crimson.jar taking a lot of space - but it can be replaced with a smaller parser ). I agree it is a bit bloated, and I hope 5.0 will fit in 512K. If people are too lazy to remove the stuff they don't need on a production site - we could easily provide a 'tomcat lazy edition'. Since most users are lazy developers, that's what the default release includes. Are you enabling all the modules that comes with Apache by default ? Or maybe all the possible modules ( mod_auth_ldap, mod_dav, etc ) ? Do you see any apache distribution that includes just part of the code, with the modules that Pier doesn't use left out ? Costin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 25, 2002 1:07 PM To: Tomcat Developers List Subject: HA tomcat ( was: RE: 5.0 proposal) On Tue, 25 Jun 2002, GOMEZ Henri wrote: Pier could you detail what should be a Tomcat HA, and how it could fit in TC 5.0 proposal ? As far as I can remember it was voted -1... What about TC 5.0 with HA capability ? TC5.0 will have a 'higher availability' then 4.1 which is better than 4.0. Same goes for 3.3 versus 3.2, and so on. rant -stop reading if you're not interested in flames -- I am trying as hard as possible to remain calm and on the subject when discussing with 'angry' Pier - but the FUD he is using is unbelievable. He can't use tomcat4.0 in production ? Maybe he's trying to do that with mod_webapp ( with no load balancing AFAIK, and 'auto configuration' ). And he complains about features - well, Apache is full of features, and most people know how to not enable the modules that they don't need on a production site. Now he proposes a HA tomcat - as if all our efforts in so far has been in adding useless features and nobody else cares about HA. Well, if you would pay attention a lot of work is beeing put in improving the lb ( an essential factor for HA ), in adding management ( guess what - JMX is not only for configuration, but also for getting runtime info and notifications ), and in improving the low-level objects to beter deal with the load ( that's coyote ) plus for 5.0 a simpler core that would allow more modularity ( coyote again ). And the solution he proposes: removing 'useless' features like jasper or JMX. Well, I know quite a few people who managed to get tomcat in production on a variety of sites ( including very large loads). Even with tomcat3.2 - a generation behind the current 3.3 and 4.0. They do that using load balancing and customizing the installation. Unfortunately Pier's tomcat4.0 doesn't support load balancing, and it seems he's having problems with the admin module of 4.1. Well, send a patch - or just disable the offending module in your code. Tomcat out-of-box is feature full and more intended for developers ( who greatly outnumber the 'production sites'). If you read the 5.0 proposal, it allows ( or includes ) the ability to release customized tomcats. Of course, nobody stops Pier on working on whatever he wants - a -1 means he can't do it in the main branch and he can't use the name 'tomcat', but the proposal/ area has allwasy been open. If he can get a 'higher availability' than we'll get with 5.0 - great, we'll all be happy. But now Pier treatens he'll just leave us oprhapns ( without a father). I certainly hope he's not serious with that, and if he does - I hope he'll return. And in the meantime he may try to learn to be a bit more polite and modest - and control his frustrations. /rant Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: HA tomcat ( was: RE: 5.0 proposal)
[EMAIL PROTECTED] wrote: On Tue, 25 Jun 2002, GOMEZ Henri wrote: Pier could you detail what should be a Tomcat HA, and how it could fit in TC 5.0 proposal ? As far as I can remember it was voted -1... What about TC 5.0 with HA capability ? TC5.0 will have a 'higher availability' then 4.1 which is better than 4.0. Same goes for 3.3 versus 3.2, and so on. rant -stop reading if you're not interested in flames -- I am trying as hard as possible to remain calm and on the subject when discussing with 'angry' Pier - but the FUD he is using is unbelievable. He can't use tomcat4.0 in production ? Maybe he's trying to do that with mod_webapp ( with no load balancing AFAIK, and 'auto configuration' ). And he complains about features - well, Apache is full of features, and most people know how to not enable the modules that they don't need on a production site. Now he proposes a HA tomcat - as if all our efforts in so far has been in adding useless features and nobody else cares about HA. Well, if you would pay attention a lot of work is beeing put in improving the lb ( an essential factor for HA ), in adding management ( guess what - JMX is not only for configuration, but also for getting runtime info and notifications ), and in improving the low-level objects to beter deal with the load ( that's coyote ) plus for 5.0 a simpler core that would allow more modularity ( coyote again ). And the solution he proposes: removing 'useless' features like jasper or JMX. Well, I know quite a few people who managed to get tomcat in production on a variety of sites ( including very large loads). Even with tomcat3.2 - a generation behind the current 3.3 and 4.0. They do that using load balancing and customizing the installation. Unfortunately Pier's tomcat4.0 doesn't support load balancing, and it seems he's having problems with the admin module of 4.1. Well, send a patch - or just disable the offending module in your code. Tomcat out-of-box is feature full and more intended for developers ( who greatly outnumber the 'production sites'). If you read the 5.0 proposal, it allows ( or includes ) the ability to release customized tomcats. Of course, nobody stops Pier on working on whatever he wants - a -1 means he can't do it in the main branch and he can't use the name 'tomcat', but the proposal/ area has allwasy been open. If he can get a 'higher availability' than we'll get with 5.0 - great, we'll all be happy. But now Pier treatens he'll just leave us oprhapns ( without a father). I certainly hope he's not serious with that, and if he does - I hope he'll return. And in the meantime he may try to learn to be a bit more polite and modest - and control his frustrations. /rant Even omitting personal comments from the rant (which I have to admit I share), you did a sooo impressive work on improving Tomcat HA-level during the 3.0-3.1-3.2-3.3 releases that I definitely trust you to help take Tomcat 5.0 to the next HA-level. On a side note, it would be really nice if Tomcat developers could STOP writing blanket FUD-style statements about whatever module / the container / etc when they didn't even care to review the code. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: HA tomcat ( was: RE: 5.0 proposal)
[EMAIL PROTECTED] wrote: On Tue, 25 Jun 2002, GOMEZ Henri wrote: Pier could you detail what should be a Tomcat HA, and how it could fit in TC 5.0 proposal ? As far as I can remember it was voted -1... What about TC 5.0 with HA capability ? TC5.0 will have a 'higher availability' then 4.1 which is better than 4.0. Same goes for 3.3 versus 3.2, and so on. [snip] Well, I know quite a few people who managed to get tomcat in production on a variety of sites ( including very large loads). I run Tomcat on 20 or so production web sites, with volumes in the 2/3 million hits per day mark. I've been running Tomcat since march 2000, starting with 3.2.1. I think with a little of involvment it is easy to set up a high availability environment using Apache/Tomcat and maybe hardware load balancers. Maybe what is missing is a good tutorial on such a setup. Maybe I could start thinking about writing something about our setup. We came up with neat tricks to handle live application upgrade and this sort of things. I don't know where this could fit in but it is definitely the kind of HOWTO that could be good for the spread of Tomcat on production environments. As for the pure servlet speed Tomcat can deliver, from what I see everyday, the bottleneck is usually in the data tier and not in the application server, so this is a purely sterile debate in my opinion. Just my 2 cents of euro worth. Mathias. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: HA tomcat ( was: RE: 5.0 proposal)
Mathias, Thanks for the encouraged news. We've been using Tomcat in our product for a while now. Now, I need to set it up with support for minimum 100K simultaneous connection to our server side. If you could share some of your knowledge how you did it with your site, it would be tremendously helpful for me and many other Tomcat user out there. Regards, Huy Tran. Mathias Herberts wrote: [EMAIL PROTECTED] wrote: On Tue, 25 Jun 2002, GOMEZ Henri wrote: Pier could you detail what should be a Tomcat HA, and how it could fit in TC 5.0 proposal ? As far as I can remember it was voted -1... What about TC 5.0 with HA capability ? TC5.0 will have a 'higher availability' then 4.1 which is better than 4.0. Same goes for 3.3 versus 3.2, and so on. [snip] Well, I know quite a few people who managed to get tomcat in production on a variety of sites ( including very large loads). I run Tomcat on 20 or so production web sites, with volumes in the 2/3 million hits per day mark. I've been running Tomcat since march 2000, starting with 3.2.1. I think with a little of involvment it is easy to set up a high availability environment using Apache/Tomcat and maybe hardware load balancers. Maybe what is missing is a good tutorial on such a setup. Maybe I could start thinking about writing something about our setup. We came up with neat tricks to handle live application upgrade and this sort of things. I don't know where this could fit in but it is definitely the kind of HOWTO that could be good for the spread of Tomcat on production environments. As for the pure servlet speed Tomcat can deliver, from what I see everyday, the bottleneck is usually in the data tier and not in the application server, so this is a purely sterile debate in my opinion. Just my 2 cents of euro worth. Mathias. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: HA tomcat ( was: RE: 5.0 proposal)
On Tue, 25 Jun 2002, Huy Tran wrote: Mathias, Thanks for the encouraged news. We've been using Tomcat in our product for a while now. Now, I need to set it up with support for minimum 100K simultaneous connection to our server side. If you could share some of your knowledge how you did it with your site, it would be tremendously helpful for me and many other Tomcat user out there. 100k simultaneous connections ??? Well, that's a lot. Depending on the request and hardware, you could run 1-200 RPS on one tomcat - but you would need a pretty large farm to load balance 100.000. I would use few hardware load balancers, and several apache boxes in front of the farm. Hopefully not all of the requests will be for dynamic content - so you may be able to handle it. But I've never seen 100.000 concurent users ( well, google probably has more - and is certainly not impossible - but it'll take some work ) Costin Regards, Huy Tran. Mathias Herberts wrote: [EMAIL PROTECTED] wrote: On Tue, 25 Jun 2002, GOMEZ Henri wrote: Pier could you detail what should be a Tomcat HA, and how it could fit in TC 5.0 proposal ? As far as I can remember it was voted -1... What about TC 5.0 with HA capability ? TC5.0 will have a 'higher availability' then 4.1 which is better than 4.0. Same goes for 3.3 versus 3.2, and so on. [snip] Well, I know quite a few people who managed to get tomcat in production on a variety of sites ( including very large loads). I run Tomcat on 20 or so production web sites, with volumes in the 2/3 million hits per day mark. I've been running Tomcat since march 2000, starting with 3.2.1. I think with a little of involvment it is easy to set up a high availability environment using Apache/Tomcat and maybe hardware load balancers. Maybe what is missing is a good tutorial on such a setup. Maybe I could start thinking about writing something about our setup. We came up with neat tricks to handle live application upgrade and this sort of things. I don't know where this could fit in but it is definitely the kind of HOWTO that could be good for the spread of Tomcat on production environments. As for the pure servlet speed Tomcat can deliver, from what I see everyday, the bottleneck is usually in the data tier and not in the application server, so this is a purely sterile debate in my opinion. Just my 2 cents of euro worth. Mathias. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: HA tomcat ( was: RE: 5.0 proposal)
Mathias, It would be great to see some details on your experiences with load-balancing Tomcat, and any tricks you've come up with would be much appreciated by the community (well, at least my part of it ;) We also run Tomcat 4.0 in production, behind a hardware load balancer. It's working great thus far, but we don't have nearly the traffic to require even the setup we have now, so I can't contribute an aweful lot except to say 'works-for-me' Aaron Dunlop -Original Message- From: Mathias Herberts [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 25, 2002 11:23 AM To: Tomcat Developers List Subject: Re: HA tomcat ( was: RE: 5.0 proposal) [snip] Well, I know quite a few people who managed to get tomcat in production on a variety of sites ( including very large loads). I run Tomcat on 20 or so production web sites, with volumes in the 2/3 million hits per day mark. I've been running Tomcat since march 2000, starting with 3.2.1. I think with a little of involvment it is easy to set up a high availability environment using Apache/Tomcat and maybe hardware load balancers. Maybe what is missing is a good tutorial on such a setup. Maybe I could start thinking about writing something about our setup. We came up with neat tricks to handle live application upgrade and this sort of things. I don't know where this could fit in but it is definitely the kind of HOWTO that could be good for the spread of Tomcat on production environments. As for the pure servlet speed Tomcat can deliver, from what I see everyday, the bottleneck is usually in the data tier and not in the application server, so this is a purely sterile debate in my opinion. Just my 2 cents of euro worth. Mathias. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: HA tomcat ( was: RE: 5.0 proposal)
Dunlop, Aaron wrote: Mathias, It would be great to see some details on your experiences with load-balancing Tomcat, and any tricks you've come up with would be much appreciated by the community (well, at least my part of it ;) We also run Tomcat 4.0 in production, behind a hardware load balancer. It's working great thus far, but we don't have nearly the traffic to require even the setup we have now, so I can't contribute an aweful lot except to say 'works-for-me' There's a link on that on the site: http://jakarta.apache.org/tomcat/resources.html Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
reflections of tomcat 5.0 proposal
Hello, For what it is worth, here is a quote from a famous person: The significant problems we face in life cannot be solved at the same level of thinking we were at when we created them Albert Einstein. There exists a problem of scaleability with Tomcat. To solve the problem, you will need to get to a new (or different) level of thinking then what you are at now. It is a simple solution if people are willing to pay the price of change. Thank you. -- Brian Millett Enterprise Consulting Group Shifts in paradigms (314) 205-9030 often cause nose bleeds. [EMAIL PROTECTED] Greg Glenn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
5.0 proposal
It seems we have 3 -1 votes so far. While majority is required, I think we all agree that getting everyone ( reasonable ) involved and comfortable with the proposal is very important ( and one of the goals of 5.0 ). Christopher: I think we should add your requirement for performance testing to the proposal. In fact, we should add a whole section about testing for 5.0. Would this satisfy you ? Glenn - I'm not sure what you ask for. The proposal adds no new features (except the new servlet api), and we obviously can't implement the next spec unless it's public. I understand your concern about the time - but given that the code will be shared ( i.e. existing code ) I don't think it should take years to get it done. Is there any particular requirement you want to add to the proposal ? For everyone - the proposal is in CVS, and everyone can contribute to it. One of the main goals is to improve the community, and that means we should be more sensitive to other needs. If you have an itch, please add it to the plan, as a goal for 5.0 ( some may not happen in 5.0.0 ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: 5.0 proposal
[EMAIL PROTECTED] wrote: It seems we have 3 -1 votes so far. While majority is required, I think we all agree that getting everyone ( reasonable ) involved and comfortable with the proposal is very important ( and one of the goals of 5.0 ). +1. Christopher: I think we should add your requirement for performance testing to the proposal. In fact, we should add a whole section about testing for 5.0. Would this satisfy you ? +1 to start a new commons subproject. If everyone else wants to see the bench webapp here, then I'll remove my -1. However, it sounds generic, and not at all dependent on Tomcat, so that's why I think it would be a lot better in the commons. Glenn - I'm not sure what you ask for. The proposal adds no new features (except the new servlet api), and we obviously can't implement the next spec unless it's public. I understand your concern about the time - but given that the code will be shared ( i.e. existing code ) I don't think it should take years to get it done. Is there any particular requirement you want to add to the proposal ? I added some details about the changes. For everyone - the proposal is in CVS, and everyone can contribute to it. One of the main goals is to improve the community, and that means we should be more sensitive to other needs. If you have an itch, please add it to the plan, as a goal for 5.0 ( some may not happen in 5.0.0 ). Not many of the negative comments posted actually contained any suggestions, so I didn't see much worth integrating, except Glenn's comments about lack of detail. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: 5.0 proposal
On Mon, 24 Jun 2002, Remy Maucherat wrote: +1 to start a new commons subproject. If everyone else wants to see the bench webapp here, then I'll remove my -1. However, it sounds generic, and not at all dependent on Tomcat, so that's why I think it would be a lot better in the commons. Maybe watchdog would be a better place for it ( or a -tomcat repository for all tests ) ? Fact is testing tomcat is important and performance is one of the test categories. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: 5.0 proposal
Remy Maucherat wrote: [EMAIL PROTECTED] wrote: It seems we have 3 -1 votes so far. While majority is required, I think we all agree that getting everyone ( reasonable ) involved and comfortable with the proposal is very important ( and one of the goals of 5.0 ). +1. Christopher: I think we should add your requirement for performance testing to the proposal. In fact, we should add a whole section about testing for 5.0. Would this satisfy you ? +1 to start a new commons subproject. How about making it part of JMeter? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
