You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Tim Funk <fu...@joedog.org> on 2003/05/16 19:47:45 UTC
tc4 server.xml, remove WarpConnector declaration
Does anyone care if WarpConnector declaration is taken out of the default
server.xml for tomcat 4.1?
Since mod_webapp is unsupported it may be easier on a user if it is not
present in the default config. (even though it is commented out)
-Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] [PROPOSAL] Removing all old mappers
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> I've adapted the mapper to do the job of the context mapper. This will
> be used in the request dispatcher.
>
> On a broader perspective, the idea is to get rid of the old mapper
> design, support classes, etc.
> One of its goal was to support multiple protocols (more that one mapper
> per container). However, this turned out to be a non-goal (IMO), given
> that it doesn't comply with the behavior of the only non HTTP protocol
> used which I know is being used in a servlet container (SIP). The
> problem is that for one request, SIP can map many wrappers, and invoke
> them sequentially. That model, of course, doesn't fit too well with the
> Container map(...) method. So in the end, if it's just for mapping HTTP
> like requests, it can be done in a simpler and more efficient way (see
> the mapper in j-t-c/util).
>
> Mapping is only needed:
> - when the request gets out of the connector (done)
> - for request dispatcher mapping
> The Catalina Mapper is right now only used for request dispatcher mapping.
>
> Mapping is a performance problem in the current request dispatching
> implementation (that and the filter mapping, which is more generic and
> easier to optimize, since it's not as tightly embedded into the Catalina
> core design).
>
> My plan would be to:
> - Remove all current Catalina Mapper, implementations and APIs
> - Use the j-t-c/util mapper instead
> - Optimize filter mapping
+1
I don't think we'll see any "backward compatibility" problem - but in case
anyone was using the old mapper, we may have to do something.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] [PROPOSAL] Removing all old mappers
Posted by Remy Maucherat <re...@apache.org>.
Jean-Francois Arcand wrote:
>
>
> Remy Maucherat wrote:
>
> +1. I would like to add:
>
> - we come with an improved design for the filter mapping (when
> dispatcher equals error/forward). The current code is not enougth
> generic and "if cases" are distributed in several classes to make the
> mechanism working. If we can move all thoses workaround inside the
> Mapper (or add a new FilterMapper). that will be easier to maintains :-)
I think the mapping code can stay in AFilterFactory. It doesn't have
that much in common with the HTTP mapping, since you have to match all
filters (not just one). Some of the sub algorithms are the same (in
particular for extension match), and a little code can be reused.
Anyway, the current code is *very bad* and needs to go (it's called
substring abuse). I wonder how many substrings would get used if a
webapp uses say 5 filters, and the URL would look like
/some/long/url/a/b/c/d/e (well, unless all filters are mapped to /*; in
that case, there's an optimization, lol :-D). It sort of reminds me of
the old mapper, except in that case, the nasty stuff occurred only once
(here it's nFilters * nRDCalls).
I think I volunteered first for the task, BTW :) I think I should do it,
I have some experience dealing with mapping operations and the
j-t-c/util buffers now, so hopefully, I won't break things too bad.
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] [PROPOSAL] Removing all old mappers
Posted by Jean-Francois Arcand <jf...@apache.org>.
Remy Maucherat wrote:
> I've adapted the mapper to do the job of the context mapper. This will
> be used in the request dispatcher.
>
> On a broader perspective, the idea is to get rid of the old mapper
> design, support classes, etc.
> One of its goal was to support multiple protocols (more that one
> mapper per container). However, this turned out to be a non-goal
> (IMO), given that it doesn't comply with the behavior of the only non
> HTTP protocol used which I know is being used in a servlet container
> (SIP). The problem is that for one request, SIP can map many wrappers,
> and invoke them sequentially. That model, of course, doesn't fit too
> well with the Container map(...) method. So in the end, if it's just
> for mapping HTTP like requests, it can be done in a simpler and more
> efficient way (see the mapper in j-t-c/util).
>
> Mapping is only needed:
> - when the request gets out of the connector (done)
> - for request dispatcher mapping
> The Catalina Mapper is right now only used for request dispatcher
> mapping.
>
> Mapping is a performance problem in the current request dispatching
> implementation (that and the filter mapping, which is more generic and
> easier to optimize, since it's not as tightly embedded into the
> Catalina core design).
>
> My plan would be to:
> - Remove all current Catalina Mapper, implementations and APIs
> - Use the j-t-c/util mapper instead
> - Optimize filter mapping
>
> Comments ?
+1. I would like to add:
- we come with an improved design for the filter mapping (when
dispatcher equals error/forward). The current code is not enougth
generic and "if cases" are distributed in several classes to make the
mechanism working. If we can move all thoses workaround inside the
Mapper (or add a new FilterMapper). that will be easier to maintains :-)
-- Jeanfrancois
>
>
> Remy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
[5.0] [PROPOSAL] Removing all old mappers
Posted by Remy Maucherat <re...@apache.org>.
I've adapted the mapper to do the job of the context mapper. This will
be used in the request dispatcher.
On a broader perspective, the idea is to get rid of the old mapper
design, support classes, etc.
One of its goal was to support multiple protocols (more that one mapper
per container). However, this turned out to be a non-goal (IMO), given
that it doesn't comply with the behavior of the only non HTTP protocol
used which I know is being used in a servlet container (SIP). The
problem is that for one request, SIP can map many wrappers, and invoke
them sequentially. That model, of course, doesn't fit too well with the
Container map(...) method. So in the end, if it's just for mapping HTTP
like requests, it can be done in a simpler and more efficient way (see
the mapper in j-t-c/util).
Mapping is only needed:
- when the request gets out of the connector (done)
- for request dispatcher mapping
The Catalina Mapper is right now only used for request dispatcher mapping.
Mapping is a performance problem in the current request dispatching
implementation (that and the filter mapping, which is more generic and
easier to optimize, since it's not as tightly embedded into the Catalina
core design).
My plan would be to:
- Remove all current Catalina Mapper, implementations and APIs
- Use the j-t-c/util mapper instead
- Optimize filter mapping
Comments ?
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: tc4 server.xml, remove WarpConnector declaration
Posted by Costin Manolache <cm...@yahoo.com>.
Tim Funk wrote:
> Does anyone care if WarpConnector declaration is taken out of the default
> server.xml for tomcat 4.1?
>
> Since mod_webapp is unsupported it may be easier on a user if it is not
> present in the default config. (even though it is commented out)
>
>
> -Tim
+1
Also in server.xml in tomcat5 - we should probably remove the example
<Context> and move it to webapps/example.xml, and add a comment that
context declarations in server.xml are deprecated.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org