tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From BuildSmart <>
Subject Re: jkMount
Date Sun, 28 Oct 2007 19:41:16 GMT

On Oct 28, 2007, at 10:47:19, Rainer Jung wrote:

> Comments inline
> BuildSmart wrote:
>> On Oct 28, 2007, at 08:32:50, Rainer Jung wrote:
>>> Hi,
>>> BuildSmart wrote:
>>>> I'm trying to get around a configuration issue.
>>>> My webapp builds dynamic script content but the generated  
>>>> scripts are not accessible.
>>>> For example, calling http://domain.tld/index.jsp? 
>>>> ip= <http://domain.tld/index.jsp?

>>>> ip=>" should generate some  
>>>> subdirectories and builds some jsp pages with content and this  
>>>> seems to work as expected but from apache these are not  
>>>> accessible but from the Tomcat port I can access the pages  
>>>> without issue, is there a way to resolve this?
>>> With respect to what is following below, I'm not actually sure,  
>>> if I understand, what you mean by "not accessible".
>> "not accessible" means apache cannot access the pages, gives an  
>> error --> page does not exist.
>> if the content pages that are built have the following paths:
>> <docroot>/index.jsp <-- the main page
>> <docroot>/example/user.jsp <-- generated by main page
>> <docroot>/example/data.jsp <-- generated by main page
>> I cannot access any pages in examples directory from apache.
>> I cannot code the subdirectory because they are generated on the  
>> fly and I do not know in advance that they are.
>> I cannot use /* because apache also has other content handlers  
>> like php and then Tomcat errors on the php file.
>>>> I can't pre-define the mount points for the subdirectories  
>>>> because I don't know what they are in advance, there doesn't  
>>>> seem to be a way to define access to Tomcat based on the file  
>>>> extension since it wont let you assign a mount point without a  
>>>> leading "/".
>>> JkMount /*.jsp myworker
>>> would be perfectly valid. You can combine prefixes and suffixes.
>>> If there are no rules at all (no known prefixes and no known  
>>> suffixes) then your URL space is weird and you can only use
>>> JkMount /* myworker
>>> and live with the consequences :(
>>> In case it would be easier to describe, what *not* to forward,  
>>> you can combine JkMount with JkUnmount
>> Now I'd be getting into a complicated and bastardized configuration.
>>> See
>>> and
>> Forgive me for complaining but why on earth has no servlet handler/ 
>> module been developed that processes by file extension rather than  
>> only by context.
>> It would be nice to do:
>> jkMount *.jsp ajp13
> That's exaclty what happens, if you use
> JkMount /*.jsp ajp13
>> then all .jsp files would be processed by the handler, of course  
>> mod_jk doesn't allow it and to do it by file extension would be  
>> too intelligent and renders a lot of current configuration  
>> complicated methods obsolete.
> *It does allow it*
> I already included this example in my previous mail. You didn't  
> comment that example.

jkMount /* myworker <-- your example.

It didn't work and only further proves that mod_jk lacks any real  
intelligence in functionality.

Well it sorta worked, it worked but only with localhost, none of my  
virtual hosts worked and I lost perl and php functionality so it  
really didn't work.

>> adding mode_rewrite or having to configure more than a single  
>> webapp host makes no sense if all you want to do is gain access to  
>> the java engine to deploy pgaes from within apache and having to  
>> define more than one host/port in Tomcat is a retarded concept by  
>> any standards.
>> Currently due to the lack of functionality based on the current  
>> ajp connector and mod_jk, my current solution to execute the .jsp  
>> files from the apache DOCUMENT_ROOT's is limited to the .jsp files  
>> being at the first level of the DOCUMENT_ROOT because mod_jk is  
>> too stupid to allow mapping by file extension and this is not  
>> acceptable.
> No idea, why you claim that.

Because it's true and I have seen no proof of the contrary, what I do  
get are well intentioned individuals offering advice however the  
advice must be incomplete because none of the offered suggestions work.

>> If it involves more than a simple configuration of the apache  
>> module then the method is tainted.
>> I want to server the .jsp pages from any apache DOCUMENT_ROOT  
>> without requiring a degree to configure several modules to achieve  
>> the goal.
>> I'd pay someone to write the connector and module for me cause my  
>> java skills suck but I'm currently so dumb-founded that no one  
>> else has achieved or even complained that the current method of  
>> implementation is useless in a production environment where apache  
>> virtualhosts are the norm.
>> I have a partial solution based on the modified Ajp13Connector  
>> class and a modified mod_jk module but as I stated earlier, it's  
>> limited to the first level of DOCUMENT_ROOT because mapping by  
>> file extension is not possible.
> The above example is *not* restricted to one level of directory. A  
> '*' in a JkMount URI matches any sequence of charaters, including a  
> '/'.

using anything but localhost in the url does not provide a working  
solution, whatever is defined must work for all virtualhosts.
> Concerning vhosts, I didn't understand, what you try to achieve.  
> Please try the above JkMount first. As soon as that works for you,  
> we can discuss further requirements.

I did, it doesn't work and it kills python and php functionality.

> Note: Jkmount by default doesn't get inhertited between vhosts,  
> because usually mounts are vhost specific. You need to put the  
> JkMount into the vhost (or use JkMountCopy). See the docs.

Putting anything into a specific vhost is a moronic concept if the  
webapp is to be shared by all virtualhosts.

At this time, I find it hard to believe that mod_jk can do anything  
more than serve pages from defined contexts cause I have not seen one  
working instance where it can do anything but.

I have several hundred virtual hosts and to have to configure each  
one independently to access the webapp should not even be contemplated.

Achieving a solution that kills functionality is not acceptable, the  
goal is to increase functionality without sacrificing existing  

I have 1 webapp server, I have several hundred apache virtualhosts  
and I want to server the pages from the apache virtualhost  
DOCUMENT_ROOT's and not the webapp root, kinda like the way I can  
process php pages from any apache virtualhost without resorting to  
some stupid or complicated configuration to achieve the task.

What I'm looking for is a solution that is simple to configure but  
based on what you have reported, Tomcat and mod_jk are not capable of  
the the functionality I wish to achieve, what a shame that the  
jakarata guys didn't have enough foresight to see any value in  
exporting the environment rather than ensuring it's a confined  
environment that has far too many limitations and restrictions.

The advantages of serving the pages from the apache virtualhost  
DOCUMENT_ROOT's rather than from Tomcat's webapp docroot should have  
been a consideration and you can see why the concept has merrit but  
unfortunately it seems that they have limited vision and can't see  
past their own work.

I'm left with no choice but to conclude that mod_jk was someone's  
failed attempt to achieve some kind of useful functionality that  
could be applied in a production virtualhost environment.

Is there any other connector/module combination that has a different  
result than mod_jk?

> Regards,
> Rainer

-- Dale

View raw message