You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by BuildSmart <bu...@daleenterprise.com> on 2007/10/28 12:04:39 UTC
jkMount
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=192.168.0.10&count=10&key=robot" 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?
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 "/".
Maybe I should be using a different protocol that allows assignment
by file extension (if one exists) but google has done nothing but
create more confusion for me.
_______________________________________
My apache config contains:
_______________________________________
<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>
_______________________________________
my workers.ajp13.properties contains:
_______________________________________
ps=/
# Define 1 real worker using ajp13
worker.list=ajp13
# ------------------------
# First worker server
# ------------------------
# Set properties for ajp13 (ajp13)
worker.ajp13.host=localhost
worker.ajp13.port=8019
worker.ajp13.type=ajp13
worker.ajp13.lbfactor=1
#
# END workers.properties
#
_______________________________________
-- Dale
Re: jkMount
Posted by Ingo Krabbe <ik...@web.de>.
Am Montag, 29. Oktober 2007 23:33:16 schrieb Christopher Schultz:
> 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
> >> right virtual host config on either httpd or Tomcat or both. My guess is
> >> "both".
> >
> > 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
> and you expect it to work with other virtual hosts? Apache httpd doesn't
> do this, either. Why would you expect that an incorrect configuration
> would work properly?
>
> > 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.
>
> 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
> 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
> virtual hosts. Since you are so familiar with the documentation, I won't
> waste space in this post with the configuration.
>
> > 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
> this, but there's an easy workaround: use a global virtual host. In any
> event, if you need this global capability (and it sounds like you do),
> try asking for this capability instead of telling the mod_jk folks that
> they are bunch of idiots. You catch more flies...
Actually I had BIG problems with JkMount at a time ... well I think there was
a major flaw in communication between the module and the tomcat vm ... or
somewhere else. Anyway these problems are thought to be gone in recent
versions (I think).
>
> 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.
The virtual host problem can be solved quite easily be apache configuration if
you define you JkMount statements in a simple include file lets call it
jkmount.conf and use them in your virtual host statements:
<VirtualHost bla:80>
# [...]
include jkmount.conf
# [...]
</VirtualHost>
>
> >>>> 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.
> >>
> >> No, you said that "JkMount /* workerX" kills Python and Php. Rainer is
> >> asking you to use "JkMount /*.jsp workerX".
> >
> > 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.
>
ouch, yes of course there should be workers.
> > guess that doesn't work either, any more suggestion???
>
> Yes: use the name of the worker that you actually configured (ajp13, as
> per the posted configuration).
>
> > 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
> > configure it and as you stated that is how everyone configures it and it
> > works for them so either I'm not getting all of the information or it
> > doesn't work.
No, it just a bit insane. Nore more then anything else that is done with
Java.
>
> 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.
>
> 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>
>
> Your config is clearly being loaded, as you are getting messages in your
> log file regarding mod_jk.
>
> Where is this configuration located? Is it being put into a VirtualHost,
> or is it at the top-level?
>
> Can you post a mod_jk log of what /does/ happen when you use this
> configuration and try to access a JSP page? My guess is that you'll see
> there are "no" mappings in the URI worker map for that virtual host.
>
> What happens if, for the sake of testing, you move the JkMount directive
> into a specific virtual host and try that? Does it work, then?
>
> -chris
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: jkMount
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dale,
BuildSmart wrote:
> You're shitting me, it can't be that simple, thank you, it works as
> configured with my ajp13 worker.
Yes, it's that simple. Usually the only problem with mod_jk setup is
that people try to add too much complexity at once. I believe that
Tomcat is configured out-of-the-box to have the "localhost" virtual host
as the default, so this doesn't affect most people.
> 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.
You should not have to configure "workerX". Your worker named "ajp13"
should be just fine. Forget I said anything about "workerX".
> It works once I added the default virtualhost option
Good.
> 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
Excellent. So, how is your module different from mod_jk? I know you
removed some old stuff (ajp12?), but it seems like this ought to work by
simply passing httpd's DocumentRoot setting to Tomcat and then
overriding some of the JasperServlet methods to find the JSP relative to
httpd's DocumentRoot rather than relative to the webapp's deployment
directory.
Is this roughly what you're doing?
Would it be possible to instead simply configure the standard mod_jk
module to forward the PATH_TRANSLATED environment variable to Tomcat and
have it use that? I'm just looking for what might be a simpler solution:
if you only have to distribute a webapp, that's better than distributing
a webapp along with an Apache httpd module.
> 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?
If it's something that can be relatively easily added (and turned on
with configuration) and doesn't significantly change the existing code
(which, I guess, you could say is the same thing), then they may accept
a patch from you. Try not to be a jerk when submitting it, though. They
my already be ignoring you (notice they're no longer replying to you).
What, no "thank you"?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHJy6p9CaO5/Lv0PARAmgLAJ9T8r2Y47eXKzU8eti0paU5z5gyEACeKzz6
JKbus5YYJAXdCb4UTAQ+klY=
=/Kbs
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: jkMount
Posted by BuildSmart <bu...@daleenterprise.com>.
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
>>> right virtual host config on either httpd or Tomcat or both. My
>>> guess is
>>> "both".
>>
>> 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
> and you expect it to work with other virtual hosts? Apache httpd
> doesn't
> do this, either. Why would you expect that an incorrect configuration
> would work properly?
>
>> 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.
>
> 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
> 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
> virtual hosts. Since you are so familiar with the documentation, I
> won't
> waste space in this post with the configuration.
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
> this, but there's an easy workaround: use a global virtual host. In
> any
> event, if you need this global capability (and it sounds like you do),
> try asking for this capability instead of telling the mod_jk folks
> that
> 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.
>
>>>>> 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.
>>>
>>> No, you said that "JkMount /* workerX" kills Python and Php.
>>> Rainer is
>>> asking you to use "JkMount /*.jsp workerX".
>>
>> 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???
>
> Yes: use the name of the worker that you actually configured
> (ajp13, as
> per the posted configuration).
>
>> 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
>> configure it and as you stated that is how everyone configures it
>> and it
>> works for them so either I'm not getting all of the information or it
>> doesn't work.
>
> 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>
>
> Your config is clearly being loaded, as you are getting messages in
> your
> log file regarding mod_jk.
>
> Where is this configuration located? Is it being put into a
> VirtualHost,
> or is it at the top-level?
top level
>
> Can you post a mod_jk log of what /does/ happen when you use this
> configuration and try to access a JSP page? My guess is that you'll
> see
> there are "no" mappings in the URI worker map for that virtual host.
>
> What happens if, for the sake of testing, you move the JkMount
> directive
> into a specific virtual host and try that? Does it work, then?
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
Re: jkMount
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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
>> right virtual host config on either httpd or Tomcat or both. My guess is
>> "both".
>
> 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
and you expect it to work with other virtual hosts? Apache httpd doesn't
do this, either. Why would you expect that an incorrect configuration
would work properly?
> 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.
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
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
virtual hosts. Since you are so familiar with the documentation, I won't
waste space in this post with the configuration.
> 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
this, but there's an easy workaround: use a global virtual host. In any
event, if you need this global capability (and it sounds like you do),
try asking for this capability instead of telling the mod_jk folks that
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.
>>>> 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.
>>
>> No, you said that "JkMount /* workerX" kills Python and Php. Rainer is
>> asking you to use "JkMount /*.jsp workerX".
>
> 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.
> guess that doesn't work either, any more suggestion???
Yes: use the name of the worker that you actually configured (ajp13, as
per the posted configuration).
> 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
> configure it and as you stated that is how everyone configures it and it
> works for them so either I'm not getting all of the information or it
> doesn't work.
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.
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>
Your config is clearly being loaded, as you are getting messages in your
log file regarding mod_jk.
Where is this configuration located? Is it being put into a VirtualHost,
or is it at the top-level?
Can you post a mod_jk log of what /does/ happen when you use this
configuration and try to access a JSP page? My guess is that you'll see
there are "no" mappings in the URI worker map for that virtual host.
What happens if, for the sake of testing, you move the JkMount directive
into a specific virtual host and try that? Does it work, then?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHJl+s9CaO5/Lv0PARAgEFAJ91gTgqtkKF2gFIbqDRHybp8Y5uOQCeOe+z
wPQ7varIZ+S2UaUMtQBiSmc=
=B5oJ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: jkMount
Posted by BuildSmart <bu...@daleenterprise.com>.
On Oct 29, 2007, at 10:27:21, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> BS,
>
> BuildSmart wrote:
>> jkMount /* myworker <-- your example.
>>
>> It didn't work and only further proves that mod_jk lacks any real
>> intelligence in functionality.
>
> You are not making any friends on this list. I need to fix your tone
> right now before everyone lips your bozo bit and refuses to answer
> your
> increasingly stupid posts.
>
> Given that you are trying to hack-up a protocol to work in a way
> that ti
> wasn't designed, I wouldn't start shooting my mouth off at the authors
> of the code you're bastardizing.
>
>> 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.
>
> It totally did work. You mapped everything to Tomcat, so everything
> went
> to Tomcat. Just because you wanted Apache to make the same decision
> you
> would have ".php goes to php runner, .jsp goes to Tomcat" doesn't mean
> that mod_jk is broken: it means that your understanding of how to
> configure it is broken.
obviously not only my understanding is broken but the advise from
well intentioned helpers who direct me to make configuration by only
providing partial information expecting that I know what I'm doing
where tomcat is concerned.
>
> You obviously have not read the documentation clearly, or you wouldn't
> be asking these questions.
clearly I have read the documentation but it does not provide a
working configuration or even an example I can copy/paste that that
does anything remotely close to what I'm being told to configure.
>
> 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
> right virtual host config on either httpd or Tomcat or both. My
> guess is
> "both".
I only have one webapp in Tomcat as localhost and it's on port 8080
(with connector on 8009) what more do I need??
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.
>
>>> 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.
>
> Dude, everyone uses "JkMount /*.jsp workerX". It can't be just you. Or
> can it? You've been monkeying around in the mod_jk code to create this
> zombie mod_just_jsp thing and now you want to complain that it doesn't
> work? Get bent. You probably broke it yourself.
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.
>
>>> 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.
>
> No, you said that "JkMount /* workerX" kills Python and Php. Rainer is
> asking you to use "JkMount /*.jsp workerX".
workerX is not defined anywhere but I'll give it a try to satisfy you.
[Mon Oct 29 17:03:35 2007] [29592:2684415368] [debug]
map_uri_to_worker::jk_uri_worker_map.c (597): Attempting to map URI '/
index.jsp' from 2 maps
[Mon Oct 29 17:03:35 2007] [29592:2684415368] [debug]
map_uri_to_worker::jk_uri_worker_map.c (609): Attempting to map
context URI '/servlet/*=workerX' source 'JkMount'
[Mon Oct 29 17:03:35 2007] [29592:2684415368] [debug]
map_uri_to_worker::jk_uri_worker_map.c (609): Attempting to map
context URI '/*.jsp=workerX' source 'JkMount'
[Mon Oct 29 17:03:35 2007] [29592:2684415368] [debug]
map_uri_to_worker::jk_uri_worker_map.c (624): Found a wildchar match
'/*.jsp=workerX'
[Mon Oct 29 17:03:35 2007] [29592:2684415368] [debug]
wc_get_worker_for_name::jk_worker.c (115): did not find a worker workerX
[Mon Oct 29 17:03:35 2007] [29592:2684415368] [error]
jk_handler::mod_jk.c (2194): Could not init service for worker=workerX
guess that doesn't work either, any more suggestion???
>
>>> 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.
>
> You seriously need to check yourself. While the above may be true,
> your
> frustration should not result in such poor manners.
yes, you are correct, it should not, however, if it had only been a
day or two of fiddling with it 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 configure it and as you stated that is how everyone configures
it and it works for them so either I'm not getting all of the
information or it doesn't work.
I decided to go try it on 3 other systems in the event that maybe
this one is broken and it yields the same results so now that I have
confirmed that it's not an isolated incident we can move forward.
>
>> I have several hundred virtual hosts and to have to configure each
>> one independently to access the webapp should not even be
>> contemplated.
>
> I think you're trying to do something that is just complex and a
> pain in
> the ass. Php and Python are not application servers. Tomcat is an
> application server and JSPs are designed to run in them. AJP is a
> protocol that was designed to support this architecture. mod_jk is an
> implementation of that protocol also designed to support that
> architecture.
>
> Don't complain when mod_jk and AJP don't work on your Frankenstein
> architecture.
I'll be happy to see it work and it has nothing to do with
Frankenstein architecture.
>
>> 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.
>
> Go talk to Sun.
>
>> 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?
>
> Go use mod_jk2. It may be more your style. It's got a higher version
> number, so it must be better, right?
only better if you claim it is.
>
> - -chris
-- Dale
Re: jkMount
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
BS,
BuildSmart wrote:
> jkMount /* myworker <-- your example.
>
> It didn't work and only further proves that mod_jk lacks any real
> intelligence in functionality.
You are not making any friends on this list. I need to fix your tone
right now before everyone lips your bozo bit and refuses to answer your
increasingly stupid posts.
Given that you are trying to hack-up a protocol to work in a way that ti
wasn't designed, I wouldn't start shooting my mouth off at the authors
of the code you're bastardizing.
> 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.
It totally did work. You mapped everything to Tomcat, so everything went
to Tomcat. Just because you wanted Apache to make the same decision you
would have ".php goes to php runner, .jsp goes to Tomcat" doesn't mean
that mod_jk is broken: it means that your understanding of how to
configure it is broken.
You obviously have not read the documentation clearly, or you wouldn't
be asking these questions.
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
right virtual host config on either httpd or Tomcat or both. My guess is
"both".
>> 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.
Dude, everyone uses "JkMount /*.jsp workerX". It can't be just you. Or
can it? You've been monkeying around in the mod_jk code to create this
zombie mod_just_jsp thing and now you want to complain that it doesn't
work? Get bent. You probably broke it yourself.
>> 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.
No, you said that "JkMount /* workerX" kills Python and Php. Rainer is
asking you to use "JkMount /*.jsp workerX".
>> 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.
You seriously need to check yourself. While the above may be true, your
frustration should not result in such poor manners.
> I have several hundred virtual hosts and to have to configure each
> one independently to access the webapp should not even be contemplated.
I think you're trying to do something that is just complex and a pain in
the ass. Php and Python are not application servers. Tomcat is an
application server and JSPs are designed to run in them. AJP is a
protocol that was designed to support this architecture. mod_jk is an
implementation of that protocol also designed to support that architecture.
Don't complain when mod_jk and AJP don't work on your Frankenstein
architecture.
> 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.
Go talk to Sun.
> 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?
Go use mod_jk2. It may be more your style. It's got a higher version
number, so it must be better, right?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHJe3J9CaO5/Lv0PARAjQjAJ91hVxwIw5XtZ/6e+IRTMh0a5KzyACeLk0Q
7cjMq6oRkY3OJMB3mo1s4RY=
=lwj1
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: jkMount
Posted by BuildSmart <bu...@daleenterprise.com>.
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=192.168.0.10&count=10&key=robot <http://domain.tld/index.jsp?
>>>> ip=192.168.0.10&count=10&key=robot>" 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
>>>
>>> http://tomcat.apache.org/connectors-doc/reference/apache.html
>>> and
>>> http://tomcat.apache.org/connectors-doc/reference/uriworkermap.html
>>>
>> 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
functionality.
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
Re: jkMount
Posted by Rainer Jung <ra...@kippdata.de>.
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=192.168.0.10&count=10&key=robot
>>> <http://domain.tld/index.jsp?ip=192.168.0.10&count=10&key=robot>"
>>> 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
>>
>> http://tomcat.apache.org/connectors-doc/reference/apache.html
>> and
>> http://tomcat.apache.org/connectors-doc/reference/uriworkermap.html
>>
> 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.
> 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.
> 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 '/'.
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.
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.
Regards,
Rainer
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: jkMount
Posted by BuildSmart <bu...@daleenterprise.com>.
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=192.168.0.10&count=10&key=robot" 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
>
> http://tomcat.apache.org/connectors-doc/reference/apache.html
> and
> http://tomcat.apache.org/connectors-doc/reference/uriworkermap.html
>
> See further comments inline.
>
>> Maybe I should be using a different protocol that allows
>> assignment by file extension (if one exists) but google has done
>> nothing but create more confusion for me.
>> _______________________________________
>> My apache config contains:
>> _______________________________________
>> <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] "
>
> That was our old default JkLogStampFormat. If you omit the lines,
> you will get milliseconds for free starting with mod_jk 1.2.25.
>
>> JkMount /*.jsp ajp13
>
> Uups: there you are, you already use a suffix pattern!
>
>> JkOptions +ForwardKeySize +ForwardURICompat
>
> It's very likely, that you won't need the +ForwardURICompat when
> using an up-to-date mod_jk.
>
>> </IfModule>
>> _______________________________________
>> my workers.ajp13.properties contains:
>> _______________________________________
>> ps=/
>
> This defines a variable ps, which you are never using. Simply
> delete this.
>
>> # Define 1 real worker using ajp13
>> worker.list=ajp13
>> # ------------------------
>> # First worker server
>> # ------------------------
>> # Set properties for ajp13 (ajp13)
>> worker.ajp13.host=localhost
>> worker.ajp13.port=8019
>> worker.ajp13.type=ajp13
>> worker.ajp13.lbfactor=1
>> #
>> # END workers.properties
>> #
>> _______________________________________
>> -- Dale
>
> Regards,
>
> Rainer
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
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.
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.
I believe that one host/port can be used by any apache virtualhost to
server pages from the apache virtualhost DOCUMENT_ROOT and not the
webapp docroot making it's implementation far more dynamic and
useable rather than all the complicated configuring of the current
methods discussed on this list.
A good example of this in action is BlueDragon, it has a custom
connector and a module to handle the communication between the webapp
server and apache.
Adobe CF does something similiar with mod_jrun but it's configuration
is a little more complicated and also not a free useable solution.
BlueDragon makes integration and use from apache very easy to
achieve, does not require telling the webapp server where the apache
DOCUMENT_ROOT's are and servers the pages from the apache
DOCUMENT_ROOT's and not the webapp docroots which is a far more
intelligent solution.
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.
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.
-- Dale
Re: jkMount
Posted by Rainer Jung <ra...@kippdata.de>.
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=192.168.0.10&count=10&key=robot" 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".
> 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
See
http://tomcat.apache.org/connectors-doc/reference/apache.html
and
http://tomcat.apache.org/connectors-doc/reference/uriworkermap.html
See further comments inline.
> Maybe I should be using a different protocol that allows assignment by
> file extension (if one exists) but google has done nothing but create
> more confusion for me.
>
> _______________________________________
>
> My apache config contains:
> _______________________________________
>
> <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] "
That was our old default JkLogStampFormat. If you omit the lines, you
will get milliseconds for free starting with mod_jk 1.2.25.
> JkMount /*.jsp ajp13
Uups: there you are, you already use a suffix pattern!
> JkOptions +ForwardKeySize +ForwardURICompat
It's very likely, that you won't need the +ForwardURICompat when using
an up-to-date mod_jk.
> </IfModule>
> _______________________________________
>
> my workers.ajp13.properties contains:
> _______________________________________
>
> ps=/
This defines a variable ps, which you are never using. Simply delete this.
> # Define 1 real worker using ajp13
> worker.list=ajp13
>
> # ------------------------
> # First worker server
> # ------------------------
> # Set properties for ajp13 (ajp13)
> worker.ajp13.host=localhost
> worker.ajp13.port=8019
> worker.ajp13.type=ajp13
> worker.ajp13.lbfactor=1
>
> #
> # END workers.properties
> #
> _______________________________________
>
>
> -- Dale
Regards,
Rainer
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org