Giampaolo Tomassoni wrote:
Any other 'better' integration would probably require patching
Apache core, and thats IMHO unfeasible by majority of users.

Which one? Checking the 404 response? If mod_jk adopts sub-requests to Tomcat, 
why should Apache get patched?
Or if you mean the JkMount directive to be <Directory>-based, isn't it a matter 
of how mod_jk handles its own directives? So, again, why would it need patching 
Apache?


Look, I don't wish to go into discussion with you, because
you obviously already have your perspective (IMHO wrong).

Static content delivery by Apache requires thorough application
design so that it can be served outside the application itself.

No, it doesn't. The purpose of mod_jk is exactly this, I think.
Company A makes a servlet-based application, which probably has both static and 
dynamic content, using their preferred IDE/application builder. Company B 
publishes it using Tomcat and Apache, and wants to avoid wasting cpu cicles and 
memory by allowing apache to delivery the static content, not Tomcap.
Mod_jk may be used just to map a virtual space to Tomcat. It is also used to 
deliver static content more or less regardless of the servlet app. Of course, 
you may not be able to deliver *all* the static content by apache (think, in 
example, to the deliverable resources in Tomahawk), but most of your app's 
icons, css, js and the like can. An they get even cached into the client this 
way.


What if the application is inside a .war or .sar. What then?
You don't have a file system, so if you wish to have a static content
served by Apache you *must* design your application accordingly.
First of all you will loose auto deployers, etc...



This both ease the configuration and increases the security,
because the worst thing you can do is to physically map the
web application to the Apache Directory. In that case all the
Tomcat and Servlet spec security is jeopardized.

Well, not exactly. Of course you have to know what you're doing, but often it 
is not that difficult: when you want to secure an area of a webapp, you often 
doesn't mean to secure the delivery of its static contents (who cares of 
icons?). You mean to do this for the dynamic part.
Sure, you have to avoid downloading "META-INF/*" and "WEB-INF/*". Well, in most 
cases this is all you need to secure from the apache side.
Also, if you need to secure some static branch of the VFS, you may just JkMount 
"/your_own_secure_statics/*" and rely on Tomcat to handle it...

But all that requires management of two different configs.
Any change in Tomcat configuration (well, for start let's forget JMX,
an all other dynamic configs) would require to at least 'thinking' of
what that change would mean for the Apache Httpd in front, and that
simply sucks.

Regards,
Mladen.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to