You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2002/05/02 06:19:58 UTC
RE: Which Connector for Tomcat 4.0.3 - mod_webapp or mod_jk
> I believe that the official stance is that mod_webapp will be the future
of
> Apache-tomcat connectors, and it will receive performance and feature
> improvements whereas ...
This appears to be one of the most common myths regarding Tomcat connectors.
The real official stance appears to be that mod_jk2 and mod_webapp are
competing projects from two groups of developers who don't agree with
others' code/approach.
AIUI, mod_webapp has been easier to configure; mod_jk offers load balancing,
and doesn't pass requests for static resources to Tomcat before letting
Apache handle them. mod_jk2 is getting even faster and easier to configure.
mod_webapp is getting patched to avoid passing static requests through
Tomcat first. mod_jk configuration is more similar to what those of us who
used mod_jserv know. mod_jk supports multiple worker types, including
in-process execution of Tomcat.
The biggest difference seems to be the deployment approach. When it comes
down to it, there is a difference between:
WebAppDeploy examples warpConnection /examples/
and
JkMount /*.jsp tomcat1
JkMount /examples/* tomcat1
mod_jk tells Apache about resources it should ask Tomcat to handle.
mod_webapp tells Apache about webapps that Tomcat should handle.
This really is a huge difference, if I understand the implications (without
reading through the code). For example, mod_jk won't know that we want
Tomcat to process a filter chain against a directory unless we've done a
JkMount for that tree, whereas it would know that Tomcat needs to process a
JSP page. On the other hand, mod_webapp would know about the filter chain
because the resources would have been deployed as part of a web app.
The respective developers are free to correct any of the above.
--- Noel
--
To unsubscribe: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>
Re: Which Connector for Tomcat 4.0.3 - mod_webapp or mod_jk
Posted by Simon Stewart <sm...@lateral.net>.
On Thu, May 02, 2002 at 09:55:29AM -0700, costinm@covalent.net wrote:
>
> One of the goals of mod_jk2 is to go further and be able to operate with
> only 'standard' apache directives and configuration ( i.e. <Location> and
> SetHandler ). That'll be much faster and easier to integrate - but even
> more verbose. However that's just one option, for advanced use.
Does this also include doing away with the badly documented
workers.properties files too? I'd love to be able to configure my
apache modules using the apache config file.... ;)
Cheers,
Simon
--
"What're we gonna do tonight, Brain?" "I'd tell you, but there's a 78-char li
--
To unsubscribe: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>
RE: Which Connector for Tomcat 4.0.3 - mod_webapp or mod_jk
Posted by "Noel J. Bergman" <no...@devtech.com>.
> >For example, mod_jk won't know that we want
> >Tomcat to process a filter chain against a directory unless we've done a
> >JkMount for that tree, whereas it would know that Tomcat needs to process
a
> >JSP page. On the other hand, mod_webapp would know about the filter
chain
> >because the resources would have been deployed as part of a web app.
> This isn't quite true. You can get the same functionality with mod_jk as
> mod_webapp by saying:
> JkMount /mycontext ajp13
> JkMount /mycontext/* ajp13
> that works *exactly* the same as:
> WebAppDeploy mycontext warpConnection /mycontext/
Which part of "unless we've done a JkMount for that tree" didn't you
understand? I did not say that mod_jk doesn't support the facility, just
that it has to be configured properly. Your example provides exactly what I
said would be necessary.
Having done this, Tomcat will serve up even static resources in that
context. Which is what the deployment is asking for in this case.
--- Noel
--
To unsubscribe: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>
RE: Which Connector for Tomcat 4.0.3 - mod_webapp or mod_jk
Posted by Jacob Kjome <ho...@visi.com>.
>For example, mod_jk won't know that we want
>Tomcat to process a filter chain against a directory unless we've done a
>JkMount for that tree, whereas it would know that Tomcat needs to process a
>JSP page. On the other hand, mod_webapp would know about the filter chain
>because the resources would have been deployed as part of a web app.
This isn't quite true. You can get the same functionality with mod_jk as
mod_webapp by saying:
JkMount /mycontext ajp13
JkMount /mycontext/* ajp13
that works *exactly* the same as:
WebAppDeploy mycontext warpConnection /mycontext/
In both cases, all requests will be forwarded to Tomcat to do processing
which makes it so you don't have to re-specify the servlet mappings you set
in the web.xml as JkMounts like you would have to if you took the following
approach.
JkMount /mycontext/servlet ajp13
JkMount /mycontext/servlet/* ajp13
JkMount /mycontext/*.jsp ajp13
JkMount /mycontext/myservletmapping ajp13
Jake
At 12:19 AM 5/2/2002 -0400, you wrote:
> > I believe that the official stance is that mod_webapp will be the future
>of
> > Apache-tomcat connectors, and it will receive performance and feature
> > improvements whereas ...
>
>This appears to be one of the most common myths regarding Tomcat connectors.
>The real official stance appears to be that mod_jk2 and mod_webapp are
>competing projects from two groups of developers who don't agree with
>others' code/approach.
>
>AIUI, mod_webapp has been easier to configure; mod_jk offers load balancing,
>and doesn't pass requests for static resources to Tomcat before letting
>Apache handle them. mod_jk2 is getting even faster and easier to configure.
>mod_webapp is getting patched to avoid passing static requests through
>Tomcat first. mod_jk configuration is more similar to what those of us who
>used mod_jserv know. mod_jk supports multiple worker types, including
>in-process execution of Tomcat.
>
>The biggest difference seems to be the deployment approach. When it comes
>down to it, there is a difference between:
>
> WebAppDeploy examples warpConnection /examples/
>
>and
>
> JkMount /*.jsp tomcat1
> JkMount /examples/* tomcat1
>
>mod_jk tells Apache about resources it should ask Tomcat to handle.
>mod_webapp tells Apache about webapps that Tomcat should handle.
>
>This really is a huge difference, if I understand the implications (without
>reading through the code). For example, mod_jk won't know that we want
>Tomcat to process a filter chain against a directory unless we've done a
>JkMount for that tree, whereas it would know that Tomcat needs to process a
>JSP page. On the other hand, mod_webapp would know about the filter chain
>because the resources would have been deployed as part of a web app.
>
>The respective developers are free to correct any of the above.
>
> --- Noel
>
>
>--
>To unsubscribe: <ma...@jakarta.apache.org>
>For additional commands: <ma...@jakarta.apache.org>
>Troubles with the list: <ma...@jakarta.apache.org>
RE: Which Connector for Tomcat 4.0.3 - mod_webapp or mod_jk
Posted by co...@covalent.net.
On Thu, 2 May 2002, Noel J. Bergman wrote:
> AIUI, mod_webapp has been easier to configure; mod_jk offers load balancing,
The configuration is the same, for the 'basic' things:
WebAppDeploy examples /examples
is arguably as easy as:
JkMount /examples/* tomcat
And has the same effect (i.e. current webapp behavior ).
What is complex is advanced configuration - lb, letting apache handle
static resources, etc.
> This really is a huge difference, if I understand the implications (without
> reading through the code). For example, mod_jk won't know that we want
> Tomcat to process a filter chain against a directory unless we've done a
> JkMount for that tree, whereas it would know that Tomcat needs to process a
> JSP page. On the other hand, mod_webapp would know about the filter chain
> because the resources would have been deployed as part of a web app.
mod_webapp will know that because it forwards all requests. Same is
trivial with mod_jk, however jk does give you the option to fine tune
what resources are forwarded ( and maybe use apache where an equivalent
functionality exists ).
One of the goals of mod_jk2 is to go further and be able to operate with
only 'standard' apache directives and configuration ( i.e. <Location> and
SetHandler ). That'll be much faster and easier to integrate - but even
more verbose. However that's just one option, for advanced use.
Costin
--
To unsubscribe: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>