You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by "Jones, Stephen" <sj...@rational.com> on 2001/03/02 00:25:44 UTC
Proposed Server.xml Change (was RE: Bugzilla #512 is Bunk)
Right, but that is excruciating to configure and more excruciating to
maintain...
Why not use two copies of Tomcat, each with their own mod_jk.conf-auto which
can be included in the appropriate VirtualHost section?
Or better yet change the way server.xml works to something like this:
<Server>
<ContextManager generate-config="mod-jk-secure.conf-auto" debug="0"
workDir="work" showDebugInfo="true">
... secure contexts ...
</ContextManager>
<ContextManager generate-config="mod-jk.conf-auto" debug="0"
workDir="work" showDebugInfo="true">
... non-secure contexts ...
</ContextManager>
</Server>
Then we could map each ContextManager to one VirtualHost with one
auto-generated config file, and Include them from httpd.conf for each
VirtualHost accordingly?
The implementation would be simple, add the attribute to the ContextManager
XML tag, add it to the ContextManager object which is passed into
ApacheConfig.execute(ContextManager cm), and get the filename to generate
from the ContextManager object. This would minimize on hardcoded filenames,
as well.
Of course we would have to do something about the JkWorkersFile, JkLogLevel,
and JkLogFile directives. Perhaps these could be in a conditional block such
as <IfModule !mod_jk.c></IfModule> or some other Apache conditional
directive. There's got to be some way to separate out the global settings
from the ones which apply to only one ContextManager.
Just some ideas...
Steve
> -----Original Message-----
> From: GOMEZ Henri [mailto:hgomez@slib.fr]
> Sent: Thursday, March 01, 2001 2:54 PM
> To: tomcat-dev@jakarta.apache.org
> Cc: danmil@shore.net; jean-paul_abgrall@phoenix.com
> Subject: RE: Bugzilla #512 is Bunk
>
>
> The correct config for mod_jk is :
>
> in httpd.conf :
>
> JkWorkersFile /etc/httpd/conf/workers.properties
> JkLogFile /var/log/httpd/mod_jk.log
> # set it to error since warn just load to many apache
> JkLogLevel error
>
> for virtuals
>
> <VirtualHost host1.com:80>
>
> DocumentRoot "/home/httpd/host1/html"
>
> <Directory "/home/httpd/host1/html">
> Options FollowSymLinks MultiViews
> AllowOverride AuthConfig
> Order allow,deny
> Allow from all
> </Directory>
>
> ServerName host1.com
> ServerAdmin webmaster@host1.com
>
> ErrorLog /home/httpd/host1/var/log/httpd/error_log
> TransferLog /home/httpd/host1/var/log/httpd/access_log
>
> JkMount /app1/servlet/* workerhost1
> JkMount /app1/*.jsp workerhost1
>
> </VirtualHost>
>
> <VirtualHost host1.com:443>
>
> DocumentRoot "/home/httpd/host1/htmls"
>
> <Directory "/home/httpd/host1/htmls">
> Options FollowSymLinks MultiViews
> AllowOverride AuthConfig
> Order allow,deny
> Allow from all
> </Directory>
>
> Alias /usage/ "/home/httpd/host1/usage/"
>
> <Directory "/home/httpd/host1/usage">
> Options Indexes MultiViews
> AllowOverride None
> Order allow,deny
> Allow from all
> </Directory>
>
> ServerName host1.com
> ServerAdmin webmaster@host1.com
>
> ErrorLog /home/httpd/host1/var/log/httpd/error_log
> TransferLog /home/httpd/host1/var/log/httpd/access_log
>
> SSLEngine on
> SSLCipherSuite
> ALL:!ADH:!EXP56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
> SSLCertificateFile
> /home/httpd/host1/etc/httpd/conf/ssl.crt/host1.com-server.crt
> SSLCertificateKeyFile
> /home/httpd/host1/etc/httpd/conf/ssl.key/host1.com-server.key
>
> <Files ~ "\.(cgi|shtml|phtml|php3?)$">
> SSLOptions +StdEnvVars
> </Files>
>
> <Directory "/home/httpd/cgi-bin">
> SSLOptions +StdEnvVars
> </Directory>
>
> SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
> downgrade-1.0 force-response-1.0
> CustomLog /home/httpd/host1/var/log/httpd/ssl_request_log "%t %h
> %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
>
> JkMount /secureapp1/servlet/* workerhost1
> JkMount /secureapp1/*.jsp workerhost1
>
> </VirtualHost>
>
> .....
>
> Note the way to use SSL in this case to use secureapp1 webapp ;-)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org
>
Re: [TC3.3] lib/shared -> lib/apps change
Posted by cm...@yahoo.com.
Hi Mel,
> I notice that you've renamed the
> 'TOMCAT_HOME/lib/shared' directory to
> 'TOMCAT_HOME/lib/apps' (as well as created a new
> 'container' subdirectory and rearranged the jar
> contents a bit.).
Yes, I sent the proposal few weeks ago and nobody
said -1. It's mostly a cosmetic change.
> In light of this, I'll revise
> org.apache.tomcat.startup.Main so that the
> configuration property used to set the classpath for
> classes shared amongs applications from the current
> "org.apache.tomcat.shared.classpath" to
> "org.apache.tomcat.apps.classpath".
Sure. We also need to update the docs.
Costin
[TC3.3] lib/shared -> lib/apps change
Posted by Mel Martinez <me...@yahoo.com>.
Costin,
I notice that you've renamed the
'TOMCAT_HOME/lib/shared' directory to
'TOMCAT_HOME/lib/apps' (as well as created a new
'container' subdirectory and rearranged the jar
contents a bit.).
This probably is a better name because there is the
potential for confusion in that 'shared' might be
interpreted to mean shared amongst the apps and the
container. 'apps' makes it clear that it is for just
the applications.
In light of this, I'll revise
org.apache.tomcat.startup.Main so that the
configuration property used to set the classpath for
classes shared amongs applications from the current
"org.apache.tomcat.shared.classpath" to
"org.apache.tomcat.apps.classpath".
Any objections?
Mel
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
[PATCH][tc3.3]Re: Proposed ApacheConfig.java change
Posted by Mel Martinez <me...@yahoo.com>.
{sorry about the resend - I hit the send button early
last time}
The attached PATCH modifies
org.apache.tomcat.modules.config.ApacheConfig to add
some needed flexibility. I need someone who is
running apache and tomcat3.3 using mod_jserv to test
it in that
configuration and give their feedback.
I've tested it with mod_jk on winNT and linux 6.2 and
it seems to work fine. I would of course welcome any
tests that would uncover things I may have overlooked.
As soon as I have a reasonable amount of feedback to
resolve any such oversights, I will commit the
changes.
The nature of the changes is as follows. First off,
if you haven't been using the latest tomcat3.3, you
need to tell it to auto-generate the Apache config
files for jserv and jk. To do this, the only thing you
need to do is insert an <ApacheConfig/> config
intercepter element inside the ContextManager tag like
so:
<ContextManager ... >
...
<ApacheConfig />
...
</ContextManager>
That will make sure that ApacheConfig is invoked.
In the absence of any attributes in the
<ApacheConfig/>
tag the only difference in behavior should be that the
LoadModule statements will be wrapped in
<IfModule !mod_name.c>
...
</IfModule>
tags to make the loads conditional.
In addition to making the LoadModule
statements conditional, I've also added some
attributes to the <ApacheConfig /> tag that should
greatly
help setting up Apache and Tomcat deployments:
confighome - default parent directory for the
following
paths. If not set, this defaults to TOMCAT_HOME.
Ignored whenever any of the following paths is
absolute.
jservconfig - path to write apache jserv conf file to.
If not set, defaults to
"conf/jserv/tomcat-apache.conf".
jkconfig - path to write apacke mod_jk conf file to.
If not set, defaults to "conf/jk/mod_jk.conf".
workersconfig - path to workers.properties file used
by mod_jk. If not set, defaults to
"conf/jk/workers.properties".
modjserv - path to Apache JServ plugin module file.
If not set, defaults to
"modules/ApacheModuleJServ.dll" on windows,
"modules/Jserv.nlm" on netware, and
"libexec/mod_jserv.so" everywhere else.
modjk - path to Apache mod_jk plugin file. If not
set, defaults to "modules/mod_jk.dll" on windows,
"modules/mod_jk.nlm" on netware, and
"libexec/mod_jk.so" everywhere else.
jklog - path to log file to be used by mod_jk.
All of these attributes are optional.
Please try the patch out and let me know if you have
any problems.
Send me a +1 if you think it should be committed.
Cheers,
Mel
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
[PATCH][tc3.3]Re: Proposed ApacheConfig.java change
Posted by Mel Martinez <me...@yahoo.com>.
The attached PATCH modifies
org.apache.tomcat.modules.config.ApacheConfig to add
some needed flexibility. I need someone who is
running apache and tomcat3.3 using mod_jserv to test
it in that
configuration and give their feedback.
I've tested it with mod_jk on winNT and linux 6.2 and
it seems to work fine. I would of course welcome any
tests that would uncover things I may have overlooked.
As soon as I have a reasonable amount of feedback to
resolve any such oversights, I will commit the
changes.
The nature of the changes is as follows. First off,
if you haven't been using the latest tomcat3.3, you
need to tell it to auto-generate the Apache config
files for jserv and jk. To do this, the only thing you
need to do is insert an <ApacheConfig/> config
intercepter element inside the ContextManager tag like
so:
<ContextManager ... >
...
<ApacheConfig />
...
</ContextManager>
That will make sure that ApacheConfig is invoked.
In the absence of any attributes in the
<ApacheConfig/>
tag the only difference in behavior should be that the
LoadModule statements will be wrapped in
<IfModule !mod_name.c>
...
</IfModule>
tags to make the loads conditional.
In addition to making the LoadModule
statements conditional, I've also added some
attributes to the <ApacheConfig /> tag that should
greatly
help setting up Apache and Tomcat deployments:
confighome - default parent directory for the
following
paths. If not set, this defaults to TOMCAT_HOME.
Ignored whenever any of the following paths is
absolute.
jservconfig - path to write apache jserv conf file to.
If not set, defaults to
"conf/jserv/tomcat-apache.conf".
jkconfig - path to write apacke mod_jk conf file to.
If not set, defaults to "conf/jk/mod_jk.conf".
workersconfig - path to workers.properties file used
by mod_jk. If not set, defaults to
"conf/jk/workers.properties".
modjserv - path to Apache JServ plugin module file.
If not set, defaults to
"modules/ApacheModuleJServ.dll" on windows,
"modules/Jserv.nlm" on netware, and
"libexec/mod_jserv.so" everywhere else.
modjk - path to Apache mod_jk plugin file. If not
set, defaults to "modules/mod_jk.dll" on windows,
"modules/mod_jk.nlm" on netware, and
"libexec/mod_jk.so" everywhere else.
jklog - path to log file to be used by mod_jk.
All of these attributes are optional.
Please try the patch out and let me know if you have
any problems.
Send me a +1 if you think it should be committed.
Cheers,
Mel
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
Re: Proposed ApacheConfig.java change
Posted by Mel Martinez <me...@yahoo.com>.
FYI:
I'm pretty much done with the mods I wanted to make (I
ended up adding a few extras) and am in the testing
and documenting phase. Should be ready tomorrow.
BTW: I figured out soon after my last post that the
only thing I needed to do enable auto-generation of
apache config files was to insert an <ApacheConfig/>
config intercepter element inside the ContextManager
tag like so:
<ContextManager ... >
...
<ApacheConfig />
...
</ContextManager>
That returned it to the default 3.2.1 behavior.
--- Dan Milstein <da...@shore.net> wrote:
> I would strongly vote for turning the auto-config
> back on by default for the
> following reasons (other than the fact that I
> explicity turned it back on
> when Keith fixed the ApacheConfig class):
>
> 1) This is how 3.2 worked, and how the docs specify
> that 3.3 works.
>
I think that that is a strong argument in favor of
having it enabled. The cost in startup performance is
negligible and runtime is essentially zero so I
advocate defaulting it to enabled. At a minimum, the
ApacheConfig element should be present in the
server.xml file to comment/uncomment out to toggle.
> 2) Configuration of mod_jk is notoriously
> complicated. Giving people the
> auto generated file is a big, big win.
>
Aside from the proposed mod to make the LoadModule
statement conditional, I've also added some attributes
to the <ApacheConfig /> tag that should greatly help
setting up Apache and Tomcat together:
confighome - default parent directory for the
following
paths. If not set, this defaults to TOMCAT_HOME.
Ignored whenever any of the following paths is
absolute.
jservconfig - path to write apache jserv conf file to.
If not set, defaults to
"conf/jserv/tomcat-apache.conf".
jkconfig - path to write apacke mod_jk conf file to.
If not set, defaults to "conf/jk/mod_jk.conf".
workersconfig - path to workers.properties file used
by mod_jk. If not set, defaults to
"conf/jk/workers.properties".
modjserv - path to Apache JServ plugin module file. If
not set, defaults to
"modules/ApacheModuleJServ.dll" on windows,
"modules/Jserv.nlm" on netware, and
"libexec/mod_jserv.so" everywhere else.
modjk - path to Apache mod_jk plugin file. If not set,
defaults to "modules/mod_jk.dll" on windows,
"modules/mod_jk.nlm" on netware, and
"libexec/mod_jk.so" everywhere else.
jklog - path to log file to be used by mod_jk.
All of these attributes are optional.
> 3) For the people who run it in standalone, we can
> provide a comment in the
> file telling them to "comment out the below". That
> way it would work out
> of the box for both types (standalone + behind
> Apache), and be very easy for
> people to tune to their needs.
>
> Since the syntax has changed (and I've never been a
> server.xml master), I'm
> not sure where the AutoConfig stuff would go now.
>
Lemme know if you guys like/dislike the above changes.
I should be able to have it ready early tomorrow
(Sunday). I will post a PATCH version first so I can
get some feedback on test configurations I don't have
available.
Mel
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
Re: Proposed ApacheConfig.java change
Posted by Endre Stølsvik <En...@Stolsvik.com>.
On Sat, 3 Mar 2001 cmanolache@yahoo.com wrote:
| > Costin,
| >
| > I would strongly vote for turning the auto-config back on by default for the
| > following reasons (other than the fact that I explicity turned it back on
| > when Keith fixed the ApacheConfig class):
|
| You don't need a "strong" vote - I'll do the change :-)
I just want to chime in here, and add a little "bug" report which I don't
know if still exists in 3.3. ;) It's that the auto-workers.properties
doesn't include the portnumber. I have lots of tomcats running, and need
to separate them. To use the uri-whatever-it's-called file, I have to add
one line: ($PORT is set to whatever port it's running on)
worker.ajp12.port=$PORT
I use the file every time folks restart tomcat, so that I don't have to go
around changing everyones config every time something changes.
Endre.
--
Mvh,
Endre
Re: Proposed ApacheConfig.java change
Posted by cm...@yahoo.com.
> Costin,
>
> I would strongly vote for turning the auto-config back on by default for the
> following reasons (other than the fact that I explicity turned it back on
> when Keith fixed the ApacheConfig class):
You don't need a "strong" vote - I'll do the change :-)
> 2) Configuration of mod_jk is notoriously complicated. Giving people the
> auto generated file is a big, big win.
Wouldn't be enough to add a simple command line option ?
For example, we have now a -enableAdmin ( to turn "trusted" on
the /admin app ).
We could add a "-generateConfig" - and everyone can be happy.
( plus - you'll not have problems with overriting the files )
( unless you change your mind and agree with -generateConfig I'll just
re-add the default behavior )
Costin
Re: Proposed ApacheConfig.java change
Posted by Dan Milstein <da...@shore.net>.
Costin,
I would strongly vote for turning the auto-config back on by default for the
following reasons (other than the fact that I explicity turned it back on
when Keith fixed the ApacheConfig class):
1) This is how 3.2 worked, and how the docs specify that 3.3 works.
2) Configuration of mod_jk is notoriously complicated. Giving people the
auto generated file is a big, big win.
3) For the people who run it in standalone, we can provide a comment in the
file telling them to "comment out the below". That way it would work out
of the box for both types (standalone + behind Apache), and be very easy for
people to tune to their needs.
Since the syntax has changed (and I've never been a server.xml master), I'm
not sure where the AutoConfig stuff would go now.
-Dan
cmanolache@yahoo.com wrote:
>
> > However, after upgrading to the latest and greatest
> > tomcat 3.3 version out of CVS (as of last night) I've
> > suddenly noticed that tomcat is no longer generating
> > the mod_jk.conf-auto or tomcat-apache.conf files
> > automatically.
> >
> > As near as I can tell, ApacheConfig.execute() is not
> > being called.
>
> Yes, you need to insert the ApacheConfig module in
> server.xml. We can include it by default for
> the next milestone - but I would rather not,
> many people use tomcat standalone.
>
> ( a better solution be part of the new admin interface,
> but probably after 3.3 )
>
> Costin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org
--
Dan Milstein // danmil@shore.net
Re: Proposed ApacheConfig.java change
Posted by cm...@yahoo.com.
> However, after upgrading to the latest and greatest
> tomcat 3.3 version out of CVS (as of last night) I've
> suddenly noticed that tomcat is no longer generating
> the mod_jk.conf-auto or tomcat-apache.conf files
> automatically.
>
> As near as I can tell, ApacheConfig.execute() is not
> being called.
Yes, you need to insert the ApacheConfig module in
server.xml. We can include it by default for
the next milestone - but I would rather not,
many people use tomcat standalone.
( a better solution be part of the new admin interface,
but probably after 3.3 )
Costin
Re: Proposed ApacheConfig.java change
Posted by Mel Martinez <me...@yahoo.com>.
Hi y'all.
I'm in the process of making a small tweak so that the
mod_jk.conf-auto file uses <IfModule> conditionals
around the LoadModule statments. As discussed
earlier, there should be a lot of deployment
configuration value in this tweak.
However, after upgrading to the latest and greatest
tomcat 3.3 version out of CVS (as of last night) I've
suddenly noticed that tomcat is no longer generating
the mod_jk.conf-auto or tomcat-apache.conf files
automatically.
As near as I can tell, ApacheConfig.execute() is not
being called.
Is this a bug or do I need to configure something in
server.xml now to make this happen? (With tc3.2.1 I
didn't do anything in particular to cause these to be
generated.)
I look forward to some enlightenment.
Cheers,
Mel
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
Re: Proposed Server.xml Change (was RE: Bugzilla #512 is Bunk)
Posted by cm...@yahoo.com.
> Right, but that is excruciating to configure and more excruciating to
> maintain...
We need to fix that :-)
> Why not use two copies of Tomcat, each with their own mod_jk.conf-auto which
> can be included in the appropriate VirtualHost section?
Use 2 copies of tomcat as a workaround for stupid config mechanism ( I can
say that, I wrote a large part of it :-) ?
What if you have 1000 virtual hosts ?
Don't get me wrong, sometimes it is good to have multiple instances of
tomcat ( preferably on a farm of servers, or even on the same computer :-),
for many valid reasons - but I wouldn't do it as a workaround for
config.
> Then we could map each ContextManager to one VirtualHost with one
> auto-generated config file, and Include them from httpd.conf for each
> VirtualHost accordingly?
Except ContextManager represents a "Server" instance, not a virtual host.
Mea culpa - a lot of people said that we need a VirtualHost object, but I
(still) think it is not actually needed - Container can represent any
"group" of URLs, including VirtualHost, Context, URLPattern, or any other
mechansim.
And Modules ( including config modules ) do have access to all this
information and can generate anything they need.
While this may be a bit confusing ( why don't we treat a virtual host in a
special way ) it is also much more flexible and simpler to do, with
simpler code.
> Just some ideas...
Thanks Steve. Please don't give up - maybe we can find a way to improve
the config generator, or you may help with mod_webapp ( or ajp14 ) -
i.e. extend the protocol to send Apache all the information about the
hosts/web applications.
Costin