[TC4] SingleSignOnSupport broken?
Hi I'm using the TC4 sources from cvs from Feb 17 (well after the last commit to org.apache.catalina.authenticator.SingleSignOn), with SlideRealm. I had been using three different webapps; each web.xml file had identical realm name, as in: login-config auth-methodBASIC/auth-method realm-namemyRealm/realm-name Without the SingleSignOn valve, this worked well; well, subject to a problem with Internet Explorer which i'm asking about in a separate post. Because of that problem with Internet Explorer, i tried single sign on support instead. However, it doesn't appear to work, in that I get an authentication challenge for each new realm (when i give the realm in each webapp a different name), and the logs always say "Checking for SSO cookie - SSO cookie is not present", as in: 2001-03-02 00:28:50 StandardHost[localhost]: Mapping request URI '/TestDrive-webdav/' 2001-03-02 00:28:50 StandardHost[localhost]: Trying the longest context path prefix 2001-03-02 00:28:50 StandardHost[localhost]: Mapped to context '/TestDrive-webdav' 2001-03-02 00:28:56 SingleSignOn[localhost]: Process request for '/TestDrive-webdav/' 2001-03-02 00:28:56 SingleSignOn[localhost]: Checking for SSO cookie 2001-03-02 00:28:56 SingleSignOn[localhost]: SSO cookie is not present i have turned on user cookie approval in the browser, and the only cookie which is getting set is the JSESSIONID cookie. Am i doing something which is obviously wrong? I've got the valve at the Host level. thanks Jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Tomcat 4 unpacking of WAR files behavior
What is the expected behaviour of Tomcat 4 when starting/stopping in regards to unpacking war files. I noticed what to me seems like strange behaviour. The Host is configured in server.xml with unpackWARs="true". ls of webapps before starting tomcat, notice that some of the war files are not expanded out. $ ls -l webapps total 1091 drwxr-xr-x 9 tomcatd tomcatd 512 Feb 18 09:06 ROOT drwxr-xr-x 8 tomcatd tomcatd 512 Feb 18 09:06 examples drwxr-xr-x 5 tomcatd tomcatd 512 Feb 17 06:42 jdbc-doc -rw-r--r-- 1 tomcatd tomcatd168332 Feb 15 16:19 jdbc-doc.war drwxr-xr-x 4 tomcatd tomcatd 512 Feb 25 20:27 jdbc-examples -rw-r--r-- 1 tomcatd tomcatd 39156 Feb 15 16:19 jdbc-examples.war drwxr-xr-x 5 tomcatd tomcatd 512 Feb 16 13:20 jndi-doc -rw-r--r-- 1 tomcatd tomcatd 79042 Feb 15 16:37 jndi-doc.war drwxr-xr-x 4 tomcatd tomcatd 512 Feb 17 06:42 jndi-examples -rw-r--r-- 1 tomcatd tomcatd 33516 Feb 15 16:37 jndi-examples.war -rw-r--r-- 1 tomcatd tomcatd411591 Mar 1 06:09 jsp-tests.war drwxr-xr-x 5 tomcatd tomcatd 512 Feb 18 09:06 manager drwxr-xr-x 5 tomcatd tomcatd 512 Feb 17 06:42 request-doc -rw-r--r-- 1 tomcatd tomcatd159409 Feb 16 13:25 request-doc.war drwxr-xr-x 4 tomcatd tomcatd 512 Feb 17 06:42 request-examples -rw-r--r-- 1 tomcatd tomcatd 36690 Feb 16 13:25 request-examples.war -rw-r--r-- 1 tomcatd tomcatd 51150 Feb 26 20:36 scrape-doc.war -rw-r--r-- 1 tomcatd tomcatd 86902 Feb 26 20:36 scrape-examples.war drwxr-xr-x 5 tomcatd tomcatd 512 Feb 18 09:06 webdav ls of webapps after starting tomcat, all war files are expanded. $ ls -l webapps total 1094 drwxr-xr-x 9 tomcatd tomcatd 512 Feb 18 09:06 ROOT drwxr-xr-x 8 tomcatd tomcatd 512 Feb 18 09:06 examples drwxr-xr-x 5 tomcatd tomcatd 512 Feb 17 06:42 jdbc-doc -rw-r--r-- 1 tomcatd tomcatd168332 Feb 15 16:19 jdbc-doc.war drwxr-xr-x 4 tomcatd tomcatd 512 Feb 25 20:27 jdbc-examples -rw-r--r-- 1 tomcatd tomcatd 39156 Feb 15 16:19 jdbc-examples.war drwxr-xr-x 5 tomcatd tomcatd 512 Feb 16 13:20 jndi-doc -rw-r--r-- 1 tomcatd tomcatd 79042 Feb 15 16:37 jndi-doc.war drwxr-xr-x 4 tomcatd tomcatd 512 Feb 17 06:42 jndi-examples -rw-r--r-- 1 tomcatd tomcatd 33516 Feb 15 16:37 jndi-examples.war drwxr-xr-x 5 tomcatd tomcatd 512 Mar 1 08:27 jsp-tests -rw-r--r-- 1 tomcatd tomcatd411591 Mar 1 06:09 jsp-tests.war drwxr-xr-x 5 tomcatd tomcatd 512 Feb 18 09:06 manager drwxr-xr-x 5 tomcatd tomcatd 512 Feb 17 06:42 request-doc -rw-r--r-- 1 tomcatd tomcatd159409 Feb 16 13:25 request-doc.war drwxr-xr-x 4 tomcatd tomcatd 512 Feb 17 06:42 request-examples -rw-r--r-- 1 tomcatd tomcatd 36690 Feb 16 13:25 request-examples.war drwxr-xr-x 5 tomcatd tomcatd 512 Mar 1 08:28 scrape-doc -rw-r--r-- 1 tomcatd tomcatd 51150 Feb 26 20:36 scrape-doc.war drwxr-xr-x 4 tomcatd tomcatd 512 Mar 1 08:28 scrape-examples -rw-r--r-- 1 tomcatd tomcatd 86902 Feb 26 20:36 scrape-examples.war drwxr-xr-x 5 tomcatd tomcatd 512 Feb 18 09:06 webdav ls of webapps after stopping tomcat, notice that the war files that tomcat had expanded out now have their directories removed. $ ls -l webapps total 1091 drwxr-xr-x 9 tomcatd tomcatd 512 Feb 18 09:06 ROOT drwxr-xr-x 8 tomcatd tomcatd 512 Feb 18 09:06 examples drwxr-xr-x 5 tomcatd tomcatd 512 Feb 17 06:42 jdbc-doc -rw-r--r-- 1 tomcatd tomcatd168332 Feb 15 16:19 jdbc-doc.war drwxr-xr-x 4 tomcatd tomcatd 512 Feb 25 20:27 jdbc-examples -rw-r--r-- 1 tomcatd tomcatd 39156 Feb 15 16:19 jdbc-examples.war drwxr-xr-x 5 tomcatd tomcatd 512 Feb 16 13:20 jndi-doc -rw-r--r-- 1 tomcatd tomcatd 79042 Feb 15 16:37 jndi-doc.war drwxr-xr-x 4 tomcatd tomcatd 512 Feb 17 06:42 jndi-examples -rw-r--r-- 1 tomcatd tomcatd 33516 Feb 15 16:37 jndi-examples.war -rw-r--r-- 1 tomcatd tomcatd411591 Mar 1 06:09 jsp-tests.war drwxr-xr-x 5 tomcatd tomcatd 512 Feb 18 09:06 manager drwxr-xr-x 5 tomcatd tomcatd 512 Feb 17 06:42 request-doc -rw-r--r-- 1 tomcatd tomcatd159409 Feb 16 13:25 request-doc.war drwxr-xr-x 4 tomcatd tomcatd 512 Feb 17 06:42 request-examples -rw-r--r-- 1 tomcatd tomcatd 36690 Feb 16 13:25 request-examples.war -rw-r--r-- 1 tomcatd tomcatd 51150 Feb 26 20:36 scrape-doc.war -rw-r--r-- 1 tomcatd tomcatd 86902 Feb 26 20:36 scrape-examples.war drwxr-xr-x 5 tomcatd tomcatd 512 Feb 18 09:06 webdav What is the point in having Tomcat 4 unpack the war files if it removes the unpacked war file directory when Tomcat stops? Why are some unpacked war file directories removed, and others are left alone? What if you modified the web application you installed, or it manages some properties files in its own
Re: [TC4] SingleSignOnSupport broken?
Jason Harrop wrote: Hi I'm using the TC4 sources from cvs from Feb 17 (well after the last commit to org.apache.catalina.authenticator.SingleSignOn), with SlideRealm. I had been using three different webapps; each web.xml file had identical realm name, as in: login-config auth-methodBASIC/auth-method realm-namemyRealm/realm-name Without the SingleSignOn valve, this worked well; well, subject to a problem with Internet Explorer which i'm asking about in a separate post. Because of that problem with Internet Explorer, i tried single sign on support instead. However, it doesn't appear to work, in that I get an authentication challenge for each new realm (when i give the realm in each webapp a different name), and the logs always say "Checking for SSO cookie - SSO cookie is not present", as in: 2001-03-02 00:28:50 StandardHost[localhost]: Mapping request URI '/TestDrive-webdav/' 2001-03-02 00:28:50 StandardHost[localhost]: Trying the longest context path prefix 2001-03-02 00:28:50 StandardHost[localhost]: Mapped to context '/TestDrive-webdav' 2001-03-02 00:28:56 SingleSignOn[localhost]: Process request for '/TestDrive-webdav/' 2001-03-02 00:28:56 SingleSignOn[localhost]: Checking for SSO cookie 2001-03-02 00:28:56 SingleSignOn[localhost]: SSO cookie is not present i have turned on user cookie approval in the browser, and the only cookie which is getting set is the JSESSIONID cookie. Am i doing something which is obviously wrong? I've got the valve at the Host level. There is an (undocumented) restriction in the current implementation when using BASIC or DIGEST authentication with single sign on support -- the value you specify for realm in the security constraints needs to be the same for all of the webapps that are participating in the single sign on environment. This is probably a bug (most of my development work was on using form-based login with this), but it should work if you use the same realm string. thanks Jason Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [PATCH] custom tag performance problem
Casey, I'm reviewing this patch for possible inclusion in Tomcat 3.2.2. Its a little late in the game to be changing things, but the patch looks OK. Is is possible for you to provide the pages that you used for your test runs so that I can test this more thoroughly? Marc Saegesser -Original Message- From: Casey Lucas [mailto:[EMAIL PROTECTED]] Sent: Sunday, February 11, 2001 1:55 PM To: [EMAIL PROTECTED] Subject: [PATCH] custom tag performance problem It's great to see that the 3.2.2 beta is out but it was sad to see that there's still a performance problem in certain situations with custom tags. I submitted the patch a few weeks back but I'm sure you all are very busy. So, given the recent threads about performance, I'll plea my case again... The problem should be apparent in at least two situations: 1. if you are using custom tags that derive from BodyTagSupport and have larger than 8K body. 2. if you are using a lot of nested tags (e.g. inside iteration type tags.) Basically the problem is that BodyContentImpl allocates a new buffer in situations where it doesn't need to. This causes a lot of 8K or larger buffers to be used -- ouch. After applying the patch, my test runs went from spending an average of 17% time in BodyContentImpl.reAllocBuff and BodyContentImpl.clear to spending an average of 5.6% time in BodyContentImpl.reAllocBuff (clear had almost 0% time.) I've attached the patch for BodyContentImpl.java. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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]
NLS Support
hi , Does Tomcat supports the NLS for different language character encoding ? (like the IBM WebSphere does ?) If so, how about one goes of doing it ?? thanks, dipak
RE: Proposed ApacheConfig tweak:Re: Bugzilla #512 is Bunk
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]
cvs commit: jakarta-tomcat/src/tests/webpages/jsp HelloWorld.jsp
larryi 01/03/01 09:54:35 Modified:src/tests/webpages/jsp HelloWorld.jsp Log: Modify so you can tell if it is being served statically. Revision ChangesPath 1.3 +2 -2 jakarta-tomcat/src/tests/webpages/jsp/HelloWorld.jsp Index: HelloWorld.jsp === RCS file: /home/cvs/jakarta-tomcat/src/tests/webpages/jsp/HelloWorld.jsp,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- HelloWorld.jsp1999/11/04 01:39:59 1.2 +++ HelloWorld.jsp2001/03/01 17:54:30 1.3 @@ -1,3 +1,3 @@ -html -HelloWorld +% String s="World"; %html +Hello%= s % /html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/test/matchers HttpStatusMatch.java ResponseMatch.java
larryi 01/03/01 09:56:28
Modified:src/share/org/apache/tomcat/util/test/matchers
HttpStatusMatch.java ResponseMatch.java
Log:
Update log output so you can tell if matching for true or false.
Revision ChangesPath
1.2 +5 -2
jakarta-tomcat/src/share/org/apache/tomcat/util/test/matchers/HttpStatusMatch.java
Index: HttpStatusMatch.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/test/matchers/HttpStatusMatch.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- HttpStatusMatch.java 2001/02/09 03:48:17 1.1
+++ HttpStatusMatch.java 2001/03/01 17:56:21 1.2
@@ -124,8 +124,11 @@
responseLine.indexOf(returnCode) -1);
if( match != testCondition ) {
responseStatus = false;
- log("Expecting: " + returnCode );
- log("Got : " + responseLine);
+ if( testCondition )
+ log("Expecting: " + returnCode );
+ else
+ log("Not Expecting: " + returnCode );
+ log("Got : " + responseLine);
}
}
1.2 +4 -1
jakarta-tomcat/src/share/org/apache/tomcat/util/test/matchers/ResponseMatch.java
Index: ResponseMatch.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/test/matchers/ResponseMatch.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ResponseMatch.java2001/02/09 03:48:17 1.1
+++ ResponseMatch.java2001/03/01 17:56:23 1.2
@@ -127,7 +127,10 @@
boolean match=responseBody.indexOf( responseMatch ) = 0;
if( match != testCondition ) {
responseStatus = false;
- log("ERROR: expecting match on " + responseMatch);
+ if( testCondition )
+ log("ERROR: expecting match on " + responseMatch);
+ else
+ log("ERROR: expecting no match on " + responseMatch);
log("GOT: " );
log(responseBody );
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/tests/webpages/WEB-INF test-tomcat.xml
larryi 01/03/01 09:59:11
Modified:src/tests/webpages/WEB-INF test-tomcat.xml
Log:
Added a test to check if a file ending with ".jsp%20" is served. It should
result in a 404 Not found error.
Revision ChangesPath
1.26 +7 -1 jakarta-tomcat/src/tests/webpages/WEB-INF/test-tomcat.xml
Index: test-tomcat.xml
===
RCS file: /home/cvs/jakarta-tomcat/src/tests/webpages/WEB-INF/test-tomcat.xml,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- test-tomcat.xml 2001/02/28 20:35:15 1.25
+++ test-tomcat.xml 2001/03/01 17:59:03 1.26
@@ -16,7 +16,7 @@
early tests.
--
- property name="revision" value="$Revision: 1.25 $" /
+ property name="revision" value="$Revision: 1.26 $" /
property name="host" value="127.0.0.1" /
property name="port" value="8080" /
property name="outputType" value="text" /
@@ -1102,6 +1102,12 @@
gtest request="GET /test/meta-inf/Manifest.mf HTTP/1.0"
returnCode="${http.protocol} 4" /
+
+ gtest description="This URL should return 404 Not Found"
+ request="GET /test/jsp/HelloWorld.jsp%20 HTTP/1.0"
+ returnCode="${http.protocol} 404"
+ /
+
/target
!-- All targets --
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Bugzilla #512 is Bunk
Steve, Thanks so much! This is very, very helpful -- I am not master of Apache configuration, and the virtual host thing is important. I'll try to work this into the docs some time soonish... -Dan Stephen Jones wrote: The following bug is not a bug: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=512 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 (2) To configure Apache for your Tomcat Contexts using Alias, Location, and Directory Apache Directives (3) To configure mod_jk itself using all the directives starting with Jk (JkWorkersFile, JkLogFile, JkMount, etc). 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 ) The directives in (2) are definitely legal, but I don't know about those in (3) since they are custom. Does anyone know whether these would work within the VirtualHost context? The bug was reported by someone using Apache 1.3.14; they recieved a core dump dereferencing a null pointer to something that was supposed to contain Apache configuration info (a jk_server_conf_t). I am using Apache 1.3.17; I recieved this polite and informative (wow, from open source software?) error message: sudo /usr/local/apache/bin/apachectl startssl Syntax error on line 8 of /usr/local/tomcat/conf/mod_jk.conf-auto: LoadModule cannot occur within VirtualHost section /usr/local/apache/bin/apachectl startssl: httpd could not be started Provided that the custom directives (3) will work within a VirtualHost context, the solution to this problem is to create a custom configuration file based on mod_jk.conf-auto, move the LoadModule directive into it, and then Include it from within your VirtualHost context. If the directives (3) do work, another option would be for Tomcat to change the code to not generate the LoadModule directive, which prevents this level of configurability, and just make people type it in. Hope this is helpful, Steve Jones - 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: Bugzilla #512 is Bunk
JkWorkersFiles is the main problem inside of a VirtualHost. I don't know about JkLogFile. JkMount is legal inside of a VirtualHost. - Original Message - From: "Stephen Jones" [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, February 28, 2001 8:08 PM Subject: Bugzilla #512 is Bunk The following bug is not a bug: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=512 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 (2) To configure Apache for your Tomcat Contexts using Alias, Location, and Directory Apache Directives (3) To configure mod_jk itself using all the directives starting with Jk (JkWorkersFile, JkLogFile, JkMount, etc). 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 ) The directives in (2) are definitely legal, but I don't know about those in (3) since they are custom. Does anyone know whether these would work within the VirtualHost context? The bug was reported by someone using Apache 1.3.14; they recieved a core dump dereferencing a null pointer to something that was supposed to contain Apache configuration info (a jk_server_conf_t). I am using Apache 1.3.17; I recieved this polite and informative (wow, from open source software?) error message: sudo /usr/local/apache/bin/apachectl startssl Syntax error on line 8 of /usr/local/tomcat/conf/mod_jk.conf-auto: LoadModule cannot occur within VirtualHost section /usr/local/apache/bin/apachectl startssl: httpd could not be started Provided that the custom directives (3) will work within a VirtualHost context, the solution to this problem is to create a custom configuration file based on mod_jk.conf-auto, move the LoadModule directive into it, and then Include it from within your VirtualHost context. If the directives (3) do work, another option would be for Tomcat to change the code to not generate the LoadModule directive, which prevents this level of configurability, and just make people type it in. Hope this is helpful, Steve Jones - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[Bug 109] New - Not able to run demo JSP pages BugRat Report#115
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=109
*** shadow/109 Thu Mar 1 11:27:33 2001
--- shadow/109.tmp.14226Thu Mar 1 11:27:33 2001
***
*** 0
--- 1,73
+ ++
+ | Not able to run demo JSP pages BugRat Report#115 |
+ ++
+ |Bug #: 109 Product: Tomcat 3|
+ | Status: RESOLVEDVersion: 3.2.1 Final |
+ | Resolution: INVALIDPlatform: All |
+ | Severity: Normal OS/Version: All |
+ | Priority: High Component: Jasper |
+ ++
+ | Assigned To: [EMAIL PROTECTED]|
+ | Reported By: [EMAIL PROTECTED]|
+ | CC list: Cc: |
+ ++
+ | URL: |
+ ++
+ | DESCRIPTION |
+
+ I get the following error:
+
+ Error: 500
+
+ Location: /examples/jsp/sessions/carts.jsp
+
+ Internal Servlet Error:
+
+ org.apache.jasper.JasperException: Unable to compile class for JSPjsp-javac:
+invalid flag: -encoding
+ use: jsp-javac [-g][-O][-debug][-depend][-nowarn][-verbose][-classpath
+path][-nowrite][-d dir] file.java...
+
+ at org.apache.jasper.compiler.Compiler.compile(Compiler.java, Compiled Code)
+ at org.apache.jasper.runtime.JspServlet.loadJSP(JspServlet.java, Compiled
+Code)
+ at
+org.apache.jasper.runtime.JspServlet$JspServletWrapper.loadIfNecessary(JspServlet.java,
+ Compiled Code)
+ at
+org.apache.jasper.runtime.JspServlet$JspServletWrapper.service(JspServlet.java,
+Compiled Code)
+ at org.apache.jasper.runtime.JspServlet.serviceJspFile(JspServlet.java,
+Compiled Code)
+ at org.apache.jasper.runtime.JspServlet.service(JspServlet.java, Compiled
+Code)
+ at javax.servlet.http.HttpServlet.service(HttpServlet.java, Compiled Code)
+ at org.apache.tomcat.core.ServletWrapper.handleRequest(ServletWrapper.java,
+Compiled Code)
+ at org.apache.tomcat.core.ContextManager.service(ContextManager.java,
+Compiled Code)
+ at
+org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConnectionHandler.java,
+ Compiled Code)
+ at org.apache.tomcat.service.TcpConnectionThread.run(SimpleTcpEndpoint.java,
+Compiled Code)
+ at java.lang.Thread.run(Thread.java, Compiled Code)
+
+
+ javac --help output is:
+
+ /usr/local/jakarta-tomcat/doc:javac --help
+ --help is an invalid option or argument.
+ Usage: javac options source files
+
+ where options includes:
+ -g Generate all debugging info
+ -g:noneGenerate no debugging info
+ -g:{lines,vars,source} Generate only some debugging info
+ -O Optimize; may hinder debugging or enlarge class files
+ -nowarnGenerate no warnings
+ -verbose Output messages about what the compiler is doing
+ -deprecation Output source locations where deprecated APIs are used
+ -classpath path Specify where to find user class files
+ -sourcepath path Specify where to find input source files
+ -bootclasspath path Override location of bootstrap class files
+ -extdirs dirsOverride location of installed extensions
+ -d directory Specify where to place generated class files
+ -encoding encoding Specify character encoding used by source files
+ -target release Generate class files for specific VM version
+
+
+ So "javac" does support "-encoding".
+
+ Not sure why this is happenning -
+
+ ANy help appreciated.
+
+ --- Additional Comments From [EMAIL PROTECTED] 2001-03-01 11:27 ---
+ Looks like Jasper was seeing an old JDK.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Tomcat 4 unpacking of WAR files behavior
What is the expected behaviour of Tomcat 4 when starting/stopping in regards to unpacking war files. I noticed what to me seems like strange behaviour. The Host is configured in server.xml with unpackWARs="true". ls of webapps before starting tomcat, notice that some of the war files are not expanded out. $ ls -l webapps total 1091 drwxr-xr-x 9 tomcatd tomcatd 512 Feb 18 09:06 ROOT drwxr-xr-x 8 tomcatd tomcatd 512 Feb 18 09:06 examples drwxr-xr-x 5 tomcatd tomcatd 512 Feb 17 06:42 jdbc-doc -rw-r--r-- 1 tomcatd tomcatd168332 Feb 15 16:19 jdbc-doc.war drwxr-xr-x 4 tomcatd tomcatd 512 Feb 25 20:27 jdbc-examples -rw-r--r-- 1 tomcatd tomcatd 39156 Feb 15 16:19 jdbc-examples.war drwxr-xr-x 5 tomcatd tomcatd 512 Feb 16 13:20 jndi-doc -rw-r--r-- 1 tomcatd tomcatd 79042 Feb 15 16:37 jndi-doc.war drwxr-xr-x 4 tomcatd tomcatd 512 Feb 17 06:42 jndi-examples -rw-r--r-- 1 tomcatd tomcatd 33516 Feb 15 16:37 jndi-examples.war -rw-r--r-- 1 tomcatd tomcatd411591 Mar 1 06:09 jsp-tests.war drwxr-xr-x 5 tomcatd tomcatd 512 Feb 18 09:06 manager drwxr-xr-x 5 tomcatd tomcatd 512 Feb 17 06:42 request-doc -rw-r--r-- 1 tomcatd tomcatd159409 Feb 16 13:25 request-doc.war drwxr-xr-x 4 tomcatd tomcatd 512 Feb 17 06:42 request-examples -rw-r--r-- 1 tomcatd tomcatd 36690 Feb 16 13:25 request-examples.war -rw-r--r-- 1 tomcatd tomcatd 51150 Feb 26 20:36 scrape-doc.war -rw-r--r-- 1 tomcatd tomcatd 86902 Feb 26 20:36 scrape-examples.war drwxr-xr-x 5 tomcatd tomcatd 512 Feb 18 09:06 webdav ls of webapps after starting tomcat, all war files are expanded. $ ls -l webapps total 1094 drwxr-xr-x 9 tomcatd tomcatd 512 Feb 18 09:06 ROOT drwxr-xr-x 8 tomcatd tomcatd 512 Feb 18 09:06 examples drwxr-xr-x 5 tomcatd tomcatd 512 Feb 17 06:42 jdbc-doc -rw-r--r-- 1 tomcatd tomcatd168332 Feb 15 16:19 jdbc-doc.war drwxr-xr-x 4 tomcatd tomcatd 512 Feb 25 20:27 jdbc-examples -rw-r--r-- 1 tomcatd tomcatd 39156 Feb 15 16:19 jdbc-examples.war drwxr-xr-x 5 tomcatd tomcatd 512 Feb 16 13:20 jndi-doc -rw-r--r-- 1 tomcatd tomcatd 79042 Feb 15 16:37 jndi-doc.war drwxr-xr-x 4 tomcatd tomcatd 512 Feb 17 06:42 jndi-examples -rw-r--r-- 1 tomcatd tomcatd 33516 Feb 15 16:37 jndi-examples.war drwxr-xr-x 5 tomcatd tomcatd 512 Mar 1 08:27 jsp-tests -rw-r--r-- 1 tomcatd tomcatd411591 Mar 1 06:09 jsp-tests.war drwxr-xr-x 5 tomcatd tomcatd 512 Feb 18 09:06 manager drwxr-xr-x 5 tomcatd tomcatd 512 Feb 17 06:42 request-doc -rw-r--r-- 1 tomcatd tomcatd159409 Feb 16 13:25 request-doc.war drwxr-xr-x 4 tomcatd tomcatd 512 Feb 17 06:42 request-examples -rw-r--r-- 1 tomcatd tomcatd 36690 Feb 16 13:25 request-examples.war drwxr-xr-x 5 tomcatd tomcatd 512 Mar 1 08:28 scrape-doc -rw-r--r-- 1 tomcatd tomcatd 51150 Feb 26 20:36 scrape-doc.war drwxr-xr-x 4 tomcatd tomcatd 512 Mar 1 08:28 scrape-examples -rw-r--r-- 1 tomcatd tomcatd 86902 Feb 26 20:36 scrape-examples.war drwxr-xr-x 5 tomcatd tomcatd 512 Feb 18 09:06 webdav ls of webapps after stopping tomcat, notice that the war files that tomcat had expanded out now have their directories removed. $ ls -l webapps total 1091 drwxr-xr-x 9 tomcatd tomcatd 512 Feb 18 09:06 ROOT drwxr-xr-x 8 tomcatd tomcatd 512 Feb 18 09:06 examples drwxr-xr-x 5 tomcatd tomcatd 512 Feb 17 06:42 jdbc-doc -rw-r--r-- 1 tomcatd tomcatd168332 Feb 15 16:19 jdbc-doc.war drwxr-xr-x 4 tomcatd tomcatd 512 Feb 25 20:27 jdbc-examples -rw-r--r-- 1 tomcatd tomcatd 39156 Feb 15 16:19 jdbc-examples.war drwxr-xr-x 5 tomcatd tomcatd 512 Feb 16 13:20 jndi-doc -rw-r--r-- 1 tomcatd tomcatd 79042 Feb 15 16:37 jndi-doc.war drwxr-xr-x 4 tomcatd tomcatd 512 Feb 17 06:42 jndi-examples -rw-r--r-- 1 tomcatd tomcatd 33516 Feb 15 16:37 jndi-examples.war -rw-r--r-- 1 tomcatd tomcatd411591 Mar 1 06:09 jsp-tests.war drwxr-xr-x 5 tomcatd tomcatd 512 Feb 18 09:06 manager drwxr-xr-x 5 tomcatd tomcatd 512 Feb 17 06:42 request-doc -rw-r--r-- 1 tomcatd tomcatd159409 Feb 16 13:25 request-doc.war drwxr-xr-x 4 tomcatd tomcatd 512 Feb 17 06:42 request-examples -rw-r--r-- 1 tomcatd tomcatd 36690 Feb 16 13:25 request-examples.war -rw-r--r-- 1 tomcatd tomcatd 51150 Feb 26 20:36 scrape-doc.war -rw-r--r-- 1 tomcatd tomcatd 86902 Feb 26 20:36 scrape-examples.war drwxr-xr-x 5 tomcatd tomcatd 512 Feb 18 09:06 webdav What is the point in having Tomcat 4 unpack the war files if it removes the unpacked war file directory when Tomcat stops? I think it was to make it equivalent to running the web application directly from the WAR. Now that we actually
re-use of tag objects via Tag.release method
Looking at the rendered jsp - java files in the work directory (and noticing the calls to Tag.release), I realized that Jasper is not reusing tags that it creates. So, my question is: Has there been any conversations about implementing tag reuse in Jasper? -Casey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: re-use of tag objects via Tag.release method
Casey Lucas wrote: Looking at the rendered jsp - java files in the work directory (and noticing the calls to Tag.release), I realized that Jasper is not reusing tags that it creates. So, my question is: Has there been any conversations about implementing tag reuse in Jasper? To my knowledge, there has been no conversation on the topic. But, it'd be great to start one :-). Besides the obvious performance gains, having agressive tag reuse in tomcat would also be great for taglibs testing purposes. Properly handling 'release()' in a tag can be tricky and bugs will only show up when a tag is run in a container that supports 'tag reuse'. -- Pierre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Xerces Sealing Violation Test
Hi, I have added a test servlet for the "sealing violation" problem with xerces. I also updated build scripts so that they pick up xerces.jar to test this case. tester.xml has been modified to include this case to the "tester". Cheers, -Amy -- Amy Roh Java 2 Enterprise Edition Sun Microsystems, Inc. XercesTest.zip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tomcat 4 unpacking of WAR files behavior
I consider this a bug. Tomcat should not be removing contexts that have been expanded out into a directory in webapps. If unpackWARs="false", then nothing is expanded out into webapss, the war file is expanded out as needed into the work dir, correct? The JARs are indeed expanded as a temporary fix for Jasper. There is hope that we can perhaps use a tweaked version of javac which would load classes from a classloader (in which case no expanding is needed). But if unpackWARs="true", what should the behaviour be in the following cases: A war file exits, but no directory exists matching war file prefix. - create directory name matching war file prefix and expand war file. A war file exists, and a corresponding directory exists. The war file last mod time is older than directory. - Don't expand war file. That's what is done right now, except that the deployed (read : expanded) WAR is undeployed when you shut down Catalina. A war file exists, and a corresponding directory exists. The war file last mod time is newer than the directory. - ??? You have one of two cases, a completely different web app exists in a directory with the same name as a new war file, or an updated war file for was installed and the directory is for the previously expanded version. What now? And when tomcat is shutdown it should not remove any unpacked war files, this can significantly increase the time it takes tomcat to startup/shutdown. It will only remove files if it did actually deploy the corresponding WAR. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Tomcat 4 unpacking of WAR files behavior
If unpackWARs="false", then nothing is expanded out into webapss, the war file is expanded out as needed into the work dir, correct? The JARs are indeed expanded as a temporary fix for Jasper. There is hope that we can perhaps use a tweaked version of javac which would load classes from a classloader (in which case no expanding is needed). Seems to me that running from a war directly would be a problem for performance anyway. Wouldn't you have to unzip them somewhere? RAM? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tomcat 4 unpacking of WAR files behavior
Remy, What I am trying to do is start a discussion of _what_ the behaviour should be, so it can be fixed. I already consider the current behaviour to be broken. For example deploying a war on starutp, then undeploying it on shutdown adds unnecessary overhead to the tomcat start/stop processing. This would be a huge issue in a hosting environment where you might have 100's of war files. Regards, Glenn Remy Maucherat wrote: I consider this a bug. Tomcat should not be removing contexts that have been expanded out into a directory in webapps. If unpackWARs="false", then nothing is expanded out into webapss, the war file is expanded out as needed into the work dir, correct? The JARs are indeed expanded as a temporary fix for Jasper. There is hope that we can perhaps use a tweaked version of javac which would load classes from a classloader (in which case no expanding is needed). But if unpackWARs="true", what should the behaviour be in the following cases: A war file exits, but no directory exists matching war file prefix. - create directory name matching war file prefix and expand war file. A war file exists, and a corresponding directory exists. The war file last mod time is older than directory. - Don't expand war file. That's what is done right now, except that the deployed (read : expanded) WAR is undeployed when you shut down Catalina. A war file exists, and a corresponding directory exists. The war file last mod time is newer than the directory. - ??? You have one of two cases, a completely different web app exists in a directory with the same name as a new war file, or an updated war file for was installed and the directory is for the previously expanded version. What now? And when tomcat is shutdown it should not remove any unpacked war files, this can significantly increase the time it takes tomcat to startup/shutdown. It will only remove files if it did actually deploy the corresponding WAR. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Tomcat 4 unpacking of WAR files behavior
If unpackWARs="false", then nothing is expanded out into webapss, the war file is expanded out as needed into the work dir, correct? The JARs are indeed expanded as a temporary fix for Jasper. There is hope that we can perhaps use a tweaked version of javac which would load classes from a classloader (in which case no expanding is needed). Seems to me that running from a war directly would be a problem for performance anyway. Wouldn't you have to unzip them somewhere? RAM? It probably slows down a little bit the classloading, but the class only has to be loaded once anyway, so it's not a big deal. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: re-use of tag objects via Tag.release method
Ok, I'll bite. Where's the best place to start looking? Code that does the rendering? Wasn't there at one point talk of making the renderer more "pluggable"? -Casey -Original Message- From: Pierre Delisle [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 01, 2001 3:22 PM To: [EMAIL PROTECTED] Subject: Re: re-use of tag objects via Tag.release method Casey Lucas wrote: Looking at the rendered jsp - java files in the work directory (and noticing the calls to Tag.release), I realized that Jasper is not reusing tags that it creates. So, my question is: Has there been any conversations about implementing tag reuse in Jasper? To my knowledge, there has been no conversation on the topic. But, it'd be great to start one :-). Besides the obvious performance gains, having agressive tag reuse in tomcat would also be great for taglibs testing purposes. Properly handling 'release()' in a tag can be tricky and bugs will only show up when a tag is run in a container that supports 'tag reuse'. -- Pierre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - This email server is running an evaluation copy of the MailShield anti- spam software. Please contact your email administrator if you have any questions about this message. MailShield product info: www.mailshield.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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:[EMAIL PROTECTED]]
Sent: Thursday, March 01, 2001 2:54 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
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
JkLogLevelerror
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
ServerNamehost1.com
ServerAdmin [EMAIL PROTECTED]
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
ServerNamehost1.com
ServerAdmin [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: re-use of tag objects via Tag.release method
Casey Lucas wrote: Ok, I'll bite. Where's the best place to start looking? Code that does the rendering? Wasn't there at one point talk of making the renderer more "pluggable"? Great! Since you asked, here are some ideas: As a first step, I'd make sure to clearly understand all the spec says about tag reuse. Then, I'd get acquainted with the tomcat generated servlet code of various JSP pages that use tags. That will tell how access to tags is currently architected in jasper. (I think it will be easier than looking at the tags generator code itself, but if you're insterested in seeing that code, check the Tag* files in org.apache.jasper.compiler.) Finally, with all that knowledge, I'd come come up with ideas, rough designs, etc... on how reuse could be implemented in Jasper. I don't think any deep knowledge of Jasper code is required to get up to here. Use the list for help/feedback. Before long, you'll be the expert! -- Pierre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Server crash Class Loading
Hi All, I have a tomcat 3.2.1 release version running. Recently, I have included a jar in the lib directory (taking from the development root). This does not have any explicit package and do some computation on graphs. Basically, I was planning to use the classes in some helper Class file I am writing for my development. However, when starting the server, it gave me a message "cannot load servlet name :jsp" and subsequently it failed to execute any of the jsp. Any idea what is going on ? I created a context into ../../web. Now I have some jsp files in ../../web/dummy. When I try to instantiate a class in any jsp files in dummy directory it attrempts to find dummy.classname instead of classname itself. Any idea, how can I get rid of this ? Thanks, Koushik. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
isapi_redirect.dll : Compiled under which version of Windows???
Dear Tomcat Developers: Which version of NT was the version of isapi_redirect.dll compiled under? I am referring to the version that appears under the 3.2.1 binary downloads section of the Tomcat website. The download version seems to install fine under Windows2000/IIS but does not install under Windows NT 4.0 Workstation running PWS. (I can't get the dll into a Green Up Arrow condition on the ISAPI filters section of the IIS management console and I don't see anyplace where IIS tells you what the problem is.) I am wondering if this version is not compatible with NT4 workstation/PWS and that I should try to compile the dll from source. But I'd rather not go through the effort to compile everything if this does not even have a chance of solving my problem. Any guidance from the developers who actually have built the code would be appreciated. Thanks, Keith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Bug report: welcome-file broken with non static pages (e.g. servlet paths)
"Berche, Guillaume" wrote: Hello, Despites the Servlet specs 2.2 are pretty vague about this problem, I guess that the welcome-file entry should be able to specify servlet names. However, tomcat 3.2.1 fails to do this. Looking a bit into it, I diagnosed it as follows: FYI, this is going to be one of the many clarifications in 2.3 -- containers will be required to support servlet URIs as "welcome files". Craig McCLanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[PATCH] Exporting Servlet mappings for mod_jk
It was getting to be too much work to keep my web.xml files synced with
httpd.conf, so I got ApacheConfig.java to do it for me. The following is
for Tomcat 3.3M1:
*** ApacheConfig.java.orig Thu Mar 1 16:40:46 2001
--- ApacheConfig.java Thu Mar 1 16:38:26 2001
***
*** 328,337
mod_jk.println("#");
mod_jk.println("# The following line mounts all JSP files and
the/servlet/ uri to tomcat");
mod_jk.println("#");
mod_jk.println("JkMount " + path +"/servlet/* " +
JkMount[jkConnector]);
mod_jk.println("JkMount " + path +"/*.jsp " +
JkMount[jkConnector]);
-
// Deny serving any files from WEB-INF
mod_jk.println();
mod_jk.println("#");
--- 328,345
mod_jk.println("#");
mod_jk.println("# The following line mounts all JSP files and
the/servlet/ uri to tomcat");
mod_jk.println("#");
+ /*
mod_jk.println("JkMount " + path +"/servlet/* " +
JkMount[jkConnector]);
mod_jk.println("JkMount " + path +"/*.jsp " +
JkMount[jkConnector]);
+ */
+Enumeration ctxMaps = context.getContainerLocations();
+while(ctxMaps.hasMoreElements()) {
+ String cxpath = (String)ctxMaps.nextElement();
+ if(!cxpath.startsWith("/"))
+ cxpath = "/"+cxpath;
+ mod_jk.println("JkMount " + path + cxpath +" "+
JkMount[jkConnector]);
+}
// Deny serving any files from WEB-INF
mod_jk.println();
mod_jk.println("#");
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: isapi_redirect.dll : Compiled under which version of Windows???
Questions about configuring Tomcat really belong on the tomcat-users mailing list. Also, search the list archives because this questions has been asked an answered more times that I can remember. It works fine on WinNT 4.0. I've been using it for quite some time. The normal reasons for the isapi_redirect to fail are 1) Corrupted download. 2) Misconfigured registry entries for the worker_file or worker_mount_file. In TC3.2.2 log messages will appear in the redirector's log file if these files can't be found (assuming that the log_file registry entry exists and is correct. 3) Creating the "Filter DLLs" registry entry when your using IIS. This entry is only required when your using the Personal Web Server. (The how-to document in TC3.2.2 includes an additional comment about this). -Original Message- From: Hawkins, Keith (Keith) [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 01, 2001 12:28 PM To: '[EMAIL PROTECTED]' Subject: isapi_redirect.dll : Compiled under which version of Windows??? Dear Tomcat Developers: Which version of NT was the version of isapi_redirect.dll compiled under? I am referring to the version that appears under the 3.2.1 binary downloads section of the Tomcat website. The download version seems to install fine under Windows2000/IIS but does not install under Windows NT 4.0 Workstation running PWS. (I can't get the dll into a Green Up Arrow condition on the ISAPI filters section of the IIS management console and I don't see anyplace where IIS tells you what the problem is.) I am wondering if this version is not compatible with NT4 workstation/PWS and that I should try to compile the dll from source. But I'd rather not go through the effort to compile everything if this does not even have a chance of solving my problem. Any guidance from the developers who actually have built the code would be appreciated. Thanks, Keith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/startup Tomcat.java
costin 01/03/01 20:49:36
Modified:src/share/org/apache/tomcat/core Context.java
src/share/org/apache/tomcat/modules/config ApacheConfig.java
IISConfig.java LogSetter.java NSConfig.java
PolicyInterceptor.java
src/share/org/apache/tomcat/modules/generators
ErrorHandler.java
src/share/org/apache/tomcat/modules/server Ajp12.java
Ajp13Interceptor.java Http10.java
Http10Interceptor.java
src/share/org/apache/tomcat/modules/session
SimpleSessionStore.java
src/share/org/apache/tomcat/startup Tomcat.java
Log:
Stop using Logger or the the Log constructor.
Revision ChangesPath
1.141 +2 -1 jakarta-tomcat/src/share/org/apache/tomcat/core/Context.java
Index: Context.java
===
RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Context.java,v
retrieving revision 1.140
retrieving revision 1.141
diff -u -r1.140 -r1.141
--- Context.java 2001/02/27 16:54:01 1.140
+++ Context.java 2001/03/02 04:49:06 1.141
@@ -583,7 +583,8 @@
if( "/".equals(path) )
path="";
this.path = path;
- loghelper.setLogPrefix("Ctx("+ getId() +") ");
+ loghelper=Log.getLog("org/apache/tomcat/core",
+ "Ctx("+ getId() +") ");
}
/**
1.6 +1 -1
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/ApacheConfig.java
Index: ApacheConfig.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/ApacheConfig.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- ApacheConfig.java 2001/02/20 03:16:51 1.5
+++ ApacheConfig.java 2001/03/02 04:49:11 1.6
@@ -119,7 +119,7 @@
-Log loghelper = new Log("tc_log", this);
+Log loghelper = Log.getLog("tc_log", this);
public void execute(ContextManager cm) throws TomcatException {
try {
1.3 +1 -1
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/IISConfig.java
Index: IISConfig.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/IISConfig.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- IISConfig.java2001/02/13 04:30:16 1.2
+++ IISConfig.java2001/03/02 04:49:12 1.3
@@ -78,7 +78,7 @@
public static final String JK_LOG_LOCATION = "/logs/iis_redirect.log";
public static final String IIS_REG_FILE = "/conf/jk/iis_redirect.reg";
-Log loghelper = new Log("tc_log", "IISConfig");
+Log loghelper = Log.getLog("tc_log", "IISConfig");
public IISConfig()
{
1.9 +22 -3
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/LogSetter.java
Index: LogSetter.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/LogSetter.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- LogSetter.java2001/02/20 03:16:51 1.8
+++ LogSetter.java2001/03/02 04:49:13 1.9
@@ -61,6 +61,7 @@
import org.apache.tomcat.core.*;
import org.apache.tomcat.util.log.*;
+import org.apache.tomcat.util.qlog.*;
import org.apache.tomcat.util.io.FileUtil;
import java.io.*;
import java.net.*;
@@ -192,6 +193,15 @@
{
if( module!=this ) return;
+ LogManager logManager=(LogManager)cm.getNote("tc.LogManager");
+
+ // Log will redirect all Log.getLog to us
+ if( logManager==null ) {
+ logManager=new TomcatLogManager();
+ cm.setNote("tc.LogManager", logManager);
+ Log.setLogManager( logManager );
+ }
+
if( name==null ) {
if( servletLogger )
name="org/apache/tomcat/facade";
@@ -220,7 +230,6 @@
// construct a queue logger
QueueLogger ql=new QueueLogger();
- ql.setName(name);
if( ! timestamps )
ql.setTimestamp( "false" );
if( tsFormat!=null )
@@ -233,7 +242,7 @@
ql.open();
- Logger.putLogger( ql );
+ logManager.addChannel( name, ql );
if( "org/apache/tomcat/core".equals( name ) ) {
// this will be the Log interface to the log we just created
@@ -252,8 +261,18 @@
}
+/** Adapter and registry for QueueLoggers
+ */
+static class TomcatLogManager extends LogManager {
-// XXX Flush the buffers on shutdown
cvs commit: jakarta-tomcat/src/admin/WEB-INF/classes/tadm TomcatAdmin.java
costin 01/03/01 21:26:03
Modified:src/admin/WEB-INF/classes/tadm TomcatAdmin.java
Log:
A last ( ? ) change.
Revision ChangesPath
1.11 +5 -2 jakarta-tomcat/src/admin/WEB-INF/classes/tadm/TomcatAdmin.java
Index: TomcatAdmin.java
===
RCS file: /home/cvs/jakarta-tomcat/src/admin/WEB-INF/classes/tadm/TomcatAdmin.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- TomcatAdmin.java 2001/02/09 04:03:22 1.10
+++ TomcatAdmin.java 2001/03/02 05:26:01 1.11
@@ -9,6 +9,7 @@
import javax.servlet.jsp.tagext.*;
import org.apache.tomcat.core.*;
import org.apache.tomcat.util.log.*;
+import org.apache.tomcat.util.qlog.*;
/**
* A context administration class. Contexts can be
@@ -135,10 +136,12 @@
try {
QueueLogger logger=new QueueLogger();
System.out.println("Setting logger " + dest );
- logger.setName( "temp.log");
logger.setPath( dest );
logger.open();
- Logger.putLogger( logger );
+ LogManager logManager=(LogManager)ctx.getContextManager().
+ getNote("tc.LogManager");
+
+ logManager.addChannel("temp.log", logger );
Log log=Log.getLog( "temp.log", ctx );
ctx.setLog( log );
ctx.setServletLog( log );
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/jasper/runtime package.html
costin 01/03/01 22:54:13 Added: src/share/org/apache/jasper/runtime package.html Log: Added documentation about the run-time dependencies of the jasper-generated servlets. In order to deploy pre-compiled servlets or to provide a minimal env., you need to include all the files listed, and follow the initialization procedure. Revision ChangesPath 1.1 jakarta-tomcat/src/share/org/apache/jasper/runtime/package.html Index: package.html === This package needs to be visible and is used at runtime by the generated servlets. h2Initialization/h2 Code using jasper-generated servlets must init the runtime by calling: JspFactory.setDefaultFactory(new JspFactoryImpl()); h2Dependencies/h2 A servlet generated by jasper will depend at runtime on the following: org.apache.jasper.runtime.* ( act as a facade ) org.apache.jasper.Constants org.apache.jasper.JasperException org.apache.jasper.Options Plus general purpose utils - independent of tomcat and self contained: org.apache.tomcat.util.collections.* org.apache.tomcat.util.log.* Things we might want to remove: util.compat ( only to get platform lineSeparator ) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/jasper/runtime JspFactoryImpl.java JspWriterImpl.java
costin 01/03/01 22:56:20
Modified:src/share/org/apache/jasper/runtime JspFactoryImpl.java
JspWriterImpl.java
Log:
Removed dependency on tomcat.util.compat - the runtime can be set up
without it.
The trick ( not a trick actually ) is to do the actions needed
special priviledge when the system is initialized ( i.e. JspFactoryImpl
is created and set into JspFactory ).
No other priviledged are required so far in the runtime.
Revision ChangesPath
1.10 +15 -3
jakarta-tomcat/src/share/org/apache/jasper/runtime/JspFactoryImpl.java
Index: JspFactoryImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/runtime/JspFactoryImpl.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- JspFactoryImpl.java 2001/03/02 04:51:40 1.9
+++ JspFactoryImpl.java 2001/03/02 06:56:19 1.10
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/runtime/JspFactoryImpl.java,v 1.9
2001/03/02 04:51:40 costin Exp $
- * $Revision: 1.9 $
- * $Date: 2001/03/02 04:51:40 $
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/runtime/JspFactoryImpl.java,v
1.10 2001/03/02 06:56:19 costin Exp $
+ * $Revision: 1.10 $
+ * $Date: 2001/03/02 06:56:19 $
*
*
*
@@ -80,6 +80,18 @@
public class JspFactoryImpl extends JspFactory {
private SimplePool pool=new SimplePool( 100 );
private static final boolean usePool=true;
+static String lineSeparator;
+static {
+ try {
+ lineSeparator = System.getProperty("line.separator");
+ } catch( Exception ex ) {
+ lineSeparator="\r\n";
+ }
+ // This whole things allows us to set the writer line
+ // separator when we init jasper, i.e. in priv. mode -
+ // without it we would need a priviledged action.
+ JspWriterImpl.lineSeparator=lineSeparator;
+}
Log loghelper = Log.getLog("JASPER_LOG", "JspFactoryImpl");
1.7 +5 -12
jakarta-tomcat/src/share/org/apache/jasper/runtime/JspWriterImpl.java
Index: JspWriterImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/runtime/JspWriterImpl.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- JspWriterImpl.java2001/03/02 04:51:41 1.6
+++ JspWriterImpl.java2001/03/02 06:56:19 1.7
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/runtime/JspWriterImpl.java,v 1.6
2001/03/02 04:51:41 costin Exp $
- * $Revision: 1.6 $
- * $Date: 2001/03/02 04:51:41 $
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/runtime/JspWriterImpl.java,v 1.7
2001/03/02 06:56:19 costin Exp $
+ * $Revision: 1.7 $
+ * $Date: 2001/03/02 06:56:19 $
*
*
*
@@ -72,7 +72,6 @@
import javax.servlet.jsp.JspWriter;
import org.apache.jasper.Constants;
-import org.apache.tomcat.util.compat.*;
/**
* Write text to a character-output stream, buffering characters so as
@@ -382,18 +381,12 @@
write(s, 0, s.length());
}
-
static String lineSeparator;
static {
- Jdk11Compat jdk11Compat=Jdk11Compat.getJdkCompat();
try {
- lineSeparator = (String)jdk11Compat.doPrivileged( new Action() {
- public Object run() throws Exception {
- return System.getProperty("line.separator");
- }
- });
+ lineSeparator = System.getProperty("line.separator");
} catch( Exception ex ) {
- lineSeparator="\r\r";
+ lineSeparator="\r\n";
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
