You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Remy Maucherat <re...@apache.org> on 2002/03/13 03:30:23 UTC
[PROPOSAL] Proposed integration of Coyote in 4.0-HEAD
There are many ways to take advantage of Coyote in Tomcat 4, but I'd like to
start with some limited changes at first. Most of these proposed changes are
Coyote-related (hence the subject of the message), and all involve some
refactoring / API additions.
A) URI decoding refactoring. To avoid doing some URI decoding in many places
in the pipeline, a decodedURI field (with associated getter/setter) should
be added in the HttpRequest interface, and used in the Catalina pipeline.
This also has the advantage to guarantee that no double URI decoding occurs
(which can lead to URI-based security attacks).
<ballot>
[ ] +1
[ ] +0
[ ] -1:
</ballot>
B) Use Coyote as the default HTTP connector in 4.0-HEAD, replacing the old
connector, which has many shortcoming (slow performance on output, HTTP
handling limitations and extreme complexity). Initial tests results and
benchmarks with Coyote are extremely positive so far.
<ballot>
[ ] +1
[ ] +0
[ ] -1:
</ballot>
C) Add better lifecycle handling in the resources. A start method is needed
(which could be called 'allocate' to mirror the 'release' method), because
it is currently not possible to restart a stopped context. In the 4.0
branch, the patch introducing the 'release' method must either be reverted,
or these proposed changes must also be ported to 4.0.
Thanks to Jean-Francois Clere for the report and debugging of this problem.
<ballot>
[ ] +1
[ ] +0
[ ] -1:
</ballot>
D) Deprecate the o.a.catalina.connector package. This package *SHOULD NOT*
be used for any new connector development. To make this more obvious, I'd
like to deprecate all classes in this package and subpackages. The binaries
will also be packaged in a separate JAR file (tentatively named
catalina-legacy.jar). This package will continue to be maintained on a case
by case basis. The facades will not be deprecated, and two new helper
objects will be introduced to handle the need for "fake" req/resp when
requesting a JSP precompilation with a load-on-startup (see bug 4518 for
more details).
<ballot>
[ ] +1
[ ] +0
[ ] -1:
</ballot>
E) Use commons-logging in Coyote, by adding a get/setLogger on the Processor
interface. Otherwise, the processor has no way to cleanly handle logging.
commons-logging is already used by other j-t-c components. At the moment,
the HTTP/1.1 processor "logs" problems as stack traces on the stderr; this
needs to be improved. When I originally designed most of the base
interfaces, commons-logging didn't exist yet, and I didn't feel like adding
yet another logging interface.
<ballot>
[ ] +1
[ ] +0
[ ] -1:
</ballot>
+1 for everything. Thanks for voting / commenting :)
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD
Posted by Patrick Luby <pa...@sun.com>.
Remy,
+1 for all.
Patrick
Remy Maucherat wrote:
>
> There are many ways to take advantage of Coyote in Tomcat 4, but I'd like to
> start with some limited changes at first. Most of these proposed changes are
> Coyote-related (hence the subject of the message), and all involve some
> refactoring / API additions.
>
> A) URI decoding refactoring. To avoid doing some URI decoding in many places
> in the pipeline, a decodedURI field (with associated getter/setter) should
> be added in the HttpRequest interface, and used in the Catalina pipeline.
> This also has the advantage to guarantee that no double URI decoding occurs
> (which can lead to URI-based security attacks).
>
> <ballot>
> [ ] +1
> [ ] +0
> [ ] -1:
>
> </ballot>
>
> B) Use Coyote as the default HTTP connector in 4.0-HEAD, replacing the old
> connector, which has many shortcoming (slow performance on output, HTTP
> handling limitations and extreme complexity). Initial tests results and
> benchmarks with Coyote are extremely positive so far.
>
> <ballot>
> [ ] +1
> [ ] +0
> [ ] -1:
>
> </ballot>
>
> C) Add better lifecycle handling in the resources. A start method is needed
> (which could be called 'allocate' to mirror the 'release' method), because
> it is currently not possible to restart a stopped context. In the 4.0
> branch, the patch introducing the 'release' method must either be reverted,
> or these proposed changes must also be ported to 4.0.
> Thanks to Jean-Francois Clere for the report and debugging of this problem.
>
> <ballot>
> [ ] +1
> [ ] +0
> [ ] -1:
>
> </ballot>
>
> D) Deprecate the o.a.catalina.connector package. This package *SHOULD NOT*
> be used for any new connector development. To make this more obvious, I'd
> like to deprecate all classes in this package and subpackages. The binaries
> will also be packaged in a separate JAR file (tentatively named
> catalina-legacy.jar). This package will continue to be maintained on a case
> by case basis. The facades will not be deprecated, and two new helper
> objects will be introduced to handle the need for "fake" req/resp when
> requesting a JSP precompilation with a load-on-startup (see bug 4518 for
> more details).
>
> <ballot>
> [ ] +1
> [ ] +0
> [ ] -1:
>
> </ballot>
>
> E) Use commons-logging in Coyote, by adding a get/setLogger on the Processor
> interface. Otherwise, the processor has no way to cleanly handle logging.
> commons-logging is already used by other j-t-c components. At the moment,
> the HTTP/1.1 processor "logs" problems as stack traces on the stderr; this
> needs to be improved. When I originally designed most of the base
> interfaces, commons-logging didn't exist yet, and I didn't feel like adding
> yet another logging interface.
>
> <ballot>
> [ ] +1
> [ ] +0
> [ ] -1:
>
> </ballot>
>
> +1 for everything. Thanks for voting / commenting :)
>
> Remy
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
_____________________________________________________________________
Patrick Luby Email: patrick.luby@sun.com
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
_____________________________________________________________________
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Remy Maucherat wrote:
>
> There are many ways to take advantage of Coyote in Tomcat 4, but I'd like to
> start with some limited changes at first. Most of these proposed changes are
> Coyote-related (hence the subject of the message), and all involve some
> refactoring / API additions.
>
> A) URI decoding refactoring. To avoid doing some URI decoding in many places
> in the pipeline, a decodedURI field (with associated getter/setter) should
> be added in the HttpRequest interface, and used in the Catalina pipeline.
> This also has the advantage to guarantee that no double URI decoding occurs
> (which can lead to URI-based security attacks).
>
> <ballot>
> [X] +1
> [ ] +0
> [ ] -1:
>
> </ballot>
>
> B) Use Coyote as the default HTTP connector in 4.0-HEAD, replacing the old
> connector, which has many shortcoming (slow performance on output, HTTP
> handling limitations and extreme complexity). Initial tests results and
> benchmarks with Coyote are extremely positive so far.
>
> <ballot>
> [X] +1
> [ ] +0
> [ ] -1:
>
> </ballot>
>
> C) Add better lifecycle handling in the resources. A start method is needed
> (which could be called 'allocate' to mirror the 'release' method), because
> it is currently not possible to restart a stopped context. In the 4.0
> branch, the patch introducing the 'release' method must either be reverted,
> or these proposed changes must also be ported to 4.0.
> Thanks to Jean-Francois Clere for the report and debugging of this problem.
Typo in my first name!
The bug is 6982. Porting the changes is what I prefer.
>
> <ballot>
> [X] +1
> [ ] +0
> [ ] -1:
>
> </ballot>
>
> D) Deprecate the o.a.catalina.connector package. This package *SHOULD NOT*
> be used for any new connector development. To make this more obvious, I'd
> like to deprecate all classes in this package and subpackages. The binaries
> will also be packaged in a separate JAR file (tentatively named
> catalina-legacy.jar). This package will continue to be maintained on a case
> by case basis. The facades will not be deprecated, and two new helper
> objects will be introduced to handle the need for "fake" req/resp when
> requesting a JSP precompilation with a load-on-startup (see bug 4518 for
> more details).
>
> <ballot>
> [X] +1
> [ ] +0
> [ ] -1:
>
> </ballot>
>
> E) Use commons-logging in Coyote, by adding a get/setLogger on the Processor
> interface. Otherwise, the processor has no way to cleanly handle logging.
> commons-logging is already used by other j-t-c components. At the moment,
> the HTTP/1.1 processor "logs" problems as stack traces on the stderr; this
> needs to be improved. When I originally designed most of the base
> interfaces, commons-logging didn't exist yet, and I didn't feel like adding
> yet another logging interface.
>
> <ballot>
> [X] +1
> [ ] +0
> [ ] -1:
>
> </ballot>
>
> +1 for everything. Thanks for voting / commenting :)
>
> Remy
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD
Posted by Remy Maucherat <re...@apache.org>.
> On Tue, 12 Mar 2002, Remy Maucherat wrote:
>
> > Also, I'm about to add in the TC 4 adapter the code used in TC 4 to
prevent
> > some URL based attacks (with a flag allowing to disable the checks,
though,
> > as this may be useless in the HEAD branch after the proposed
refactoring).
> > However, I know that TC 3.3 has that kind of nomalization code also, so
> > maybe you should check to be sure you don't need it (maybe in 3.3 it's
not
> > part of the connector; I don't remember).
>
> No, the charset decoding is in DecodingInterceptor and is independent of
> connector.
>
> The connectors only deals with receiving/sending bytes, they have no idea
> about encodings or chars. The encoding may well be stored in the servlet
> session ( this is the only reliable way to deal with current browsers ),
> and in 2.3 it may be specified by the user.
>
> Having a 'decoded' field in the Request is very usefull, but computing it
> in the connector would be a mistake IMHO, as it'll potentially require
> access to higher layers.
>
> BTW, there is some decoding that may be required ( when Strings are
> still used ), but the real decoder will set the right charset and may
> reconvert.
>
> URL decoding is also included in the main decoder, but can be done
> in the connector.
Yes, I agree with that. I've just added the call to your URL decoding method
in the processor. No char decoding there (too many things are called the
same; it's confusing).
> > > > <ballot>
> > > > [X] +1 I'm guessing that Costin & Larry will have fits with this (TC
3.3
> > > currently has no dependencies on outside packages). However, my
support
> > is
> > > only if it gets into o.a.c.Processor. It shouldn't be a http11 only
> > issue.
> > > > [ ] +0
> > > > [ ] -1:
> > > >
> > > > </ballot>
> >
> > Yes, that's a good point. JK 2 is using commons-logging already, so I
think
> > the dependency on that component is inevitable no matter what. I'd
rather
> > live without it, but I'm very unhappy at the moment of having no logging
at
> > all inside the processor.
> > Yes, the get/setLogger will go in the Processor interface.
>
> Jk2 is using commons logging interfaces. Note that the model is based on
> pull, not push - so get/setLogger are not needed.
Ok, I'll look at the code, try to use commons-logging, and see if the
get/setLogger is really needed.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD
Posted by co...@covalent.net.
On Tue, 12 Mar 2002, Remy Maucherat wrote:
> Also, I'm about to add in the TC 4 adapter the code used in TC 4 to prevent
> some URL based attacks (with a flag allowing to disable the checks, though,
> as this may be useless in the HEAD branch after the proposed refactoring).
> However, I know that TC 3.3 has that kind of nomalization code also, so
> maybe you should check to be sure you don't need it (maybe in 3.3 it's not
> part of the connector; I don't remember).
No, the charset decoding is in DecodingInterceptor and is independent of
connector.
The connectors only deals with receiving/sending bytes, they have no idea
about encodings or chars. The encoding may well be stored in the servlet
session ( this is the only reliable way to deal with current browsers ),
and in 2.3 it may be specified by the user.
Having a 'decoded' field in the Request is very usefull, but computing it
in the connector would be a mistake IMHO, as it'll potentially require
access to higher layers.
BTW, there is some decoding that may be required ( when Strings are
still used ), but the real decoder will set the right charset and may
reconvert.
URL decoding is also included in the main decoder, but can be done
in the connector.
> > > <ballot>
> > > [X] +1 I'm guessing that Costin & Larry will have fits with this (TC 3.3
> > currently has no dependencies on outside packages). However, my support
> is
> > only if it gets into o.a.c.Processor. It shouldn't be a http11 only
> issue.
> > > [ ] +0
> > > [ ] -1:
> > >
> > > </ballot>
>
> Yes, that's a good point. JK 2 is using commons-logging already, so I think
> the dependency on that component is inevitable no matter what. I'd rather
> live without it, but I'm very unhappy at the moment of having no logging at
> all inside the processor.
> Yes, the get/setLogger will go in the Processor interface.
Jk2 is using commons logging interfaces. Note that the model is based on
pull, not push - so get/setLogger are not needed.
The main benefits over current 3.3 logging - it allows much finer
granularity for logging/info and already supports log4j/jdk1.4.
My plan is to do a small performance test on QLog vs. log4j/1.4,
and if the results are positive ( QLog has few features, but is
quite 'tuned' ) make QLogger implement commons logging.
3.3 has no dependencies external to apache - jaxp is required
( but easy to replace the impl with a smaller one ), and
each module may have its own dependencies (jk2->logging).
I do plan to add a dependency jk2->openjmx, at the moment it
seems the best way to provide runtime manageability of the
connector and the recent changes in the C side are in this
direction ( i.e. jk2 will have a proxy/remote mbean that
will manage mod_jk )
The commons-logging 'core' is comparable in size and power
with tomcat.util.log, so I see no problem moving to
a common log.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD
Posted by Remy Maucherat <re...@apache.org>.
> > A) URI decoding refactoring. To avoid doing some URI decoding in many
> places
> > in the pipeline, a decodedURI field (with associated getter/setter)
should
> > be added in the HttpRequest interface, and used in the Catalina
pipeline.
> > This also has the advantage to guarantee that no double URI decoding
> occurs
> > (which can lead to URI-based security attacks).
> >
> > <ballot>
> > [ ] +1
> > [X] +0 Already in the 3.3 code (and currently ignored in the 3.3
Adapter).
> > [ ] -1:
Good, then you'll be able to use that field in TC 3 (the HTTP/1.1 should now
populate it, and it uses the same decoder TC 3 uses; no surprise here).
Also, I'm about to add in the TC 4 adapter the code used in TC 4 to prevent
some URL based attacks (with a flag allowing to disable the checks, though,
as this may be useless in the HEAD branch after the proposed refactoring).
However, I know that TC 3.3 has that kind of nomalization code also, so
maybe you should check to be sure you don't need it (maybe in 3.3 it's not
part of the connector; I don't remember).
> > D) Deprecate the o.a.catalina.connector package. This package *SHOULD
NOT*
> > be used for any new connector development. To make this more obvious,
I'd
> > like to deprecate all classes in this package and subpackages. The
> binaries
> > will also be packaged in a separate JAR file (tentatively named
> > catalina-legacy.jar). This package will continue to be maintained on a
> case
> > by case basis. The facades will not be deprecated, and two new helper
> > objects will be introduced to handle the need for "fake" req/resp when
> > requesting a JSP precompilation with a load-on-startup (see bug 4518 for
> > more details).
> >
> > <ballot>
> > [X] +1 I couldn't ever find the "fake" req/resp for 4518 (ok, in 3.3
> land, any class that ends in "Base" is an abstract class. ;-)
> > [ ] +0
> > [ ] -1:
> >
> > </ballot>
Here, I got lucky and was able to just use HttpRequestBase/HttpResponseBase,
just populate a few fields and have it work. Obviously, it is a complete
hack, so I plan to add some dummy request/response objects which could be
used for this instead.
> > E) Use commons-logging in Coyote, by adding a get/setLogger on the
> Processor
> > interface. Otherwise, the processor has no way to cleanly handle
logging.
> > commons-logging is already used by other j-t-c components. At the
moment,
> > the HTTP/1.1 processor "logs" problems as stack traces on the stderr;
this
> > needs to be improved. When I originally designed most of the base
> > interfaces, commons-logging didn't exist yet, and I didn't feel like
> adding
> > yet another logging interface.
> >
> > <ballot>
> > [X] +1 I'm guessing that Costin & Larry will have fits with this (TC 3.3
> currently has no dependencies on outside packages). However, my support
is
> only if it gets into o.a.c.Processor. It shouldn't be a http11 only
issue.
> > [ ] +0
> > [ ] -1:
> >
> > </ballot>
Yes, that's a good point. JK 2 is using commons-logging already, so I think
the dependency on that component is inevitable no matter what. I'd rather
live without it, but I'm very unhappy at the moment of having no logging at
all inside the processor.
Yes, the get/setLogger will go in the Processor interface.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD
Posted by Bill Barker <wb...@wilshire.com>.
Disclaimer:
A +1 vote below does not necessarily mean that I'm going to pledge ongoing
support to o.a.c.tomcat4 (although it is very well done, and I relied
heavily on it for developing o.a.c.tomcat3). However, I do plan to support
o.a.c and o.a.c.http11.
----- Original Message -----
From: "Remy Maucherat" <re...@apache.org>
To: <to...@jakarta.apache.org>
Sent: Tuesday, March 12, 2002 6:30 PM
Subject: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD
> There are many ways to take advantage of Coyote in Tomcat 4, but I'd like
to
> start with some limited changes at first. Most of these proposed changes
are
> Coyote-related (hence the subject of the message), and all involve some
> refactoring / API additions.
>
> A) URI decoding refactoring. To avoid doing some URI decoding in many
places
> in the pipeline, a decodedURI field (with associated getter/setter) should
> be added in the HttpRequest interface, and used in the Catalina pipeline.
> This also has the advantage to guarantee that no double URI decoding
occurs
> (which can lead to URI-based security attacks).
>
> <ballot>
> [ ] +1
> [X] +0 Already in the 3.3 code (and currently ignored in the 3.3 Adapter).
> [ ] -1:
>
> </ballot>
>
> B) Use Coyote as the default HTTP connector in 4.0-HEAD, replacing the old
> connector, which has many shortcoming (slow performance on output, HTTP
> handling limitations and extreme complexity). Initial tests results and
> benchmarks with Coyote are extremely positive so far.
>
> <ballot>
> [X] +1
> [ ] +0
> [ ] -1:
>
> </ballot>
>
> C) Add better lifecycle handling in the resources. A start method is
needed
> (which could be called 'allocate' to mirror the 'release' method), because
> it is currently not possible to restart a stopped context. In the 4.0
> branch, the patch introducing the 'release' method must either be
reverted,
> or these proposed changes must also be ported to 4.0.
> Thanks to Jean-Francois Clere for the report and debugging of this
problem.
>
> <ballot>
> [X] +1
> [ ] +0
> [ ] -1:
>
> </ballot>
>
> D) Deprecate the o.a.catalina.connector package. This package *SHOULD NOT*
> be used for any new connector development. To make this more obvious, I'd
> like to deprecate all classes in this package and subpackages. The
binaries
> will also be packaged in a separate JAR file (tentatively named
> catalina-legacy.jar). This package will continue to be maintained on a
case
> by case basis. The facades will not be deprecated, and two new helper
> objects will be introduced to handle the need for "fake" req/resp when
> requesting a JSP precompilation with a load-on-startup (see bug 4518 for
> more details).
>
> <ballot>
> [X] +1 I couldn't ever find the "fake" req/resp for 4518 (ok, in 3.3
land, any class that ends in "Base" is an abstract class. ;-)
> [ ] +0
> [ ] -1:
>
> </ballot>
>
> E) Use commons-logging in Coyote, by adding a get/setLogger on the
Processor
> interface. Otherwise, the processor has no way to cleanly handle logging.
> commons-logging is already used by other j-t-c components. At the moment,
> the HTTP/1.1 processor "logs" problems as stack traces on the stderr; this
> needs to be improved. When I originally designed most of the base
> interfaces, commons-logging didn't exist yet, and I didn't feel like
adding
> yet another logging interface.
>
> <ballot>
> [X] +1 I'm guessing that Costin & Larry will have fits with this (TC 3.3
currently has no dependencies on outside packages). However, my support is
only if it gets into o.a.c.Processor. It shouldn't be a http11 only issue.
> [ ] +0
> [ ] -1:
>
> </ballot>
>
> +1 for everything. Thanks for voting / commenting :)
>
> Remy
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Tomcat Connector
Posted by jferna57 <jf...@pie.xtec.es>.
Hi,
I would like to connect Tomcat with a Secure Web Server deployed by my
company, but for security, I would not like that Tomcat open a socket
connection.
Can anyone help me?
Thanks.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
"Craig R. McClanahan" wrote:
>
> +1 for all, with an expansion on the last point.
>
> Currently, Tomcat components all use the internal Logger APIs for logging
> both container event and error messages, as well as those from the web
> applications that are being run (i.e. calls to ServletContext.log()).
> What would people think of migrating the container components of the HEAD
> branch to use commons-logging, as well as having Coyote do that?
1+
>
> The most interesting technical part of this is that multiple instances of
> many of the components (such as StandardContext) are used in a pretty much
> autonomous manner, and you might want to have different logging levels for
> different instances. I think we can can deal with this by creating naming
> of the underlying loggers, but wanted to gauge opinions before putting
> together a proposal for that.
>
> Craig
>
> On Tue, 12 Mar 2002, Remy Maucherat wrote:
>
> > Date: Tue, 12 Mar 2002 18:30:23 -0800
> > From: Remy Maucherat <re...@apache.org>
> > Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
> > To: tomcat-dev@jakarta.apache.org
> > Subject: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD
> >
> > There are many ways to take advantage of Coyote in Tomcat 4, but I'd like to
> > start with some limited changes at first. Most of these proposed changes are
> > Coyote-related (hence the subject of the message), and all involve some
> > refactoring / API additions.
> >
> > A) URI decoding refactoring. To avoid doing some URI decoding in many places
> > in the pipeline, a decodedURI field (with associated getter/setter) should
> > be added in the HttpRequest interface, and used in the Catalina pipeline.
> > This also has the advantage to guarantee that no double URI decoding occurs
> > (which can lead to URI-based security attacks).
> >
> > <ballot>
> > [ ] +1
> > [ ] +0
> > [ ] -1:
> >
> > </ballot>
> >
> > B) Use Coyote as the default HTTP connector in 4.0-HEAD, replacing the old
> > connector, which has many shortcoming (slow performance on output, HTTP
> > handling limitations and extreme complexity). Initial tests results and
> > benchmarks with Coyote are extremely positive so far.
> >
> > <ballot>
> > [ ] +1
> > [ ] +0
> > [ ] -1:
> >
> > </ballot>
> >
> > C) Add better lifecycle handling in the resources. A start method is needed
> > (which could be called 'allocate' to mirror the 'release' method), because
> > it is currently not possible to restart a stopped context. In the 4.0
> > branch, the patch introducing the 'release' method must either be reverted,
> > or these proposed changes must also be ported to 4.0.
> > Thanks to Jean-Francois Clere for the report and debugging of this problem.
> >
> > <ballot>
> > [ ] +1
> > [ ] +0
> > [ ] -1:
> >
> > </ballot>
> >
> > D) Deprecate the o.a.catalina.connector package. This package *SHOULD NOT*
> > be used for any new connector development. To make this more obvious, I'd
> > like to deprecate all classes in this package and subpackages. The binaries
> > will also be packaged in a separate JAR file (tentatively named
> > catalina-legacy.jar). This package will continue to be maintained on a case
> > by case basis. The facades will not be deprecated, and two new helper
> > objects will be introduced to handle the need for "fake" req/resp when
> > requesting a JSP precompilation with a load-on-startup (see bug 4518 for
> > more details).
> >
> > <ballot>
> > [ ] +1
> > [ ] +0
> > [ ] -1:
> >
> > </ballot>
> >
> > E) Use commons-logging in Coyote, by adding a get/setLogger on the Processor
> > interface. Otherwise, the processor has no way to cleanly handle logging.
> > commons-logging is already used by other j-t-c components. At the moment,
> > the HTTP/1.1 processor "logs" problems as stack traces on the stderr; this
> > needs to be improved. When I originally designed most of the base
> > interfaces, commons-logging didn't exist yet, and I didn't feel like adding
> > yet another logging interface.
> >
> > <ballot>
> > [ ] +1
> > [ ] +0
> > [ ] -1:
> >
> > </ballot>
> >
> > +1 for everything. Thanks for voting / commenting :)
> >
> > Remy
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
> >
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 13 Mar 2002, Craig R. McClanahan wrote:
>
> I think we can can deal with this by creating naming
Err, that was supposed to be "creative" naming ...
> of the underlying loggers, but wanted to gauge opinions before putting
> together a proposal for that.
>
> Craig
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD
Posted by "Craig R. McClanahan" <cr...@apache.org>.
+1 for all, with an expansion on the last point.
Currently, Tomcat components all use the internal Logger APIs for logging
both container event and error messages, as well as those from the web
applications that are being run (i.e. calls to ServletContext.log()).
What would people think of migrating the container components of the HEAD
branch to use commons-logging, as well as having Coyote do that?
The most interesting technical part of this is that multiple instances of
many of the components (such as StandardContext) are used in a pretty much
autonomous manner, and you might want to have different logging levels for
different instances. I think we can can deal with this by creating naming
of the underlying loggers, but wanted to gauge opinions before putting
together a proposal for that.
Craig
On Tue, 12 Mar 2002, Remy Maucherat wrote:
> Date: Tue, 12 Mar 2002 18:30:23 -0800
> From: Remy Maucherat <re...@apache.org>
> Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
> To: tomcat-dev@jakarta.apache.org
> Subject: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD
>
> There are many ways to take advantage of Coyote in Tomcat 4, but I'd like to
> start with some limited changes at first. Most of these proposed changes are
> Coyote-related (hence the subject of the message), and all involve some
> refactoring / API additions.
>
> A) URI decoding refactoring. To avoid doing some URI decoding in many places
> in the pipeline, a decodedURI field (with associated getter/setter) should
> be added in the HttpRequest interface, and used in the Catalina pipeline.
> This also has the advantage to guarantee that no double URI decoding occurs
> (which can lead to URI-based security attacks).
>
> <ballot>
> [ ] +1
> [ ] +0
> [ ] -1:
>
> </ballot>
>
> B) Use Coyote as the default HTTP connector in 4.0-HEAD, replacing the old
> connector, which has many shortcoming (slow performance on output, HTTP
> handling limitations and extreme complexity). Initial tests results and
> benchmarks with Coyote are extremely positive so far.
>
> <ballot>
> [ ] +1
> [ ] +0
> [ ] -1:
>
> </ballot>
>
> C) Add better lifecycle handling in the resources. A start method is needed
> (which could be called 'allocate' to mirror the 'release' method), because
> it is currently not possible to restart a stopped context. In the 4.0
> branch, the patch introducing the 'release' method must either be reverted,
> or these proposed changes must also be ported to 4.0.
> Thanks to Jean-Francois Clere for the report and debugging of this problem.
>
> <ballot>
> [ ] +1
> [ ] +0
> [ ] -1:
>
> </ballot>
>
> D) Deprecate the o.a.catalina.connector package. This package *SHOULD NOT*
> be used for any new connector development. To make this more obvious, I'd
> like to deprecate all classes in this package and subpackages. The binaries
> will also be packaged in a separate JAR file (tentatively named
> catalina-legacy.jar). This package will continue to be maintained on a case
> by case basis. The facades will not be deprecated, and two new helper
> objects will be introduced to handle the need for "fake" req/resp when
> requesting a JSP precompilation with a load-on-startup (see bug 4518 for
> more details).
>
> <ballot>
> [ ] +1
> [ ] +0
> [ ] -1:
>
> </ballot>
>
> E) Use commons-logging in Coyote, by adding a get/setLogger on the Processor
> interface. Otherwise, the processor has no way to cleanly handle logging.
> commons-logging is already used by other j-t-c components. At the moment,
> the HTTP/1.1 processor "logs" problems as stack traces on the stderr; this
> needs to be improved. When I originally designed most of the base
> interfaces, commons-logging didn't exist yet, and I didn't feel like adding
> yet another logging interface.
>
> <ballot>
> [ ] +1
> [ ] +0
> [ ] -1:
>
> </ballot>
>
> +1 for everything. Thanks for voting / commenting :)
>
> Remy
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Remy Maucherat" <re...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Tuesday, March 12, 2002 9:26 PM
Subject: Re: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD
> > on 3/12/02 6:30 PM, "Remy Maucherat" <re...@apache.org> wrote:
> >
> > > A) URI decoding refactoring. To avoid doing some URI decoding in many
> places
> > > in the pipeline, a decodedURI field (with associated getter/setter)
> should
> > > be added in the HttpRequest interface, and used in the Catalina
> pipeline.
> > > This also has the advantage to guarantee that no double URI decoding
> occurs
> > > (which can lead to URI-based security attacks).
> > >
> > > <ballot>
> > > [ ] +1
> > > [ ] +0
> > > [ ] -1:
> > >
> > > </ballot>
> >
> > Q: How can you modify the Servlet API interfaces?
>
> Well, it's not Http*Servlet*Request ;-)
> It's the internal Catalina API, and I'm just proposing to add a method to
it
> (servlets can't access it, but components of the Catalina core can).
>
+1 by the way.
Jon is confusing issues here. The "encoding" here refers to URLs like:
/foobar/%3F.jsp
The methods request.encodeURL(...) work (much/exactly) the same in Coyote
4.x and 3.x as they did before.
> Remy
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD
Posted by Remy Maucherat <re...@apache.org>.
> on 3/12/02 6:30 PM, "Remy Maucherat" <re...@apache.org> wrote:
>
> > A) URI decoding refactoring. To avoid doing some URI decoding in many
places
> > in the pipeline, a decodedURI field (with associated getter/setter)
should
> > be added in the HttpRequest interface, and used in the Catalina
pipeline.
> > This also has the advantage to guarantee that no double URI decoding
occurs
> > (which can lead to URI-based security attacks).
> >
> > <ballot>
> > [ ] +1
> > [ ] +0
> > [ ] -1:
> >
> > </ballot>
>
> Q: How can you modify the Servlet API interfaces?
Well, it's not Http*Servlet*Request ;-)
It's the internal Catalina API, and I'm just proposing to add a method to it
(servlets can't access it, but components of the Catalina core can).
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 3/12/02 6:30 PM, "Remy Maucherat" <re...@apache.org> wrote:
> A) URI decoding refactoring. To avoid doing some URI decoding in many places
> in the pipeline, a decodedURI field (with associated getter/setter) should
> be added in the HttpRequest interface, and used in the Catalina pipeline.
> This also has the advantage to guarantee that no double URI decoding occurs
> (which can lead to URI-based security attacks).
>
> <ballot>
> [ ] +1
> [ ] +0
> [ ] -1:
>
> </ballot>
Q: How can you modify the Servlet API interfaces?
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD
Posted by co...@covalent.net.
+1 for everything
Costin
On Tue, 12 Mar 2002, Remy Maucherat wrote:
> There are many ways to take advantage of Coyote in Tomcat 4, but I'd like to
> start with some limited changes at first. Most of these proposed changes are
> Coyote-related (hence the subject of the message), and all involve some
> refactoring / API additions.
>
> A) URI decoding refactoring. To avoid doing some URI decoding in many places
> in the pipeline, a decodedURI field (with associated getter/setter) should
> be added in the HttpRequest interface, and used in the Catalina pipeline.
> This also has the advantage to guarantee that no double URI decoding occurs
> (which can lead to URI-based security attacks).
>
> <ballot>
> [ ] +1
> [ ] +0
> [ ] -1:
>
> </ballot>
>
> B) Use Coyote as the default HTTP connector in 4.0-HEAD, replacing the old
> connector, which has many shortcoming (slow performance on output, HTTP
> handling limitations and extreme complexity). Initial tests results and
> benchmarks with Coyote are extremely positive so far.
>
> <ballot>
> [ ] +1
> [ ] +0
> [ ] -1:
>
> </ballot>
>
> C) Add better lifecycle handling in the resources. A start method is needed
> (which could be called 'allocate' to mirror the 'release' method), because
> it is currently not possible to restart a stopped context. In the 4.0
> branch, the patch introducing the 'release' method must either be reverted,
> or these proposed changes must also be ported to 4.0.
> Thanks to Jean-Francois Clere for the report and debugging of this problem.
>
> <ballot>
> [ ] +1
> [ ] +0
> [ ] -1:
>
> </ballot>
>
> D) Deprecate the o.a.catalina.connector package. This package *SHOULD NOT*
> be used for any new connector development. To make this more obvious, I'd
> like to deprecate all classes in this package and subpackages. The binaries
> will also be packaged in a separate JAR file (tentatively named
> catalina-legacy.jar). This package will continue to be maintained on a case
> by case basis. The facades will not be deprecated, and two new helper
> objects will be introduced to handle the need for "fake" req/resp when
> requesting a JSP precompilation with a load-on-startup (see bug 4518 for
> more details).
>
> <ballot>
> [ ] +1
> [ ] +0
> [ ] -1:
>
> </ballot>
>
> E) Use commons-logging in Coyote, by adding a get/setLogger on the Processor
> interface. Otherwise, the processor has no way to cleanly handle logging.
> commons-logging is already used by other j-t-c components. At the moment,
> the HTTP/1.1 processor "logs" problems as stack traces on the stderr; this
> needs to be improved. When I originally designed most of the base
> interfaces, commons-logging didn't exist yet, and I didn't feel like adding
> yet another logging interface.
>
> <ballot>
> [ ] +1
> [ ] +0
> [ ] -1:
>
> </ballot>
>
> +1 for everything. Thanks for voting / commenting :)
>
> Remy
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>