[BUG T322] Bug in getServletContext().getResource() for relative URLs
Bugzilla is down so I am forced to send this to the list: Relative URLs from a servlet resource do not work (Tomcat 3.2.2). I have the following code in a Servlet: URL propURL = getServletContext().getResource( /WEB-INF/connection.properties ) URL configURL = new URL( url, config.xml ); The servlet throws a FileNotFoundException on configURL.getInputStream() some diagnostic info follows: Could not load configuration file: file:persist.config.xml propURL: file:F:\tomcat\tomcat-dev\webapps\ore\WEB-INF\connection.properties configURL: persist.config.xml Apache Tomcat/4.0-b5 works perfectly, but its using jndi. Also, if I do the following: URL configURL = new URL( url, config.xml ); configURL = new URL( configURL.toString() ); it works! java version 1.3.1 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24) Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode) Full Exception is java.io.FileNotFoundException: persist.config.xml (The system cannot find the file specified) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:64) at sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:6 9) at sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection .java:133) at java.net.URL.openStream(URL.java:798) at ssabsa.control.Controller.init(Controller.java:52) at ssabsa.control.Controller.getInstance(Controller.java:74) at ssabsa.ore.WoreServlet.init(WoreServlet.java:47) at javax.servlet.GenericServlet.init(GenericServlet.java:258) at org.apache.tomcat.core.ServletWrapper.doInit(ServletWrapper.java:317) at org.apache.tomcat.core.Handler.init(Handler.java:215) at org.apache.tomcat.core.ServletWrapper.init(ServletWrapper.java:296) at org.apache.tomcat.context.LoadOnStartupInterceptor.contextInit(LoadOnStartup Interceptor.java:130) at org.apache.tomcat.core.ContextManager.initContext(ContextManager.java:491) at org.apache.tomcat.core.ContextManager.init(ContextManager.java:453) at org.apache.tomcat.startup.Tomcat.execute(Tomcat.java:195) at org.apache.tomcat.startup.Tomcat.main(Tomcat.java:235)
RE: [BUG T322] Bug in getServletContext().getResource() for relative URLs
Small correction: Also, if I do the following: URL configURL = new URL( url, config.xml ); configURL = new URL( configURL.toString() ); I meant URL configURL = new URL( new URL( url.toString() ), config.xml ); which works.
Re: [BUG T322] Bug in getServletContext().getResource() for relative URLs
Yes, Have a look at this Bug Id: 4447088 On the Bug Parade at the JDC. I submitted this after trying to use classloader.getResource() in a servlet. URL doesn't construct a proper URL string when the constructor you show is used. Works fine on unix/linux, but windows absolute paths can start with a letter, not a slash. I'd like to see tomcat use a different constructor so I can rip out some special code that checks the classloader first! David Stevenson, Chris (SSABSA) wrote: Bugzilla is down so I am forced to send this to the list: Relative URLs from a servlet resource do not work (Tomcat 3.2.2). I have the following code in a Servlet: URL propURL = getServletContext().getResource( /WEB-INF/connection.properties ) URL configURL = new URL( url, config.xml ); The servlet throws a FileNotFoundException on configURL.getInputStream() some diagnostic info follows: Could not load configuration file: file:persist.config.xml propURL: file:F:\tomcat\tomcat-dev\webapps\ore\WEB-INF\connection.properties configURL: persist.config.xml Apache Tomcat/4.0-b5 works perfectly, but its using jndi. Also, if I do the following: URL configURL = new URL( url, config.xml ); configURL = new URL( configURL.toString() ); it works! java version 1.3.1 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24) Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode) Full Exception is java.io.FileNotFoundException: persist.config.xml (The system cannot find the file specified) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:64) at sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:6 9) at sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection .java:133) at java.net.URL.openStream(URL.java:798) at ssabsa.control.Controller.init(Controller.java:52) at ssabsa.control.Controller.getInstance(Controller.java:74) at ssabsa.ore.WoreServlet.init(WoreServlet.java:47) at javax.servlet.GenericServlet.init(GenericServlet.java:258) at org.apache.tomcat.core.ServletWrapper.doInit(ServletWrapper.java:317) at org.apache.tomcat.core.Handler.init(Handler.java:215) at org.apache.tomcat.core.ServletWrapper.init(ServletWrapper.java:296) at org.apache.tomcat.context.LoadOnStartupInterceptor.contextInit(LoadOnStartup Interceptor.java:130) at org.apache.tomcat.core.ContextManager.initContext(ContextManager.java:491) at org.apache.tomcat.core.ContextManager.init(ContextManager.java:453) at org.apache.tomcat.startup.Tomcat.execute(Tomcat.java:195) at org.apache.tomcat.startup.Tomcat.main(Tomcat.java:235)
tomcat-4.0 and JSP class reloading
hey, Is anyone fixing that point? Problem is that JSP doesn't reload classes when servlet container in same context does? Tuukka --- --Me olemme keskella jotain. jossa olemme totaalisen ulkopuolisia-- Get 250 color business cards for FREE! http://businesscards.lycos.com/vp/fastpath/
RE: Filter Chains slow first time it is called
All, Many apologies if this isn't the correct list for this message. Please point me in the right direction if I've made a mistake. I've been experiencing problems with latency and filters in Tomcat 4 (both beta 1 and beta 5). A search of the mailing list archives showed up the exchange summarised below, which I believe relates to the same problem that I've been experiencing. I've done some further research, however, and I have reason to believe that the problem may be a little more serious than this exchange implies. I have an example which demonstrates the problem reliably which I would be delighted to make available if someone can tell me how to do so (I assume that attaching a .war file to this message isn't the right way!). Like Kevin, I've been experiencing approximately a 30 second latency when using filters in Tomcat. Unlike Kevin, I'm using URI patterns to set up my filters, rather than filter chains. I experience the problem reliably every time. Also like Kevin, I experience different behaviour when connecting via IE and Netscape. I have reason to believe that the problem is not with IE, however; Netscape just copes with it slightly more gracefully. I have also been using WAP 'phones to connect (my main aim is serving WML pages to WAP 'phones) and they also experience latency problems. When connecting to a filtered JSP with IE, the result isn't displayed for approximately 30 seconds. Something then obviously times out and the page is displayed correctly. The problem is definitely after the filter has been called - I've added simple logging to my example filter and its doFilter function completes almost immediately. When connecting to the same page with Netscape 6, the results display almost immediately. The connection to the server isn't closed, however (the N in the top right continues to animate and the progress bar at the bottom doesn't reach 100%). Unlike IE, the connection doesn't seem to time out after 30 seconds. I've not had the patience to wait long enough to see when it does time out (its certainly in excess of a minute). When using a WAP 'phone, the 'phone times out with an error. The problem only occurs if I use my filter on a JSP file. It does not occur when the filter is used on a plain HTML file. If there are any more details that I can provide, please let me know and I'll do my best. Thanks, pbutcher-msgCount++ -- Team Leader, Argogroup plc http://www.argogroup.com/ From: Kevin Jones [EMAIL PROTECTED] Date: Wed, 31 Jan 2001 20:27:34 - To: [EMAIL PROTECTED] Subject: RE: Filter Chains slow first time it is called I've just taken a closer look at this, it's a browser problem. IE 5.5 has really trouble with content types. Even though I'm setting the type to text/html (in a filter) but at some point I've used IE 5.5 to get the data without the filter. The servlet returns text/xml. It seems that IE5.5 is struggling to reconcile this (that's all I can think of). Netscape has no problems (for once :-) ), Kevin Jones DevelopMentor www.develop.com -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: 31 January 2001 19:21 To: [EMAIL PROTECTED] Subject: Re: Filter Chains slow first time it is called Kevin Jones wrote: Subject says it all really. The first time a filter chain is executed for a servlet, it takes about 30 seconds for the response to get back to the client. It would be surprising if this is related to initializing the filter chain -- after all, the chain is constructed for every single request (not just the first one). Are you sure there isn't anything application specific that takes a long time to initialize? This doesn't happen everytime but enough to be repeatable. I'm using Beta 1. I've set the app to be reloadable (with a reload time of 3) and I'm logging to the console if that helps, Logs and a test case (even if it doesn't repeat evey single time) would be quite useful in investigating this.
[ANNOUNCEMENT] Domino / Tomcat connecter available
I've written a Tomcat for Lotus Domino in the spirit of the IIS and Netscape connectors making it possible to use Tomcat as Domino's servlet container. It can be found at http://free.tagish.net/domino-tomcat/index.jsp It's quite small and wouldn't look at all out of place in the Tomcat release ;-) -- Andy Armstrong, Tagish
compiling mod_jk in IRIX, bug+fix
Sorry if this is the wrong list and/or this is wellknown. If you want to compile mod_jk from tomcat.3.2.2 in IRIX 6.5.x, then some smallish stuff needs to be changed: in dir jakarta-tomcat-3.2.2-src/src/native/jk edit the following files in the following way: jk_sockbuf.c. replace //comment with /* comment */ jk_util.c replace //comment with /* comment */ jjk_worker_list.h add a newline at the eof. then compile and be happy! Regards, Christer Enkvist
Re(2): compiling mod_jk in IRIX, bug+fix [PATCH]
--- jk_sockbuf.c.orig Wed May 30 12:42:28 2001
+++ jk_sockbuf.cWed May 30 12:43:10 2001
@@ -224,7 +224,7 @@
sb-buf + sb-end,
SOCKBUF_SIZE - sb-end, 0);
- // 0 is EOF/SHUTDOWN, -1 is SOCK_ERROR
+ /* 0 is EOF/SHUTDOWN, -1 is SOCK_ERROR */
if (ret = 0) {
return ret;
}
--- jk_util.c.orig Wed May 30 12:44:38 2001
+++ jk_util.c Wed May 30 15:20:45 2001
@@ -214,7 +214,7 @@
#ifdef WIN32
used = _snprintf(buf, HUGE_BUFFER_SIZE, [%s (%d)]: , f, line);
-#elif defined(NETWARE) // until we get a snprintf function
+#elif defined(NETWARE) /* until we get a snprintf function */
buf = (char *) malloc(HUGE_BUFFER_SIZE);
if (NULL == buf)
return -1;
@@ -230,7 +230,7 @@
va_start(args, fmt);
#ifdef WIN32
rc = _vsnprintf(buf + used, HUGE_BUFFER_SIZE - used, fmt, args);
-#elif defined(NETWARE) // until we get a vsnprintf function
+#elif defined(NETWARE) /* until we get a vsnprintf function */
rc = vsprintf(buf + used, fmt, args);
#else
rc = vsnprintf(buf + used, HUGE_BUFFER_SIZE - used, fmt, args);
--- jk_worker_list.h.orig Wed May 30 12:46:48 2001
+++ jk_worker_list.hWed May 30 12:48:19 2001
@@ -123,4 +123,5 @@
{ NULL, NULL}
};
#endif /* _JK_WORKER_LIST_H */
-#endif /* _PLACE_WORKER_LIST_HERE */
\ No newline at end of file
+#endif /* _PLACE_WORKER_LIST_HERE */
+
RE: Problem+Fix concerning static error pages in Tomcat 3.2.2
Bloody hell. This bug was fixed a couple months ago and then got whacked by a late commit to StaticInterceptor.java. I take partial responsibility because I reviewed that commit and missed the problem. I'll try to get this taken care of this evening. -Original Message- From: Peter S. Heijnen [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 30, 2001 12:50 AM To: [EMAIL PROTECTED] Subject: Re: Problem+Fix concerning static error pages in Tomcat 3.2.2 I use virtual hosts, but don't think that is the cause, although I have not traced this down (I will check that aswell). As I think of it, the webapp could simply be empty one with a web.xml like: ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN http://java.sun.com/j2ee/dtds/web-app_2_2.dtd; web-app error-page error-code404/error-code location/errors/404.html/location /error-page /web-app Now, when I request any file through Tomcat, it will fail (error 500: Stack overflow). When a JSP is specified for location, it works fine. Tomcat outputs a correct message from the CM about the requested error page, but FileHandler outputs the originally requested path as requested file. I will set up an independent Tomcat installation and try this again without virtual hosts. If I have the time today, I will wrap up a webapp and post the .war file. - Original Message - From: Marc Saegesser [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, May 29, 2001 8:54 PM Subject: RE: Problem+Fix concerning static error pages in Tomcat 3.2.2 Could you please supply a sample webapp that demonstrates this? Static error pages seem to work OK for me. -Original Message- From: Peer Heijnen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 29, 2001 5:52 AM To: tomcat-dev Subject: Problem+Fix concerning static error pages in Tomcat 3.2.2 I'm using Tomcat 3.2.2 (relase) and have configured static .html files as error pages. We used JSP pages before, and everything was fine... However since we're using static files, Tomcat will enter an infinite loop and eventually crash with a stack overflow (with a good change of leaving Tomcat in a defunct state). We traced down this problem and have found a way to fix it, but I'm not sure if this is correct. All this is related to the ContextManager class: 1) Both handleStatus and handleError will call 'getHandlerForPath' when an error page was configured. 2) getHandlerForPath returns a the Handler for the error page. (since we're using static files, this will be a FileHandler). So far, so good. 3) Eventually handleStatus and handleError will do a 'errorServlet.service( req, res )' to service the error. This is were things go wrong. The problem is, that 'req' passed to the 'errorServlet.service( req, res )' call is the original request, while getHandlerForPath creates a new request internally with the error's request URI. Since the handler (FileHandler) is called with the original request URI, it will try to service a file matching that request, not the static file we configured. This, in turn, will cause and error and, in our case, an infinite loop. This can lead to very strange situations. For example, if an .jsp page generates an error and the error refers to an (existing) static file, it will actually end up showing the .jsp source file contents! The quick and dirty fix we use here is to simply add 'req.setRequestURI( ctx.getPath() + errorPath);' after the 'getHandlerForPath' calls in both handleError and handleStatus methods. I'm not really sure if we are allowed to modify the request in such a way, but error attributes are also set in this request and it seems to work fine for us. But this raises another question: why construct a completely new request and response in getHandlerForPath, and then throw it away? Cheers, Peer Heijnen
cvs commit: jakarta-tomcat-connectors/jk build.xml
seguin 01/05/30 08:26:03
Modified:jk build.xml
Log:
exclude test subpackage on jar, javadoc tasks.
Revision ChangesPath
1.7 +2 -10 jakarta-tomcat-connectors/jk/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/build.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- build.xml 2001/05/29 23:05:53 1.6
+++ build.xml 2001/05/30 15:26:01 1.7
@@ -54,22 +54,14 @@
jar jarfile=${jk.build}/lib/ajp.jar
basedir=${jk.build}/classes
+ excludes=org/apache/ajp/test
/
/target
target name=test if=test.entry depends=build-main
description=Run all unit test cases
-!--
- junit printsummary=yes fork=on haltonfailure=yes
- formatter type=plain usefile=false/
- test name=${test.entry}/
-classpath refid=test.classpath/
- /junit
- --
-
java classname=${test.runner} fork=yes
failonerror=${test.failonerror}
- !--jvmarg value=${java.protocol.handler.pkgs}/--
arg value=${test.entry}/
classpath refid=test.classpath/
/java
@@ -80,7 +72,7 @@
target name=javadoc
delete dir=${jk.build}/javadoc/
mkdir dir=${jk.build}/javadoc/
- javadoc packagenames=org.apache.ajp.*
+ javadoc packagenames=org.apache.ajp,org.apache.ajp.tomcat4
sourcepath=src/java
classpath=${tomcat-util.jar}:${catalina.jar}:${servlet.jar}
destdir=${jk.build}/javadoc
A new servlet without re-start Tomcat...
...is it possible? I know there is an option in server.xml file named 'reloadable = true' that performs something similar, but i'd like to know if there is another way to do this without overloading Tomcat too much. Thanks in advance: __ Jaume Soriano Sivera [EMAIL PROTECTED] Tel: 96504 -ext. 44744 Fax: 965040047 Portal y servicios multimedia - Nuevas tecnologias W a n a d o o E s p a n a - http://www.wanadoo.es __
configure for jakarta-tomcat-connectors
Hi, I have added support for static linking of mod_jk (for Apache-1.3.x). I have used automake to reach it, it has side effects I would like to comment: - apxs cannot be used build mod_jk.so. - It needs autoconf/automake for prepare the *.in file. (Only for develloppers). - It needs libtools. I am quite unhappy about not beeing able to use apxs to build mod_jk.so, but I have not find a clean solution. Has someone an idea? Cheers Jean-frederic
Re: URI Rewritng using Apache/mod_ssl..the old story
As far as I understand the fix does not mean, that you get rid of jsse.jar
and jnet.jar.
Core Java does not include an https protocol handler, but such a thing is
implicitely used in http-URL-creation inside tomcat (although that could be
done easier). Java is open to add new protocol handlers. The way it works
is exactly by using own or third party protocol handlers and by defining
java.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol
(or to something else which knows about your own or third party protocol
handlers).
At that point your java application will be https enabled. The problem does
not occur with http, since standard java contains an http protocol handler
and the standard java.protocol.handler.pkgs knows about that one.
Of course as long as you don't really want tomcat itself to talk https
(e.g. the browser talks https to apache and you enable JkExtractSSL On
for mod_jk, so that redirects and forwards go to a correct https-URL) you
could think of supplying tomcat with basic https-URL-understanding not
using the fully featured protocol handlers. On the other side, since one
would like to have the ability to use https directly from tomcat you would
have to prepare to use the protocol handlers any way.
Rainer Jung
At 08:49 30.05.01 , you wrote:
I have just installed TC3.2.2 final, and URI Rewiting won't work over
mod_ssl
and apache.
without ssl it works fine, also.
I have set the TOMCAT_HOME and the JAVA_HOME... but it won't work
Or isn't it fixed on TC3.2.2 ??
When I install the two external classes from jdk jsse.jar and jnet.jar
in tomcat/lib and start it with an environment variable like bleow (old
bug #578 walkaround) it will work.
The only thing that's gone is that I don't have to patch the
HttpServletResponseFacade.java file out of
tomcat/lib/webserver.jar...
I've indeed tested this behavior with the standard class to test the
sessiontracking whoch comes with tomcat.
Greetings and thanks for inconvenience,
Michael
plz wrote back
Marc Saegesser wrote:
A change very similar to what you propose for
HttpServletResponseFacade.java
was already made for Tomcat 3.2.2b4. There are two conditions that I
know
of where URL rewritting won't work. If you using AJP12 and an SSL
port
other than 443 then Tomcat won't be told that the connection is secure
and
will think that that the URL scheme is HTTP not HTTPS.
HttpServletResponseFacade checks that the scheme of the URL to be
encoded
and the scheme of the current request are the same. To encode an
HTTPS url
you must be on an HTTPS request. [Note: I'm sure I really understand
this
requirement, but its been this way for a long time.]
So the two ways I know of for URL rewriting to fail are if you using
AJP12
and SSL on something other than 443 or if your encoding an HTTPS URL
during
an HTTP request. Are either of these true for your case?
To help diagnose this, could you access the SnoopServlet that comes
with
Tomcat via your SSL connection and post the results. This page will
indicate whether Tomcat thinks the request is secure or not, and if it
thinks the URL scheme is HTTPS.
Thanks, we'll get this worked out.
-Original Message-
From: Wolle [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 04, 2001 5:19 AM
To: [EMAIL PROTECTED]; GOMEZ Henri
Subject: Re: TC 3.2.2b4 URI Rewriting with mod_ssl
Hello,
sorry I just wake up ;-)
Wolle wrote:
GOMEZ Henri wrote:
That is a known Bug ,see
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=578
Marc has said, that he has fixed in the current release
TC3.2.2b4, but it
won't work.
What should I describe now ? The workaround was
Fixed by costin in TC 3.3 since 01/04/22 11:56:03
so I have all these things in TC3.2.2b4, fill it be insert in
TC3.2.2 final ?
not fill - new sentence
so I have to do all these things in TC3.2.2b4, will it be
completly insert in
TC3.2.2 final ?
1. install the jnet.jar and jsse.jar in the ROMCAT/lib dir.
2.set the TOMCAT_OPTS
=-Djava.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol
3. Modify the HttpServletResponseFacade.java:
retrieving revision 1.6.2.3
diff -u -r1.6.2.3 HttpServletResponseFacade.java
---
src/share/org/apache/tomcat/facade/HttpServletResponseFacade.java
2001/03/06 17:38:13 1.6.2.3
+++
src/share/org/apache/tomcat/facade/HttpServletResponseFacade.java
2001/03/20 13:29:41
@@ -353,10 +353,14 @@
return (false);
if
(!request.getServerName().equalsIgnoreCase(url.getHost()))
return (false);
-// Set the URL port to HTTP default if not available
before
comparing
+// Set the URL port to protocol default if not
available before
comparing
int urlPort = url.getPort();
if (urlPort == -1) {
-
Re: A new servlet without re-start Tomcat...
On Wed, 30 May 2001 [EMAIL PROTECTED] wrote: ...is it possible? I know there is an option in server.xml file named 'reloadable = true' that performs something similar, but i'd like to know if there is another way to do this without overloading Tomcat too much. If you are using the invoker servlet (/servlet/*) to call your servlets, you can add new classes and essentially add them dynamically. However, if you need to change anything in web.xml, you'll have to cause the entire web app to be reloaded (either by setting reloadable=true and changing a relevant class, or by using the admin webapp under Tomcat 3.x or the manager webapp under Tomcat 4.x). Thanks in advance: __ Jaume Soriano Sivera [EMAIL PROTECTED] Tel: 96504 -ext. 44744 Fax: 965040047 Portal y servicios multimedia - Nuevas tecnologias W a n a d o o E s p a n a - http://www.wanadoo.es __ Craig McClanahan
Re: tomcat-4.0 and JSP class reloading
On Wed, 30 May 2001, Tuukk4 |[:)-| p4s4n3n wrote: hey, Is anyone fixing that point? Problem is that JSP doesn't reload classes when servlet container in same context does? Can you provide a small example that illustrates this? Tuukka Craig McClanahan
RE: Filter Chains slow first time it is called
Hello Paul, This definitely sounds like something wrong with Tomcat 4 -- most likely a combination of things related to the browser (which can affect which HTTP version is in use), your filters, and the ultimate servlet or JSP page being called. To help narrow things down a bit: * Do you have a small test case we can use to investigate this? If so, you can send it either to TOMCAT-DEV or to me in private mail. * Are your clients using HTTP/1.0 or HTTP/1.1? * Does your filter create a wrapper on the servlet response, or is it just passing things through? I suspect that somewhere along the line the output stream isn't getting flushed or closed in a timely manner -- the above information will be helpful to be able to identify where. Craig On Wed, 30 May 2001, Paul Butcher wrote: All, Many apologies if this isn't the correct list for this message. Please point me in the right direction if I've made a mistake. I've been experiencing problems with latency and filters in Tomcat 4 (both beta 1 and beta 5). A search of the mailing list archives showed up the exchange summarised below, which I believe relates to the same problem that I've been experiencing. I've done some further research, however, and I have reason to believe that the problem may be a little more serious than this exchange implies. I have an example which demonstrates the problem reliably which I would be delighted to make available if someone can tell me how to do so (I assume that attaching a .war file to this message isn't the right way!). Like Kevin, I've been experiencing approximately a 30 second latency when using filters in Tomcat. Unlike Kevin, I'm using URI patterns to set up my filters, rather than filter chains. I experience the problem reliably every time. Also like Kevin, I experience different behaviour when connecting via IE and Netscape. I have reason to believe that the problem is not with IE, however; Netscape just copes with it slightly more gracefully. I have also been using WAP 'phones to connect (my main aim is serving WML pages to WAP 'phones) and they also experience latency problems. When connecting to a filtered JSP with IE, the result isn't displayed for approximately 30 seconds. Something then obviously times out and the page is displayed correctly. The problem is definitely after the filter has been called - I've added simple logging to my example filter and its doFilter function completes almost immediately. When connecting to the same page with Netscape 6, the results display almost immediately. The connection to the server isn't closed, however (the N in the top right continues to animate and the progress bar at the bottom doesn't reach 100%). Unlike IE, the connection doesn't seem to time out after 30 seconds. I've not had the patience to wait long enough to see when it does time out (its certainly in excess of a minute). When using a WAP 'phone, the 'phone times out with an error. The problem only occurs if I use my filter on a JSP file. It does not occur when the filter is used on a plain HTML file. If there are any more details that I can provide, please let me know and I'll do my best. Thanks, pbutcher-msgCount++ -- Team Leader, Argogroup plc http://www.argogroup.com/ From: Kevin Jones [EMAIL PROTECTED] Date: Wed, 31 Jan 2001 20:27:34 - To: [EMAIL PROTECTED] Subject: RE: Filter Chains slow first time it is called I've just taken a closer look at this, it's a browser problem. IE 5.5 has really trouble with content types. Even though I'm setting the type to text/html (in a filter) but at some point I've used IE 5.5 to get the data without the filter. The servlet returns text/xml. It seems that IE5.5 is struggling to reconcile this (that's all I can think of). Netscape has no problems (for once :-) ), Kevin Jones DevelopMentor www.develop.com -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: 31 January 2001 19:21 To: [EMAIL PROTECTED] Subject: Re: Filter Chains slow first time it is called Kevin Jones wrote: Subject says it all really. The first time a filter chain is executed for a servlet, it takes about 30 seconds for the response to get back to the client. It would be surprising if this is related to initializing the filter chain -- after all, the chain is constructed for every single request (not just the first one). Are you sure there isn't anything application specific that takes a long time to initialize? This doesn't happen everytime but enough to be repeatable. I'm using Beta 1. I've set the app to be reloadable (with a reload time of 3) and I'm logging to the console if that helps, Logs and a test case (even if it doesn't repeat evey single time) would be quite useful in investigating this.
cvs commit: jakarta-tomcat-4.0/tester/web/WEB-INF web.xml
craigmcc01/05/30 12:42:50
Modified:tester/src/bin tester.xml
tester/web/WEB-INF web.xml
Added: tester/src/tester/org/apache/tester FilterResponse01.java
UpperCaseFilter.java UpperCaseOutputStream.java
UpperCaseResponse.java UpperCaseWriter.java
tester/web FilterResponse02.jsp FilterResponse03.txt
WrappedFilterResponse02.jsp
WrappedFilterResponse03.txt
Log:
Add some unit tests for a filter that wraps the response (and converts all
characters to upper case). Wrapped output is tested from a servlet, a JSP
page, and a static file -- all accessed directly or with the second
wrapper filter used on most unit tests.
This all works with the standard test client (HTTP/1.0 only), so it
doesn't test all the scenarios currently being reported on TOMCAT-DEV.
I'm going to explore those next.
Revision ChangesPath
1.47 +47 -1 jakarta-tomcat-4.0/tester/src/bin/tester.xml
Index: tester.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/tester/src/bin/tester.xml,v
retrieving revision 1.46
retrieving revision 1.47
diff -u -r1.46 -r1.47
--- tester.xml2001/05/29 17:55:31 1.46
+++ tester.xml2001/05/30 19:42:44 1.47
@@ -15,7 +15,7 @@
taskdef name=tester classname=org.apache.tester.TestClient/
- target name=all
depends=ROOT,Authentication,CaseSensitive,Decoding,ErrorPage,Jndi,RequestDispatcher,Resources,ServletRequest,ServletResponse,HttpSession,XercesTest,SSITest/
+ target name=all
depends=ROOT,Authentication,CaseSensitive,Decoding,ErrorPage,FilterResponse,Jndi,RequestDispatcher,Resources,ServletRequest,ServletResponse,HttpSession,XercesTest,SSITest/
target name=ROOT
@@ -343,6 +343,52 @@
status=200
outContent=ErrorPage10 PASSED/
+
+ /target
+
+
+ target name=FilterResponse
+
+!-- == Apply Upper Case Filter === --
+
+!-- Output from a servlet --
+tester host=${host} port=${port} protocol=${protocol}
+ request=${context.path}/FilterResponse01
+ debug=${debug}
+ status=200
+ outContent=FILTERRESPONSE01 PASSED/
+
+tester host=${host} port=${port} protocol=${protocol}
+ request=${context.path}/WrappedFilterResponse01
+ debug=${debug}
+ status=200
+ outContent=FILTERRESPONSE01 PASSED/
+
+!-- Output from a JSP Page --
+tester host=${host} port=${port} protocol=${protocol}
+ request=${context.path}/FilterResponse02.jsp
+ debug=${debug}
+ status=200
+ outContent=FILTERRESPONSE02 PASSED/
+
+tester host=${host} port=${port} protocol=${protocol}
+ request=${context.path}/WrappedFilterResponse02.jsp
+ debug=${debug}
+ status=200
+ outContent=FILTERRESPONSE02 PASSED/
+
+!-- Output from a static page --
+tester host=${host} port=${port} protocol=${protocol}
+ request=${context.path}/FilterResponse03.txt
+ debug=${debug}
+ status=200
+ outContent=FILTERRESPONSE03 PASSED/
+
+tester host=${host} port=${port} protocol=${protocol}
+ request=${context.path}/WrappedFilterResponse03.txt
+ debug=${debug}
+ status=200
+ outContent=FILTERRESPONSE03 PASSED/
/target
1.1
jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/FilterResponse01.java
Index: FilterResponse01.java
===
/* = *
* *
* The Apache Software License, Version 1.1 *
* *
* Copyright (c) 1999, 2000, 2001 The Apache Software Foundation. *
* All rights reserved.*
* *
* = *
* *
* Redistribution and use in source and binary forms, with or without modi- *
* fication, are permitted provided that the following conditions are met: *
* *
* 1. Redistributions of source code must retain the above copyright notice *
*notice, this list of conditions and the following disclaimer. *
*
RE: Filter Chains slow first time it is called
On Wed, 30 May 2001, Craig R. McClanahan wrote: Hello Paul, This definitely sounds like something wrong with Tomcat 4 -- most likely a combination of things related to the browser (which can affect which HTTP version is in use), your filters, and the ultimate servlet or JSP page being called. To help narrow things down a bit: * Do you have a small test case we can use to investigate this? If so, you can send it either to TOMCAT-DEV or to me in private mail. * Are your clients using HTTP/1.0 or HTTP/1.1? * Does your filter create a wrapper on the servlet response, or is it just passing things through? I suspect that somewhere along the line the output stream isn't getting flushed or closed in a timely manner -- the above information will be helpful to be able to identify where. Craig I just added some more unit tests that do output filtering, and they all work immediately. I now more strongly suspect that this problem is related to some combination of using HTTP/1.1, the particular filters and wrappers being executed, and Tomcat not flushing something somewhere when it is supposed to -- but a real-life example would be tremendously helpful in tracking it down further. Craig On Wed, 30 May 2001, Paul Butcher wrote: All, Many apologies if this isn't the correct list for this message. Please point me in the right direction if I've made a mistake. I've been experiencing problems with latency and filters in Tomcat 4 (both beta 1 and beta 5). A search of the mailing list archives showed up the exchange summarised below, which I believe relates to the same problem that I've been experiencing. I've done some further research, however, and I have reason to believe that the problem may be a little more serious than this exchange implies. I have an example which demonstrates the problem reliably which I would be delighted to make available if someone can tell me how to do so (I assume that attaching a .war file to this message isn't the right way!). Like Kevin, I've been experiencing approximately a 30 second latency when using filters in Tomcat. Unlike Kevin, I'm using URI patterns to set up my filters, rather than filter chains. I experience the problem reliably every time. Also like Kevin, I experience different behaviour when connecting via IE and Netscape. I have reason to believe that the problem is not with IE, however; Netscape just copes with it slightly more gracefully. I have also been using WAP 'phones to connect (my main aim is serving WML pages to WAP 'phones) and they also experience latency problems. When connecting to a filtered JSP with IE, the result isn't displayed for approximately 30 seconds. Something then obviously times out and the page is displayed correctly. The problem is definitely after the filter has been called - I've added simple logging to my example filter and its doFilter function completes almost immediately. When connecting to the same page with Netscape 6, the results display almost immediately. The connection to the server isn't closed, however (the N in the top right continues to animate and the progress bar at the bottom doesn't reach 100%). Unlike IE, the connection doesn't seem to time out after 30 seconds. I've not had the patience to wait long enough to see when it does time out (its certainly in excess of a minute). When using a WAP 'phone, the 'phone times out with an error. The problem only occurs if I use my filter on a JSP file. It does not occur when the filter is used on a plain HTML file. If there are any more details that I can provide, please let me know and I'll do my best. Thanks, pbutcher-msgCount++ -- Team Leader, Argogroup plc http://www.argogroup.com/ From: Kevin Jones [EMAIL PROTECTED] Date: Wed, 31 Jan 2001 20:27:34 - To: [EMAIL PROTECTED] Subject: RE: Filter Chains slow first time it is called I've just taken a closer look at this, it's a browser problem. IE 5.5 has really trouble with content types. Even though I'm setting the type to text/html (in a filter) but at some point I've used IE 5.5 to get the data without the filter. The servlet returns text/xml. It seems that IE5.5 is struggling to reconcile this (that's all I can think of). Netscape has no problems (for once :-) ), Kevin Jones DevelopMentor www.develop.com -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: 31 January 2001 19:21 To: [EMAIL PROTECTED] Subject: Re: Filter Chains slow first time it is called Kevin Jones wrote: Subject says it all really. The first time a filter chain is executed for a servlet, it takes about 30 seconds for the response to get back to the client. It would be surprising if this is related to initializing the filter chain -- after all, the chain is
RE: [BUG T322] Bug in getServletContext().getResource() for relative URLs
According to the spec, the path passed to ServletContext.getResource() must start with a /. -Original Message- From: Stevenson, Chris (SSABSA) [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 30, 2001 1:44 AM To: [EMAIL PROTECTED] Subject: [BUG T322] Bug in getServletContext().getResource() for relative URLs Bugzilla is down so I am forced to send this to the list: Relative URLs from a servlet resource do not work (Tomcat 3.2.2). I have the following code in a Servlet: URL propURL = getServletContext().getResource( /WEB-INF/connection.properties ) URL configURL = new URL( url, config.xml ); The servlet throws a FileNotFoundException on configURL.getInputStream() some diagnostic info follows: Could not load configuration file: file:persist.config.xml propURL: file:F:\tomcat\tomcat-dev\webapps\ore\WEB-INF\connection.properties configURL: persist.config.xml Apache Tomcat/4.0-b5 works perfectly, but its using jndi. Also, if I do the following: URL configURL = new URL( url, config.xml ); configURL = new URL( configURL.toString() ); it works! java version 1.3.1 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24) Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode) Full Exception is java.io.FileNotFoundException: persist.config.xml (The system cannot find the file specified) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:64) at sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnect ion.java:6 9) at sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURL Connection .java:133) at java.net.URL.openStream(URL.java:798) at ssabsa.control.Controller.init(Controller.java:52) at ssabsa.control.Controller.getInstance(Controller.java:74) at ssabsa.ore.WoreServlet.init(WoreServlet.java:47) at javax.servlet.GenericServlet.init(GenericServlet.java:258) at org.apache.tomcat.core.ServletWrapper.doInit(ServletWrapper.java:317) at org.apache.tomcat.core.Handler.init(Handler.java:215) at org.apache.tomcat.core.ServletWrapper.init(ServletWrapper.java:296) at org.apache.tomcat.context.LoadOnStartupInterceptor.contextInit(Loa dOnStartup Interceptor.java:130) at org.apache.tomcat.core.ContextManager.initContext(ContextManager.java:491) at org.apache.tomcat.core.ContextManager.init(ContextManager.java:453) at org.apache.tomcat.startup.Tomcat.execute(Tomcat.java:195) at org.apache.tomcat.startup.Tomcat.main(Tomcat.java:235)
RE: Filter Chains slow first time it is called
Quoting Craig R. McClanahan [EMAIL PROTECTED]: On Wed, 30 May 2001, Craig R. McClanahan wrote: Hello Paul, This definitely sounds like something wrong with Tomcat 4 -- most likely a combination of things related to the browser (which can affect which HTTP version is in use), your filters, and the ultimate servlet or JSP page being called. To help narrow things down a bit: * Do you have a small test case we can use to investigate this? If so, you can send it either to TOMCAT-DEV or to me in private mail. * Are your clients using HTTP/1.0 or HTTP/1.1? * Does your filter create a wrapper on the servlet response, or is it just passing things through? I suspect that somewhere along the line the output stream isn't getting flushed or closed in a timely manner -- the above information will be helpful to be able to identify where. Craig I just added some more unit tests that do output filtering, and they all work immediately. I now more strongly suspect that this problem is related to some combination of using HTTP/1.1, the particular filters and wrappers being executed, and Tomcat not flushing something somewhere when it is supposed to -- but a real-life example would be tremendously helpful in tracking it down further. I suspect it's a special case problem. I quickly tried with the FilterExample in the examples webapp (which does not actually wrap anything), and it works ok. Remy
RE: Problem+Fix concerning static error pages in Tomcat 3.2.2
This was broken in 3.2.1 and unfortunately is still broken in 3.2.2 due to the commit problem I mentioned earlier. Since this isn't a regression failure and there is a work-around we'll log it as a bug and fix it in 3.2.3. -Original Message- From: Marc Saegesser [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 30, 2001 9:38 AM To: [EMAIL PROTECTED] Subject: RE: Problem+Fix concerning static error pages in Tomcat 3.2.2 Bloody hell. This bug was fixed a couple months ago and then got whacked by a late commit to StaticInterceptor.java. I take partial responsibility because I reviewed that commit and missed the problem. I'll try to get this taken care of this evening. -Original Message- From: Peter S. Heijnen [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 30, 2001 12:50 AM To: [EMAIL PROTECTED] Subject: Re: Problem+Fix concerning static error pages in Tomcat 3.2.2 I use virtual hosts, but don't think that is the cause, although I have not traced this down (I will check that aswell). As I think of it, the webapp could simply be empty one with a web.xml like: ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN http://java.sun.com/j2ee/dtds/web-app_2_2.dtd; web-app error-page error-code404/error-code location/errors/404.html/location /error-page /web-app Now, when I request any file through Tomcat, it will fail (error 500: Stack overflow). When a JSP is specified for location, it works fine. Tomcat outputs a correct message from the CM about the requested error page, but FileHandler outputs the originally requested path as requested file. I will set up an independent Tomcat installation and try this again without virtual hosts. If I have the time today, I will wrap up a webapp and post the .war file. - Original Message - From: Marc Saegesser [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, May 29, 2001 8:54 PM Subject: RE: Problem+Fix concerning static error pages in Tomcat 3.2.2 Could you please supply a sample webapp that demonstrates this? Static error pages seem to work OK for me. -Original Message- From: Peer Heijnen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 29, 2001 5:52 AM To: tomcat-dev Subject: Problem+Fix concerning static error pages in Tomcat 3.2.2 I'm using Tomcat 3.2.2 (relase) and have configured static .html files as error pages. We used JSP pages before, and everything was fine... However since we're using static files, Tomcat will enter an infinite loop and eventually crash with a stack overflow (with a good change of leaving Tomcat in a defunct state). We traced down this problem and have found a way to fix it, but I'm not sure if this is correct. All this is related to the ContextManager class: 1) Both handleStatus and handleError will call 'getHandlerForPath' when an error page was configured. 2) getHandlerForPath returns a the Handler for the error page. (since we're using static files, this will be a FileHandler). So far, so good. 3) Eventually handleStatus and handleError will do a 'errorServlet.service( req, res )' to service the error. This is were things go wrong. The problem is, that 'req' passed to the 'errorServlet.service( req, res )' call is the original request, while getHandlerForPath creates a new request internally with the error's request URI. Since the handler (FileHandler) is called with the original request URI, it will try to service a file matching that request, not the static file we configured. This, in turn, will cause and error and, in our case, an infinite loop. This can lead to very strange situations. For example, if an .jsp page generates an error and the error refers to an (existing) static file, it will actually end up showing the .jsp source file contents! The quick and dirty fix we use here is to simply add 'req.setRequestURI( ctx.getPath() + errorPath);' after the 'getHandlerForPath' calls in both handleError and handleStatus methods. I'm not really sure if we are allowed to modify the request in such a way, but error attributes are also set in this request and it seems to work fine for us. But this raises another question: why construct a completely new request and response in getHandlerForPath, and then throw it away? Cheers, Peer Heijnen
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core Constants.java
marcsaeg01/05/30 14:25:34
Modified:src/webpages Tag: tomcat_32 index.html
src/share/org/apache/tomcat/core Tag: tomcat_32
Constants.java
Log:
Updating version numbers to 3.2.3-dev.
Revision ChangesPath
No revision
No revision
1.13.2.19 +2 -2 jakarta-tomcat/src/webpages/index.html
Index: index.html
===
RCS file: /home/cvs/jakarta-tomcat/src/webpages/index.html,v
retrieving revision 1.13.2.18
retrieving revision 1.13.2.19
diff -u -r1.13.2.18 -r1.13.2.19
--- index.html2001/05/29 01:28:36 1.13.2.18
+++ index.html2001/05/30 21:25:29 1.13.2.19
@@ -4,13 +4,13 @@
meta http-equiv=Content-Type content=text/html; charset=iso-8859-1
meta name=GENERATOR content=Mozilla/4.72 [en] (WinNT; U) [Netscape]
meta name=Author content=Anil K. Vijendran
-titleTomcat v3.2.2/title
+titleTomcat v3.2.3-dev/title
/head
body bgcolor=#FF
img SRC=tomcat.gif height=92 width=130 align=LEFTbfont face=Arial,
Helvetica, sans-seriffont size=+3Tomcat/font/font/b
br
bfont face=Arial, Helvetica, sans-seriffont size=-1Version
-3.2.2/font/font/b
+3.2.3-dev/font/font/b
pThis is the default Tomcat home page. This page serves as a quick reference
guide to related resources and is located at:
ul
No revision
No revision
1.22.2.17 +1 -1
jakarta-tomcat/src/share/org/apache/tomcat/core/Attic/Constants.java
Index: Constants.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Attic/Constants.java,v
retrieving revision 1.22.2.16
retrieving revision 1.22.2.17
diff -u -r1.22.2.16 -r1.22.2.17
--- Constants.java2001/05/29 01:28:35 1.22.2.16
+++ Constants.java2001/05/30 21:25:33 1.22.2.17
@@ -67,7 +67,7 @@
public class Constants {
public static final String TOMCAT_NAME = Tomcat Web Server;
-public static final String TOMCAT_VERSION = 3.2.2;
+public static final String TOMCAT_VERSION = 3.2.3-dev;
public static final String JSP_NAME = JSP;
public static final String JSP_VERSION = 1.1;
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/request StaticInterceptor.java
marcsaeg01/05/30 14:33:04 Modified:src/share/org/apache/tomcat/request Tag: tomcat_32 StaticInterceptor.java Log: The previous commit by arieh removed larryi's previous fix for using javax.servlet.include.servlet_path. Revision ChangesPath No revision No revision 1.7.2.10 +4 -1 jakarta-tomcat/src/share/org/apache/tomcat/request/Attic/StaticInterceptor.java Index: StaticInterceptor.java === RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/request/Attic/StaticInterceptor.java,v retrieving revision 1.7.2.9 retrieving revision 1.7.2.10 diff -u -r1.7.2.9 -r1.7.2.10 --- StaticInterceptor.java2001/03/16 23:41:57 1.7.2.9 +++ StaticInterceptor.java2001/05/30 21:33:02 1.7.2.10 @@ -377,7 +377,10 @@ subReq=req.getChild(); Context ctx=subReq.getContext(); - String pathInfo=subReq.getServletPath(); +// If this file is being included, use javax.servlet.include.servlet_path. +String pathInfo = (String)subReq.getAttribute(javax.servlet.include.servlet_path); +if(pathInfo == null) +pathInfo=subReq.getServletPath(); String absPath = (String)subReq.getNote( realFileNote ); if( absPath==null ) absPath=ctx.getRealPath( pathInfo );
Re: mod_webapp under Linux
Pier, Is there anywhere I can download an archive of apr that works! On the other hand if you fix it could you Email me or the list. Thanks. Dave. [EMAIL PROTECTED] From: Pier P. Fumagalli [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: mod_webapp under Linux Date: Wed, 30 May 2001 02:50:49 +0100 kevin seguin at [EMAIL PROTECTED] wrote: it looks like the problem is you're using apache 1.3 (not multi-thread on non-win32 systems) with a multi-threaded build of apr (pthread_sigmask is an export from libpthread.so). i'm just guessing, but i imagine you can build apr in single-thread mode... Yes, it's a bug in the current APR release with Linux... (Digging into it) Pier _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
cvs commit: jakarta-tomcat-4.0/tester/web/WEB-INF web.xml
craigmcc01/05/30 14:54:55
Modified:tester/src/bin tester.xml
tester/src/tester/org/apache/tester UpperCaseFilter.java
tester/web/WEB-INF web.xml
Added: tester/src/tester/org/apache/tester FilterRequest01.java
UpperCaseInputStream.java UpperCaseReader.java
UpperCaseRequest.java
Log:
Add some corresponding tests for input that is wrapped by a filter.
Revision ChangesPath
1.48 +38 -1 jakarta-tomcat-4.0/tester/src/bin/tester.xml
Index: tester.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/tester/src/bin/tester.xml,v
retrieving revision 1.47
retrieving revision 1.48
diff -u -r1.47 -r1.48
--- tester.xml2001/05/30 19:42:44 1.47
+++ tester.xml2001/05/30 21:54:48 1.48
@@ -15,7 +15,7 @@
taskdef name=tester classname=org.apache.tester.TestClient/
- target name=all
depends=ROOT,Authentication,CaseSensitive,Decoding,ErrorPage,FilterResponse,Jndi,RequestDispatcher,Resources,ServletRequest,ServletResponse,HttpSession,XercesTest,SSITest/
+ target name=all
depends=ROOT,Authentication,CaseSensitive,Decoding,ErrorPage,FilterRequest,FilterResponse,Jndi,RequestDispatcher,Resources,ServletRequest,ServletResponse,HttpSession,XercesTest,SSITest/
target name=ROOT
@@ -343,6 +343,43 @@
status=200
outContent=ErrorPage10 PASSED/
+
+ /target
+
+
+ target name=FilterRequest
+
+!-- == Apply Upper Case Filter === --
+
+!-- Input via buffered reader --
+tester host=${host} port=${port} protocol=HTTP/1.0
+ request=${context.path}/FilterRequest01?type=reader
+ debug=${debug}
+ status=200
+ inContent=FilterRequest01 Unwrapped Reader PASSED
+ outContent=FILTERREQUEST01 UNWRAPPED READER PASSED/
+
+tester host=${host} port=${port} protocol=HTTP/1.0
+ request=${context.path}/WrappedFilterRequest01?type=reader
+ debug=${debug}
+ status=200
+ inContent=FilterRequest01 Wrapped Reader PASSED
+ outContent=FILTERREQUEST01 WRAPPED READER PASSED/
+
+!-- Input via servlet input stream --
+tester host=${host} port=${port} protocol=HTTP/1.0
+ request=${context.path}/FilterRequest01?type=reader
+ debug=${debug}
+ status=200
+ inContent=FilterRequest01 Unwrapped Stream PASSED
+ outContent=FILTERREQUEST01 UNWRAPPED STREAM PASSED/
+
+tester host=${host} port=${port} protocol=HTTP/1.0
+ request=${context.path}/WrappedFilterRequest01?type=reader
+ debug=${debug}
+ status=200
+ inContent=FilterRequest01 Wrapped Stream PASSED
+ outContent=FILTERREQUEST01 WRAPPED STREAM PASSED/
/target
1.2 +4 -2
jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/UpperCaseFilter.java
Index: UpperCaseFilter.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/UpperCaseFilter.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- UpperCaseFilter.java 2001/05/30 19:42:46 1.1
+++ UpperCaseFilter.java 2001/05/30 21:54:51 1.2
@@ -68,7 +68,7 @@
* Filter that simply transforms its output to upper case.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.1 $ $Date: 2001/05/30 19:42:46 $
+ * @version $Revision: 1.2 $ $Date: 2001/05/30 21:54:51 $
*/
public class UpperCaseFilter implements Filter {
@@ -88,10 +88,12 @@
FilterChain chain)
throws IOException, ServletException {
+HttpServletRequest wrequest =
+new UpperCaseRequest((HttpServletRequest) request);
HttpServletResponse wresponse =
new UpperCaseResponse((HttpServletResponse) response);
StaticLogger.write(UpperCaseFilter.doFilter() begin);
-chain.doFilter(request, wresponse);
+chain.doFilter(wrequest, wresponse);
StaticLogger.write(UpperCaseFilter.doFilter() end);
}
1.1
jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/FilterRequest01.java
Index: FilterRequest01.java
===
/* = *
* *
* The Apache Software License, Version 1.1 *
* *
* Copyright (c) 1999, 2000, 2001 The Apache Software Foundation. *
*
Re: [Beta5]HttpRequestBase POST buglet
I don't think this patch is what we really want to do.
Currently, the code is testing for all of the following conditions before
trying to parse request parameters from the input stream:
1) The HTTP method is POST
2) The content length is greater than zero
3) The servlet has never called getInputStream() or getReader()
4) The content type is the required value
Your patch would change test (3) to require that the servlet *must* have
called getInputStream() or getReader() first, which would break a large
number of existing servlets.
Do you have a test case that demonstrates a problem? I've got lots of
different web apps that seem to have no problems reading POST-ed request
parameters.
On Mon, 21 May 2001, Mark T. Miller wrote:
[I sent this to the users list on Friday - someone sent me email
telling me I should send it to this group - sorry for the double
post]
I just started using TomCat B5 using the builtin HTTPConnector.
When POST-ing a form, none of the name-value pairs of the
Query string make it through.
I found the below minor logic bug, and it now is working for me.
--- HttpRequestBase.java.orig Fri May 18 16:36:30 2001
+++ HttpRequestBase.javaFri May 18 16:39:40 2001
@@ -616,7 +616,7 @@
if (semicolon = 0)
contentType = contentType.substring(0, semicolon).trim();
if (POST.equals(getMethod()) (getContentLength() 0)
- (this.stream == null)
+ (this.stream != null)
application/x-www-form-urlencoded.equals(contentType)) {
try {
int max = getContentLength();
[PATCH] RE: Packaged tag libraries
Ok well here is a patch to TldLocationsCache that should all Jasper to
correctly process packaged tab libraries. I tested on my system and it
works well. I changed processJars() to use the getResourcePaths method as
Remy suggested. I pulled tldConfigJar() as it did a bunch of stuff with
URL's that appeared to be overly complex. I put the logic from that method
right in the processJars() and accessed the jar files directly (i.e. w/out
a url or connection). I changed parseTldForUri() because it was looking
for a child taglib and then a uri it should have just looked for a uri
right off.
Lastly I'm not sure why the diff produced some 'goofy' stuff. If somebody
lets me know how to fix it I won't do it in the future.
Really lastly - this is my first attempt at sending in a patch to an open
source project so if somehow I've f'ed up the etiquette, then please be
gentle.
- Robert
4c4
* Copyright (c) 1999 The Apache Software Foundation. All rights
---
* Copyright (c) 1999 The Apache Software Foundation. All rights
12c12
*notice, this list of conditions and the following disclaimer.
---
*notice, this list of conditions and the following disclaimer.
20,21c20,21
*any, must include the following acknowlegement:
* This product includes software developed by the
---
*any, must include the following acknowlegement:
* This product includes software developed by the
28c28
*from this software without prior written permission. For written
---
*from this software without prior written permission. For written
54c54
*/
---
*/
63a64,65
import java.util.Set;
import java.util.Iterator;
82c84
*
---
*
121c123
---
188d189
190d190
200,212c200,221
URL libURL = null;
try {
libURL = ctxt.getResource(/WEB-INF/lib);
} catch (MalformedURLException e) {}
if ((libURL != null) file.equals(libURL.getProtocol())) {
File libFile = new File(libURL.getFile());
if (libFile.exists() libFile.canRead()
libFile.isDirectory()) {
String filenames[] = libFile.list();
for (int i=0; ifilenames.length; i++) {
if (!filenames[i].endsWith(.jar)) continue;
tldConfigJar(ctxt, /WEB-INF/lib/ + filenames[i]);
---
try
{
Set libSet = ctxt.getResourcePaths(/WEB-INF/lib);
Iterator it = libSet.iterator();
while( it.hasNext() )
{
String resourcePath = (String) it.next();
JarFile jarFile = new
JarFile(ctxt.getRealPath(resourcePath));
Enumeration enumJarEntries = jarFile.entries();
while( enumJarEntries.hasMoreElements() )
{
JarEntry jarEntry = (JarEntry)
enumJarEntries.nextElement();
String name = jarEntry.getName();
if (!name.startsWith(META-INF/)) continue;
if (!name.endsWith(.tld)) continue;
InputStream stream = jarFile.getInputStream(jarEntry);
String uri = parseTldForUri(resourcePath, stream);
if (uri != null)
{
mappings.put(uri,
new String[]{resourcePath, name} );
}
216c225,226
}
---
catch (MalformedURLException e) {}
catch (IOException ioe) {}
218,272d227
/**
* Process a TLD in the JAR file at the specified resource path
* (if there is one). Will update the URI mappings for all
* the .tld files found in the META-INF directory tree, if
* a uri element is defined in the TLD.
*
* @param resourcePath Context-relative resource path
*/
private void tldConfigJar(ServletContext ctxt, String resourcePath)
throws JasperException
{
JarFile jarFile = null;
InputStream stream = null;
try {
URL url = ctxt.getResource(resourcePath);
if (url == null) return;
url = new URL(jar: + url.toString() + !/);
JarURLConnection conn =
(JarURLConnection) url.openConnection();
jarFile = conn.getJarFile();
Enumeration entries = jarFile.entries();
while (entries.hasMoreElements()) {
JarEntry entry = (JarEntry) entries.nextElement();
String name = entry.getName();
if (!name.startsWith(META-INF/)) continue;
if (!name.endsWith(.tld)) continue;
//p(tldConfigJar( + resourcePath +
// ): Processing entry ' + name + ');
stream = jarFile.getInputStream(entry);
String uri = parseTldForUri(resourcePath, stream);
//p(uri in TLD is: + uri);
if (uri != null) {
Re: mod_webapp under Linux
Dave Oxley at [EMAIL PROTECTED] wrote: Pier, Is there anywhere I can download an archive of apr that works! On the other hand if you fix it could you Email me or the list. I really don't know... It works on MacOS/X, have you tried compiling it without multi threading support? The last two days I've been quite busy updating Nagoya and the bugzilla database and won't have a chance to dig into it before Friday... BTW, have you tried (of course) the latest CVS checkout? :) Thanks and sorry... Pier
[T4] Classloader funk
I'm using T4b5. So, what I did was re-compile some Scarab classes. Those classes are located in scarab/WEB-INF/classes. I have class reloading turned on and when Catalina reloaded the classes, this got output to System.out.println() in my terminal window... What it *looks* like is that when the Session object attempts to be re-serialized, that whatever is in scarab/WEB-INF/lib (ie: turbine.jar) doesn't get added to the classpath before the re-serialization happens. -jon java.lang.NoClassDefFoundError: org/apache/turbine/util/security/RoleSet at java.lang.Class.getMethods0(Native Method) at java.lang.Class.getDeclaredMethods(Class.java:1039) at java.io.ObjectStreamClass.computeSerialVersionUID(ObjectStreamClass.j ava:873) at java.io.ObjectStreamClass.access$200(ObjectStreamClass.java:46) at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:420) at java.security.AccessController.doPrivileged(Native Method) at java.io.ObjectStreamClass.init(ObjectStreamClass.java:401) at java.io.ObjectStreamClass.lookupInternal(ObjectStreamClass.java:112) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:291) at java.util.Hashtable.writeObject(Hashtable.java:757) at java.lang.reflect.Method.invoke(Native Method) at java.io.ObjectOutputStream.invokeObjectWriter(ObjectOutputStream.java :1878) at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1210) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:366) at java.io.ObjectOutputStream.outputClassFields(ObjectOutputStream.java: 1841) at java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java :480) at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1214) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:366) at org.apache.catalina.session.StandardSession.writeObject(StandardSessi on.java:1210) at org.apache.catalina.session.StandardSession.writeObjectData(StandardS ession.java:707) at org.apache.catalina.session.StandardManager.unload(StandardManager.ja va:502) at org.apache.catalina.session.StandardManager.stop(StandardManager.java :648) at org.apache.catalina.core.StandardContext.reload(StandardContext.java: 2316) at org.apache.catalina.loader.ContextNotifier.run(StandardLoader.java:13 51) at java.lang.Thread.run(Thread.java:496) java.lang.StackOverflowError no stack trace available
Re: [ANNOUNCEMENT] Domino / Tomcat connecter available
Andy Armstrong at [EMAIL PROTECTED] wrote: I've written a Tomcat for Lotus Domino in the spirit of the IIS and Netscape connectors making it possible to use Tomcat as Domino's servlet container. It can be found at http://free.tagish.net/domino-tomcat/index.jsp It's quite small and wouldn't look at all out of place in the Tomcat release ;-) I didn't take a look at the sources (bear with me for a second, please :) I believe it's for Tomcat 3.x, but are you actually using the VM inside Domino itself or using something like JNI/AJP?? Thanks a lot... (Will check the sources this weekend) Pier
Re: mod_webapp under Linux
for what it's worth, from the mentioned post, i believe this: An other solution would be to use an APR without threads. To do so use ./configure --enable-threads=no when configuring APR. rather than this: I have no found exactly what happends but just add -lpthread in the (tomcat-connectors)/Makefile solves the problem: is what you want. you want a single-threaded apr for apache 1.3 rather than a multi-threaded mod_webapp. Martin van den Bemt wrote: There is an answer about this in tomcat-dev (I had the same problem and found the solution for it). I believe it's just adding a parameter when compiling. (I posted this also in tomcat-user). Oops.. found the url... See http://marc.theaimsgroup.com/?l=tomcat-devm=99020542608948w=2 (the ant-dev mailinglist...). Have fun, Martin van den Bemt -Original Message- From: Pier P. Fumagalli [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 31, 2001 1:30 AM To: [EMAIL PROTECTED] Subject: Re: mod_webapp under Linux Dave Oxley at [EMAIL PROTECTED] wrote: Pier, Is there anywhere I can download an archive of apr that works! On the other hand if you fix it could you Email me or the list. I really don't know... It works on MacOS/X, have you tried compiling it without multi threading support? The last two days I've been quite busy updating Nagoya and the bugzilla database and won't have a chance to dig into it before Friday... BTW, have you tried (of course) the latest CVS checkout? :) Thanks and sorry... Pier
Re: [PATCH] RE: Packaged tag libraries
Ok well here is a patch to TldLocationsCache that should all Jasper to correctly process packaged tab libraries. I tested on my system and it works well. I changed processJars() to use the getResourcePaths method as Remy suggested. I pulled tldConfigJar() as it did a bunch of stuff with URL's that appeared to be overly complex. I put the logic from that method right in the processJars() and accessed the jar files directly (i.e. w/out a url or connection). I changed parseTldForUri() because it was looking for a child taglib and then a uri it should have just looked for a uri right off. Lastly I'm not sure why the diff produced some 'goofy' stuff. If somebody lets me know how to fix it I won't do it in the future. Really lastly - this is my first attempt at sending in a patch to an open source project so if somehow I've f'ed up the etiquette, then please be gentle. Nice work, but you shouldn't use getRealPath() and access as a file, as getRealPath() can return null. Although it is indeed more complex, tldConfigJar() is the way to go, as it should work in all cases. Remy
Re: [T4] Classloader funk
on 5/30/01 5:56 PM, Remy Maucherat [EMAIL PROTECTED] wrote: I'm using T4b5. So, what I did was re-compile some Scarab classes. Those classes are located in scarab/WEB-INF/classes. I have class reloading turned on and when Catalina reloaded the classes, this got output to System.out.println() in my terminal window... What it *looks* like is that when the Session object attempts to be re-serialized, that whatever is in scarab/WEB-INF/lib (ie: turbine.jar) doesn't get added to the classpath before the re-serialization happens. A similar bug has been filed in bugzilla, so I assume it's the same issue. I don't have an explanation for it at the moment, unfortunately. Remy I can duplicate this bug at will...so, if you need a step by step way of duplicating it, please let me know. I would have checked bugzilla, but of course nagoya is still down... -jon
Re: Problem+Fix concerning static error pages in Tomcat 3.2.2
A related bug to this is a nasty stack overflow error if an error page that you define is not found. It's pretty easy to reproduce, just add this to your web.xml: error-page error-code404/error-code location/some-nonexistant-file.jsp/location /error-page Then try to access a non-existant file. Tomcat will go into an infinite loop until the stack overflows. -Dave On Wed, May 30, 2001 at 04:23:19PM -0500, Marc Saegesser wrote: This was broken in 3.2.1 and unfortunately is still broken in 3.2.2 due to the commit problem I mentioned earlier. Since this isn't a regression failure and there is a work-around we'll log it as a bug and fix it in 3.2.3. -Original Message- From: Marc Saegesser [mailto:[EMAIL PROTECTED]] Bloody hell. This bug was fixed a couple months ago and then got whacked by a late commit to StaticInterceptor.java. I take partial responsibility because I reviewed that commit and missed the problem. I'll try to get this taken care of this evening.
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader StandardLoader.java
remm01/05/30 20:27:58
Modified:catalina/src/share/org/apache/catalina/loader
StandardLoader.java
Log:
- Remove useless thread binding / unbinding during the creation of the loader.
Revision ChangesPath
1.25 +6 -12
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/StandardLoader.java
Index: StandardLoader.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/StandardLoader.java,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- StandardLoader.java 2001/05/04 00:57:06 1.24
+++ StandardLoader.java 2001/05/31 03:27:57 1.25
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/StandardLoader.java,v
1.24 2001/05/04 00:57:06 remm Exp $
- * $Revision: 1.24 $
- * $Date: 2001/05/04 00:57:06 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/StandardLoader.java,v
1.25 2001/05/31 03:27:57 remm Exp $
+ * $Revision: 1.25 $
+ * $Date: 2001/05/31 03:27:57 $
*
*
*
@@ -116,7 +116,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.24 $ $Date: 2001/05/04 00:57:06 $
+ * @version $Revision: 1.25 $ $Date: 2001/05/31 03:27:57 $
*/
public final class StandardLoader
@@ -600,10 +600,6 @@
// Ignore the error here.
}
-// Temporarily bind the current Catalina classloader to the directory
-// context
-DirContextURLStreamHandler.bind(this.container.getResources());
-
// Configure our context repositories if appropriate
setRepositories();
@@ -625,7 +621,8 @@
if( contextURL != null ) {
((StandardClassLoader)classLoader).setPermissions
(contextURL);
-String jarUrl = jar: + contextURL.toString() +
WEB-INF/lib/;
+String jarUrl = jar: + contextURL.toString()
++ WEB-INF/lib/;
((StandardClassLoader)classLoader).setPermissions
(jarUrl);
}
@@ -648,9 +645,6 @@
} catch (Throwable t) {
throw new LifecycleException(start: , t);
}
-
-// Unbind Catalina classloader
-DirContextURLStreamHandler.unbind();
// Validate that all required packages are actually available
validatePackages();
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardContext.java
remm01/05/30 20:53:58
Modified:catalina/src/share/org/apache/catalina/core
StandardContext.java
Log:
- The manager should be able to load classes from /WEB-INF/lib during start(),
stop() and reload().
- Filters will also be able to load classes from /WEB-INF/lib during stop().
Revision ChangesPath
1.60 +55 -56
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java
Index: StandardContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
retrieving revision 1.59
retrieving revision 1.60
diff -u -r1.59 -r1.60
--- StandardContext.java 2001/05/16 17:56:04 1.59
+++ StandardContext.java 2001/05/31 03:53:49 1.60
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
1.59 2001/05/16 17:56:04 remm Exp $
- * $Revision: 1.59 $
- * $Date: 2001/05/16 17:56:04 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
1.60 2001/05/31 03:53:49 remm Exp $
+ * $Revision: 1.60 $
+ * $Date: 2001/05/31 03:53:49 $
*
*
*
@@ -141,7 +141,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.59 $ $Date: 2001/05/16 17:56:04 $
+ * @version $Revision: 1.60 $ $Date: 2001/05/31 03:53:49 $
*/
public class StandardContext
@@ -2280,12 +2280,8 @@
// Stop accepting requests temporarily
setPaused(true);
-if (isUseNaming()) {
-try {
-ContextBindings.bindThread(this, this);
-} catch (NamingException e) {
-}
-}
+// Binding thread
+bindThread();
// Shut down the current version of all active servlets
Container children[] = findChildren();
@@ -2350,8 +2346,6 @@
}
}
-DirContextURLStreamHandler.bind(getResources());
-
// Restart our session manager (AFTER naming context recreated/bound)
if ((manager != null) (manager instanceof Lifecycle)) {
try {
@@ -2375,16 +2369,6 @@
}
}
-if (isUseNaming()) {
-try {
-ContextBindings.bindThread(this, this);
-} catch (NamingException e) {
-log(sm.getString(standardContext.namingInitFailed,
- getName()));
-ok = false;
-}
-}
-
// Restart our currently defined servlets
for (int i = 0; i children.length; i++) {
if (!ok)
@@ -2402,12 +2386,9 @@
}
}
-if (isUseNaming()) {
-ContextBindings.unbindThread(this, this);
-}
+// Unbinding thread
+unbindThread();
-DirContextURLStreamHandler.unbind();
-
// Start accepting requests again
if (ok) {
setPaused(false);
@@ -3177,6 +3158,8 @@
setManager(new StandardManager());
}
+DirContextURLStreamHandler.bind(getResources());
+
// Initialize character set mapper
getCharsetMapper();
@@ -3211,7 +3194,8 @@
getServletContext().setAttribute
(Globals.RESOURCES_ATTR, getResources());
-DirContextURLStreamHandler.bind(getResources());
+// Binding thread
+bindThread();
// Configure and call application event listeners and filters
if (ok) {
@@ -3251,16 +3235,6 @@
list.add(wrapper);
}
-if (isUseNaming()) {
-try {
-ContextBindings.bindThread(this, this);
-} catch (NamingException e) {
-log(sm.getString(standardContext.namingInitFailed,
- getName()));
-ok = false;
-}
-}
-
// Load the collected load on startup servlets
if (debug = 1)
log(Loading + map.size() + load-on-startup servlets);
@@ -3284,12 +3258,9 @@
}
}
}
-
-if (isUseNaming()) {
-ContextBindings.unbindThread(this, this);
-}
-DirContextURLStreamHandler.unbind();
+// Unbinding thread
+unbindThread();
if (ok) {
if (debug = 1)
@@ -3316,19 +3287,13 @@
// Mark this application as unavailable while we shut down
setAvailable(false);
+// Binding thread
+bindThread();
+
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup ContextConfig.java
remm01/05/30 20:56:16
Modified:catalina/src/share/org/apache/catalina/startup
ContextConfig.java
Log:
- Remove useless thread bind / unbind (which are now all done in StandardContext).
Revision ChangesPath
1.46 +4 -10
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/ContextConfig.java
Index: ContextConfig.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
retrieving revision 1.45
retrieving revision 1.46
diff -u -r1.45 -r1.46
--- ContextConfig.java2001/05/08 21:22:36 1.45
+++ ContextConfig.java2001/05/31 03:56:11 1.46
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
1.45 2001/05/08 21:22:36 craigmcc Exp $
- * $Revision: 1.45 $
- * $Date: 2001/05/08 21:22:36 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
1.46 2001/05/31 03:56:11 remm Exp $
+ * $Revision: 1.46 $
+ * $Date: 2001/05/31 03:56:11 $
*
*
*
@@ -87,7 +87,6 @@
import javax.naming.NameClassPair;
import javax.naming.NamingEnumeration;
import javax.naming.directory.DirContext;
-import org.apache.naming.resources.DirContextURLStreamHandler;
import org.apache.catalina.Authenticator;
import org.apache.catalina.Container;
import org.apache.catalina.Context;
@@ -121,7 +120,7 @@
* of that Context, and the associated defined servlets.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.45 $ $Date: 2001/05/08 21:22:36 $
+ * @version $Revision: 1.46 $ $Date: 2001/05/31 03:56:11 $
*/
public final class ContextConfig
@@ -818,7 +817,6 @@
XmlMapper mapper = createWebMapper();
defaultConfig(mapper);
applicationConfig(mapper);
-//DirContextURLStreamHandlerFactory.bind(context.getResources());
// Scan tag library descriptor files for additional listener classes
if (ok)
@@ -855,8 +853,6 @@
context.setAvailable(false);
}
-//DirContextURLStreamHandlerFactory.unbind();
-
}
@@ -950,12 +946,10 @@
URL url = context.getServletContext().getResource(resourcePath);
if (url == null)
return (false);
-DirContextURLStreamHandler.bind(context.getResources());
url = new URL(jar: + url.toString() + !/);
JarURLConnection conn =
(JarURLConnection) url.openConnection();
jarFile = conn.getJarFile();
-DirContextURLStreamHandler.unbind();
boolean found = false;
Enumeration entries = jarFile.entries();
while (entries.hasMoreElements()) {
Re: [T4] Classloader funk
I'm using T4b5. So, what I did was re-compile some Scarab classes. Those classes are located in scarab/WEB-INF/classes. I have class reloading turned on and when Catalina reloaded the classes, this got output to System.out.println() in my terminal window... What it *looks* like is that when the Session object attempts to be re-serialized, that whatever is in scarab/WEB-INF/lib (ie: turbine.jar) doesn't get added to the classpath before the re-serialization happens. CL was indeed broken when stopping the manager. I have committed something which should fix it. [Note : My build environment is totally messed up, so I wasn't able to test with Watchdog or the tester] Remy
Re: [T4] Classloader funk
On Wed, 30 May 2001, Remy Maucherat wrote: I'm using T4b5. So, what I did was re-compile some Scarab classes. Those classes are located in scarab/WEB-INF/classes. I have class reloading turned on and when Catalina reloaded the classes, this got output to System.out.println() in my terminal window... What it *looks* like is that when the Session object attempts to be re-serialized, that whatever is in scarab/WEB-INF/lib (ie: turbine.jar) doesn't get added to the classpath before the re-serialization happens. CL was indeed broken when stopping the manager. I have committed something which should fix it. [Note : My build environment is totally messed up, so I wasn't able to test with Watchdog or the tester] Downloading as I type. I'll let you know if I see anything. Jon, could you give me one of your patented cookbooks for recreating this just in case? My current unit tests do deserialization on reload, and the classes are loaded from a JAR file in WEB-INF/lib, so there must also be something else different about what Scarab is doing. Remy Craig
Re: [T4] Classloader funk
On Wed, 30 May 2001, Remy Maucherat wrote: CL was indeed broken when stopping the manager. I have committed something which should fix it. [Note : My build environment is totally messed up, so I wasn't able to test with Watchdog or the tester] Downloading as I type. I'll let you know if I see anything. Jon, could you give me one of your patented cookbooks for recreating this just in case? My current unit tests do deserialization on reload, and the classes are loaded from a JAR file in WEB-INF/lib, so there must also be something else different about what Scarab is doing. Really ? Perhaps my fix wouldn't fix anything then ... The trace Jon posted was really clear about where the problem was, though : ... org.apache.catalina.session.StandardSession.writeObjectData(StandardS ession.java:707) at org.apache.catalina.session.StandardManager.unload(StandardManager.ja va:502) at org.apache.catalina.session.StandardManager.stop(StandardManager.java :648) at org.apache.catalina.core.StandardContext.reload(StandardContext.java: 2316) ... The catalina internal thread was indeed unbound before calling reload (so that's why the manager failed to load the class when trying to serialize). Remy
Re: [T4] Classloader funk
On Wed, 30 May 2001, Remy Maucherat wrote: On Wed, 30 May 2001, Remy Maucherat wrote: CL was indeed broken when stopping the manager. I have committed something which should fix it. [Note : My build environment is totally messed up, so I wasn't able to test with Watchdog or the tester] Downloading as I type. I'll let you know if I see anything. Tester and Watchdog pass, by the way. Jon, could you give me one of your patented cookbooks for recreating this just in case? My current unit tests do deserialization on reload, and the classes are loaded from a JAR file in WEB-INF/lib, so there must also be something else different about what Scarab is doing. Really ? Perhaps my fix wouldn't fix anything then ... The trace Jon posted was really clear about where the problem was, though : ... org.apache.catalina.session.StandardSession.writeObjectData(StandardS ession.java:707) at org.apache.catalina.session.StandardManager.unload(StandardManager.ja va:502) at org.apache.catalina.session.StandardManager.stop(StandardManager.java :648) at org.apache.catalina.core.StandardContext.reload(StandardContext.java: 2316) ... The catalina internal thread was indeed unbound before calling reload (so that's why the manager failed to load the class when trying to serialize). My interest is in why this problem didn't affect the tester tests, which go through what *sounds* like exactly the same process, yet it has not failed to correctly reload session attributes after a restart. Clearly the tests don't cover the failure mode that Jon encountered, so I want to be able to explore the differences. Remy Craig
URI Rewritng using Apache/mod_ssl..the old story
I have just installed TC3.2.2 final, and URI Rewiting won't work over
mod_ssl
and apache.
without ssl it works fine, also.
I have set the TOMCAT_HOME and the JAVA_HOME... but it won't work
Or isn't it fixed on TC3.2.2 ??
When I install the two external classes from jdk jsse.jar and jnet.jar
in tomcat/lib and start it with an environment variable like bleow (old
bug #578 walkaround) it will work.
The only thing that's gone is that I don't have to patch the
HttpServletResponseFacade.java file out of
tomcat/lib/webserver.jar...
I've indeed tested this behavior with the standard class to test the
sessiontracking whoch comes with tomcat.
Greetings and thanks for inconvenience,
Michael
plz wrote back
Marc Saegesser wrote:
A change very similar to what you propose for
HttpServletResponseFacade.java
was already made for Tomcat 3.2.2b4. There are two conditions that I
know
of where URL rewritting won't work. If you using AJP12 and an SSL
port
other than 443 then Tomcat won't be told that the connection is secure
and
will think that that the URL scheme is HTTP not HTTPS.
HttpServletResponseFacade checks that the scheme of the URL to be
encoded
and the scheme of the current request are the same. To encode an
HTTPS url
you must be on an HTTPS request. [Note: I'm sure I really understand
this
requirement, but its been this way for a long time.]
So the two ways I know of for URL rewriting to fail are if you using
AJP12
and SSL on something other than 443 or if your encoding an HTTPS URL
during
an HTTP request. Are either of these true for your case?
To help diagnose this, could you access the SnoopServlet that comes
with
Tomcat via your SSL connection and post the results. This page will
indicate whether Tomcat thinks the request is secure or not, and if it
thinks the URL scheme is HTTPS.
Thanks, we'll get this worked out.
-Original Message-
From: Wolle [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 04, 2001 5:19 AM
To: [EMAIL PROTECTED]; GOMEZ Henri
Subject: Re: TC 3.2.2b4 URI Rewriting with mod_ssl
Hello,
sorry I just wake up ;-)
Wolle wrote:
GOMEZ Henri wrote:
That is a known Bug ,see
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=578
Marc has said, that he has fixed in the current release
TC3.2.2b4, but it
won't work.
What should I describe now ? The workaround was
Fixed by costin in TC 3.3 since 01/04/22 11:56:03
so I have all these things in TC3.2.2b4, fill it be insert in
TC3.2.2 final ?
not fill - new sentence
so I have to do all these things in TC3.2.2b4, will it be
completly insert in
TC3.2.2 final ?
1. install the jnet.jar and jsse.jar in the ROMCAT/lib dir.
2.set the TOMCAT_OPTS
=-Djava.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol
3. Modify the HttpServletResponseFacade.java:
retrieving revision 1.6.2.3
diff -u -r1.6.2.3 HttpServletResponseFacade.java
---
src/share/org/apache/tomcat/facade/HttpServletResponseFacade.java
2001/03/06 17:38:13 1.6.2.3
+++
src/share/org/apache/tomcat/facade/HttpServletResponseFacade.java
2001/03/20 13:29:41
@@ -353,10 +353,14 @@
return (false);
if
(!request.getServerName().equalsIgnoreCase(url.getHost()))
return (false);
-// Set the URL port to HTTP default if not available
before
comparing
+// Set the URL port to protocol default if not
available before
comparing
int urlPort = url.getPort();
if (urlPort == -1) {
-urlPort = 80;
+if(http.equalsIgnoreCase(url.getProtocol())) {
+urlPort = 80;
+} else if
(https.equalsIgnoreCase(url.getProtocol())) {
+urlPort = 443;
+}
}
if (request.getServerPort() != urlPort)
return (false);
That code need to be commited in 3.2.2b4
only this, or the other two step also ?
only this, or the other two steps also ?
I have made this with TC3.2.2b2 and TC3.2.2b3, and this works.
Then it doesn't matter if you use the ajp12 or ajp13 Protocol
(I have read that this is important to use ajp13)
You need ajp13 to get some SSL web-server vars.
so please help,
You provide a patch which may be included in tomcat and must be
reviewed by Marc for approval but It seems ok to me and Costin
use
the same (cvs commit:
jakarta-tomcat/src/facade22/org/apache/tomcat/facade
HttpServletResponseFacade.java)
thnaks and this will be the last questions about that problem ;-),
Greetings Wolle
thanks and this will be the last questions about that problem ;-),
Greetings Wolle
;-)
thanks for inconvenience
Michael
