I agree with Mike (how could I not with a name like that :-) and Mel.
Another thing that would be nice in ApacheConfig.java is to have
appropriate JkMount directives put in for any servlet-mappings. For
example in webapps\test\WEB-INF\web.xml, servlet1 is mapped to
url-pattern /foo/bar/*. It would be nice to generate the associated
JkMount /foo/bar/* ajp12 (or appropriate worker). This would allow
the webserver to be automatically configured to pass the appropriate
requests to mod_jk. I haven't looked hard enough to see if the
information is available when ApacheConfig is called, but if people are
interested, I would be willing to spend some time on it.
Now if only we could the same for those "other"
web servers (IIS and Netscape:-)
Mike Anderson
Senior Software Engineer
Platform Services Group
[EMAIL PROTECTED]
Novell, Inc., the leading provider of Net services software
www.novell.com
>>> [EMAIL PROTECTED] 03/01/01 10:52AM >>>
I say it sounds like a good idea, that way if you build according to the
mod_jk build scripts, they say to add the lines to httpd.conf. It would
also allow the use of apxs to do the install of mod_jk in the build scripts
automatically, also.
Mike.
--
Mike Braden
[EMAIL PROTECTED]
-----Original Message-----
From: Mel Martinez [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 01, 2001 12:36 PM
To: [EMAIL PROTECTED]
Subject: Proposed ApacheConfig tweak:Re: Bugzilla #512 is Bunk
--- Stephen Jones <[EMAIL PROTECTED]> wrote:
>
> In httpd.conf, you cannot do this:
>
> <VirtualHost .... blah>
> .... normal config for VirtualHost ...
> Include
> /usr/local/jakarta-tomcat/conf/mod_jk.conf-auto
> </VirtualHost>
>
> There are three main purposes of including
> mod_jk.conf-auto:
>
> (1) To get the mod_jk Apache Module loaded, as
> follows:
> LoadModule jk_module libexec/mod_jk.so
>
>
> The first (1) Apache directive is the problem: the
> LoadModule directive
> is illegal within the VirtualHost context.
> (See
>
http://httpd.apache.org/docs/mod/mod_so.html#loadmodule
> )
Without trying to change the fact that the LoadModule
call should not be inside a virtual host definition, a
simple patch that should fix this as a side benefit
(the main benefit is improved flexibility in deploying
tomcat and apache) would be to make a simple change to
ApacheConfig.java.
Specifically, ApacheConfig currently generates (based
on operating system type and other conditions) a line
similar to:
LoadModule jk_module modules/mod_jk.dll or
LoadModule jk_module modules/mod_jk.so
and so on. It should not be too difficult to modify
ApacheConfig.java to generate the following
declaration format instead:
<IfModule !mod_jk.c>
LoadModule jk_module modules/mod_jk.so
</IfModule>
This would serve two purposes. Obviously, if the
module is already loaded, then LoadModule would not be
called. Thus, if you simply make sure to use
LoadModule to load mod_jk prior to the VirtualHost
definition, then I believe that if you include the
mod_jk.conf-auto file it should not cause a problem.
I.E. step (1) would be ignored.
The more important benefit would be to allow the
deployment engineer freedom to put the mod_jk.so (or
mod_jk.dll) module elsewhere than inside
${TOMCAT_HOME}/modules/. Inside httpd.conf, you would
simply specify where you want to load mod_jk.so/.dll
from prior to including mod_jk.conf-auto.
Some examples:
#...inside a solaris version of httpd.conf...
LoadModule jk_module /path/modules/solaris/mod_jk.so
Include
/usr/local/jakarta-tomcat/conf/mod_jk.conf-auto
#...while inside a linux version of httpd.conf:
LoadModule jk_module /path/modules/linux/mod_jk.so
Include
/usr/local/jakarta-tomcat/conf/mod_jk.conf-auto
and so on. This would make it easier to deploy the
same apache/tomcat configuration from CVS to multiple
platforms since you don't have to maintain a custom
mod_jk.conf for each platform.
The same fix should be applied to the other LoadModule
calls (such as for jserv).
I will try to put some time into creating this patch
later today. I don't think I can get it done for a
day or two though. Too busy with other things. I do
need this patch for my own purposes, though, so I will
definitely pursue it.
Does anybody see a problem with this proposal?
If I don't hear any nay-saying I'll proceed. I'll
post it first as a [PATCH] as I'll need folks using
jserv to test it out as well, but this looks pretty
straight forward.
Cheers,
Mel
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
