Re: Proposed ApacheConfig.java change
On Sat, 3 Mar 2001 [EMAIL PROTECTED] 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[PATCH][tc3.3]Re: Proposed ApacheConfig.java change
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/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[PATCH][tc3.3]Re: Proposed ApacheConfig.java change
{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/
Index: ApacheConfig.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/ApacheConfig.java,v
retrieving revision 1.6
diff -u -r1.6 ApacheConfig.java
--- ApacheConfig.java 2001/03/02 04:49:11 1.6
+++ ApacheConfig.java 2001/03/04 22:39:14
@@ -1,4 +1,4 @@
-/*
+/* $Id$
*
*
* The Apache Software License, Version 1.1
@@ -70,22 +70,97 @@
import org.apache.tomcat.modules.server.Ajp13Interceptor;
/**
- * Used by ContextManager to generate automatic apache configurations
- *
- * @author Costin Manolache
+Generates automatic apache configurations based on
+the Tomcat server.xml settings and the war contexts
+initialized during startup.
+p
+This config interceptor is enabled by inserting an ApacheConfig
+element in the b\ContextManager/b tag body inside
+the server.xml file like so:
+pre
+* ContextManager ...
+* ...
+* bApacheConfig/b ioptions/i /
+* ...
+* /ContextManager
+/pre
+where ioptions/i can include any of the following attributes:
+ul
+ libconfighome/b - default parent directory for the following paths.
+If not set, this defaults to TOMCAT_HOME. Ignored
+whenever any of the following paths is absolute.
+ /li
+ libjservconfig/b - path to write apache jserv conf file to. If
+ not set, defaults to
+ "conf/jserv/tomcat-apache.conf"./li
+ libjkconfig/b - path to write apacke mod_jk conf file to. If
+not set, defaults to
+"conf/jk/mod_jk.conf"./li
+ libworkersconfig/b - path to workers.properties file used by
+mod_jk. If not set, defaults to
+"conf/jk/workers.properties"./li
+ libmodjserv/b - path to Apache JServ plugin module file. If not
+ set, defaults to "modules/ApacheModuleJServ.dll"
+ on windows, "modules/Jserv.nlm" on netware, and
+
RE: [PATCH][tc3.3]Re: Proposed ApacheConfig.java change
We can -1 later :) go for it , it looks nice.
I dont understand your question fully .., you are asking about to
generate the complete javadocs for all packages ?
8
javadoc packagenames="org.apache.tomcat.*"
sourcepath="src/share;src/facade22"
destdir="${tomcat.build}/webapps/ROOT/javadoc"
author="true"
version="true"
use="true"
windowtitle="Tomcat internal API"
doctitle="Tomcat internal"
bottom="Copyright 2000 Apache Software Foundation. All
Rights Reserved."/
8
should work..
Saludos ,
Ignacio J. Ortega
-Mensaje original-
De: Mel Martinez [mailto:[EMAIL PROTECTED]]
Enviado el: lunes 5 de marzo de 2001 0:04
Para: [EMAIL PROTECTED]
Asunto: [PATCH][tc3.3]Re: Proposed ApacheConfig.java change
{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/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Proposed ApacheConfig.java change
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Proposed ApacheConfig.java change
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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Proposed ApacheConfig.java change
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 [EMAIL PROTECTED] 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/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Proposed ApacheConfig.java change
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/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Proposed ApacheConfig.java change
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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
