Re: jkMount

[BuildSmart]

On Oct 29, 2007, at 18:33:16, Christopher Schultz wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dale,

BuildSmart wrote:

As for only working on localhost, you need to check the rest of your
Apache httpd and Tomcat configurations: you probably don't have the

"both".

right virtual host config on either httpd or Tomcat or both. My guess is

I only have one webapp in Tomcat as localhost and it's on port 8080
(with connector on 8009) what more do I need??

So, you have Tomcat configured to support the "localhost" virtual host

do this, either. Why would you expect that an incorrect configuration
would work properly?

and you expect it to work with other virtual hosts? Apache httpd doesn't

Don't tell me now that I have to add an entry in Tomcat for every
virtualhost that wishes to access the webapp, that makes no logical
sense to have multiple tomcat virtualhosts pointing to the same
webapp/docroot.

an illogical statement?

Tomcat, like Apache httpd, can be configured to use a default virtual
host for all requests that do not match any of the explicitly-defined

waste space in this post with the configuration.

Aah, yes... but you're asking all virtual hosts in httpd to point to the same Tomcat instance. Why does the symmetric relation not hold for such virtual hosts. Since you are so familiar with the documentation, I won't

You're shitting me, it can't be that simple, thank you, it works as configured with my ajp13 worker. It still doesn't work with the workerX though, I'm guessing that my workers.property file needs modification for workerX to work but since ajp13 works I just need to come up with a name that wont be common and hard code the properties into the module in an attempt to reduce configuration making it easier to implement.

I'm using the mod_jk module and not a bastardized version so if it's not working per your configuration directives then it's the guys who coded

mod_jk who are fault and you should bitch to them about it.

I've never had a problem with mod_jk. No complaints required from my
end. It's possible that mod_jk was written to support only virtual
hosts, and not JkMount options at the top-level. I'd be surprised at

event, if you need this global capability (and it sounds like you do),

they are bunch of idiots. You catch more flies...

In your case, you have discrete virtual hosts. You may have to add
"JkMount /*.jsp workerX" for each virtual host. It's not insane: it's
what's required. You have to map DocumentRoot for each VirtualHost
element. What's wrong with adding this mapping as well.

this, but there's an easy workaround: use a global virtual host. In any try asking for this capability instead of telling the mod_jk folks that

Concerning vhosts, I didn't understand, what you try to achieve.

can discuss further requirements.

Please try the above JkMount first. As soon as that works for you, we

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

asking you to use "JkMount /*.jsp workerX".

No, you said that "JkMount /* workerX" kills Python and Php. Rainer is

workerX is not defined anywhere but I'll give it a try to satisfy you.

OMGWTFBBQ. Nearly all of the mod_jk documentation surrounds creating
workers that connect mod_jk to Tomcat. You should have gotten /that/
far. You must have a worker, or nothing works. "workerX" is a

placeholder for the actual worker you want to use. Put your own worker's name in there, don't just type "workerX" and complain when it doesn't work.

I had that in my config, that's what I was told to put in it, I already had "JkMount /*.jsp ajp13" when they said to try "JkMount / *.jsp workerX" so I did.

guess that doesn't work either, any more suggestion???

per the posted configuration).

Yes: use the name of the worker that you actually configured (ajp13, as

it wouldn't have been so bad but more than a
week with incomplete directions hasn't help the frustration level,
something is definitely broken if it wont work as people tell me to

works for them so either I'm not getting all of the information or it
doesn't work.

configure it and as you stated that is how everyone configures it and it

Let's take a quick look at your configuration. workers.properties:

worker.list=ajp13
worker.ajp13.host=localhost
worker.ajp13.port=8019
worker.ajp13.type=ajp13

Note that you don't need the 'lbfactor' unless you are using a
load-balanced worker.

yeah I removed that a while ago along with the ps=/  variable.

Now, to your httpd config:

<IfModule mod_jk.c>
JKWorkersFile /etc/httpd/workers.ajp13.properties
JKLogFile /var/log/httpd/mod_jk.log
JKLogLevel debug
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
JkMount /*.jsp ajp13
JkOptions +ForwardKeySize +ForwardURICompat
</IfModule>


log file regarding mod_jk.


or is it at the top-level?

Your config is clearly being loaded, as you are getting messages in your Where is this configuration located? Is it being put into a VirtualHost,

top level

Can you post a mod_jk log of what /does/ happen when you use this

there are "no" mappings in the URI worker map for that virtual host.


into a specific virtual host and try that? Does it work, then?

configuration and try to access a JSP page? My guess is that you'll see What happens if, for the sake of testing, you move the JkMount directive

It works once I added the default virtualhost option, I'll look into doing something in the class files under an ambiquos name associated with the modified ajp13 code (I'll call it ajpx13 for lack of a better name) that should resolve that issue. I've now switched to my FRANKENSTIEN-module and the ajpx13 (modified ajp13) connector and I can execute the .jsp scripts from the apache virtualhost DOCUMENT_ROOT's as deep as the directories go so now it's just a matter of making these default values in the source of make a AJPX13-handler so it can be enable with a EnableAJPX13 directive to enable the functionality, when that works I can recombine the module back into the mod_jk source and start looking at applying the changes to the apache 2 mod_jk module or change the module even further and make it a servlet-handler assignable by file extension but I believe that using the defualt virtuhost is sufficient since it's only purpose is to make .jsp (appear to) work natively from within apache. At this time I haven't combined the AJPX13 class files with the Coyote jar and maybe it should be left on it's own pending further testing plus I need to test it with newer Tomcat versions still. When all is said and done, should this be passed to the tomcat developers or is it something that is so unique to my requirement that it's not worth bothering them with it? Oh... l just added the smith project .war as my webapp in tomcat, added /*.cfm as an additional jkmount and cold fusion is available to all apache virtualhosts like the .jsp files, definite advantages to this configuration, now I don't have to worry about virtualhosts in Tomcat and oh yes, the webapp docroot is still accessible by port specification so an administration interface is very possible.

- -chris

-- Dale

PGP.sig
Description: This is a digitally signed message part