small bug in catalina docs
in /catalina/docs/JDBCRealm-howto.html, the documentation states: h2Using digested passwords/h2 pTo use digested password you need to store them digested. To achieve this, you will need to use the same digest strategies that JDBCrealm uses to store the passwords, inside JDBCRealm there is a static method with signature codefinal public static String Digest(String password,String algorithm)/code this method is provided as a tool to be used outside JDBCRealm by an application that want to store passwords readable by JDBCRealm./p there is no such method. - donald
[catalina] small patch for HexUtils
i managed to make tomcat barf an exception when trying to use the
JDBCRealm class. turns out that i needed to patch
org.apache.catalina.util.HexUtils:
[balld@localhost util]$ cvs diff HexUtils.java
Index: HexUtils.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/HexUtils.java,v
retrieving revision 1.1
diff -u -3 -p -r1.1 HexUtils.java
--- HexUtils.java 2000/10/21 01:26:19 1.1
+++ HexUtils.java 2001/04/17 00:25:55
@@ -102,7 +102,7 @@ public final class HexUtils {
* The string manager for this package.
*/
private static StringManager sm =
- StringManager.getManager("org.apache.tomcat.resources");
+ StringManager.getManager("org.apache.catalina.util");
/**
- donald
problem with mod_webapp
hey guys. i'm trying to get the latest mod_webapp from cvs to work with the latest apr from cvs and apache-1.3.12. i'm getting this error when i try to test the configuration: [root@chngw lib]# apachectl configtest Syntax error on line 41 of /usr/local/apache/conf/httpd.conf: Cannot load /usr/local/apache/libexec/mod_webapp.so into server: /usr/local/lib/libapr.so.0: undefined symbol: pthread_create any idea what's going on? it's a redhat-6.2 box with kernel-2.2.18 and glibc-2.1.3-22. apr built cleanly with no errors or warnings. - donald
Re: problem with mod_webapp
On Thu, 28 Jun 2001, kevin seguin wrote: use a non-threaded apr with apache 1.3. thanks. i built apr with --disable-threads and now i get this: [root@chngw apr]# apachectl configtest Syntax error on line 41 of /usr/local/apache/conf/httpd.conf: Cannot load /usr/local/apache/libexec/mod_webapp.so into server: /usr/local/lib/libapr.so.0: undefined symbol: mm_create any additional helpful suggestions? - donald
Re: problem with mod_webapp
On Thu, 28 Jun 2001, Justin Erenkrantz wrote: You need to link against MM (static) to your compilation. See apr/shmem/unix/mm/.libs/libmm.a. mod_webapp should be taking advantage of APRVARS (which has this information). It doesn't seem to be doing so. -- justin pardon my ignorance, what should be statically linked? mod_webapp.so? libwebapp.a? do you have a sample apxs or gcc invokation that i could follow? - donald
Re: problem with mod_webapp
On Thu, 28 Jun 2001, Justin Erenkrantz wrote: On Thu, Jun 28, 2001 at 04:52:01PM -0400, Donald Ball wrote: On Thu, 28 Jun 2001, Justin Erenkrantz wrote: You need to link against MM (static) to your compilation. See apr/shmem/unix/mm/.libs/libmm.a. mod_webapp should be taking advantage of APRVARS (which has this information). It doesn't seem to be doing so. -- justin pardon my ignorance, what should be statically linked? mod_webapp.so? libwebapp.a? do you have a sample apxs or gcc invokation that i could follow? You should be able to add -L/path/to/apr/shmem/unix/mm/.libs -lmm to your apxs -c command line (after mod_webapp.c, if I recall the link order correctly). This tells the compiler to include the MM library - which you aren't including. -- justin strange, libapr seems to include libmm, but i went ahead and built and installed libmm seperately in /usr/local/lib. okay, geez, now i get this error: [root@chngw apache]# apachectl configtest Syntax error on line 42 of /usr/local/apache/conf/httpd.conf: Cannot add module via name 'webapp_module': not in list of loaded modules httpd.conf contains: LoadModule webapp_module libexec/mod_webapp.so AddModule webapp_module any more suggestions? - donald
Re: problem with mod_webapp
On Thu, 28 Jun 2001, Justin Erenkrantz wrote: LoadModule webapp_module libexec/mod_webapp.so AddModule webapp_module AddModule mod_webapp.c suggest that y'all fix /webapp/docs/apache-1.3.html if that's the proper line - which it appears it is - i now get this: [root@chngw apache]# apachectl configtest [Thu Jun 28 21:15:52 2001] 15330 (pr_info.c:66) INFO provider initialized [Thu Jun 28 21:15:52 2001] 15330 (pr_warp.c:492) WARP provider initialized [Thu Jun 28 21:15:52 2001] 15330 (wa_main.c:98) WebApp Library initialized [Thu Jun 28 21:15:52 2001] 15330 (wa_config.c:163) Created connection myConnection (Prov: warp Param: localhost:8008) Syntax OK [Thu Jun 28 21:15:52 2001] 15330 (pr_info.c:77) INFO provider destroyed [Thu Jun 28 21:15:52 2001] 15330 (pr_warp.c:536) WARP provider destroyed [Thu Jun 28 21:15:52 2001] 15330 (wa_main.c:127) WebApp Library destroyed with this in my httpd.conf: LoadModule webapp_module libexec/mod_webapp.so AddModule mod_webapp.c WebAppConnection myConnection warp localhost:8008 but when i add this line: WebAppDeploy intranet myConnection /intranet/ i get this error: [root@chngw apache]# apachectl configtest [Thu Jun 28 21:18:07 2001] 15337 (pr_info.c:66) INFO provider initialized [Thu Jun 28 21:18:07 2001] 15337 (pr_warp.c:492) WARP provider initialized [Thu Jun 28 21:18:07 2001] 15337 (wa_main.c:98) WebApp Library initialized [Thu Jun 28 21:18:07 2001] 15337 (wa_config.c:163) Created connection myConnection (Prov: warp Param: localhost:8008) Syntax error on line 1012 of /usr/local/apache/conf/httpd.conf: Invalid virtual host name what's up with that? - donald
Re: problem with mod_webapp (fwd)
hate to be plaintive, but i'd really appreciate any suggestions y'all would have to offer on this. so close, and yet... - donald -- Forwarded message -- with this in my httpd.conf: LoadModule webapp_module libexec/mod_webapp.so AddModule mod_webapp.c WebAppConnection myConnection warp localhost:8008 but when i add this line: WebAppDeploy intranet myConnection /intranet/ i get this error: [root@chngw apache]# apachectl configtest [Thu Jun 28 21:18:07 2001] 15337 (pr_info.c:66) INFO provider initialized [Thu Jun 28 21:18:07 2001] 15337 (pr_warp.c:492) WARP provider initialized [Thu Jun 28 21:18:07 2001] 15337 (wa_main.c:98) WebApp Library initialized [Thu Jun 28 21:18:07 2001] 15337 (wa_config.c:163) Created connection myConnection (Prov: warp Param: localhost:8008) Syntax error on line 1012 of /usr/local/apache/conf/httpd.conf: Invalid virtual host name what's up with that? - donald
Re: problem with mod_webapp
On Fri, 29 Jun 2001, Pier P. Fumagalli wrote: Oh, I believe you specified your WebAppDeploy _before_ your ServerName directive... If you switch them it should be fine... aha! voila! WebAppInfo now works great, but WebAppDeploy still fails, i now get timeouts when i try to hit urls assigned to my webapp. apache's error_log says: [Thu Jun 28 22:41:03 2001] 16006 (pr_warp.c:459) Host chngw.webslingerZ.com:80 has ID 0 [Thu Jun 28 22:41:03 2001] 16006 (pr_warp.c:324) Sent packet CID=0 TYP=2 LEN=24 [Thu Jun 28 22:41:03 2001] 16006 (pr_warp.c:478) Application intranet under /intranet/ has ID 6 [Thu Jun 28 22:41:03 2001] 16006 (pr_warp.c:522) WARP provider started [Thu Jun 28 22:41:03 2001] 16006 (wa_main.c:108) WebApp Library started [Thu Jun 28 22:41:03 2001] 16006 (pr_warp.c:324) Sent packet CID=0 TYP=4 LEN=4 [Thu Jun 28 22:41:03 2001] 16006 (pr_warp.c:324) Sent packet CID=1 TYP=16 LEN=5 [Thu Jun 28 22:41:03 2001] 16006 (pr_warp.c:324) Sent packet CID=1 TYP=17 LEN=36 [Thu Jun 28 22:41:03 2001] 16006 (pr_warp.c:324) Sent packet CID=1 TYP=18 LEN=2 [Thu Jun 28 22:41:03 2001] 16006 (pr_warp.c:324) Sent packet CID=1 TYP=19 LEN=10 [Thu Jun 28 22:41:03 2001] 16006 (pr_warp.c:324) Sent packet CID=1 TYP=20 LEN=100 [Thu Jun 28 22:41:03 2001] 16006 (pr_warp.c:324) Sent packet CID=1 TYP=20 LEN=49 [Thu Jun 28 22:41:03 2001] 16006 (pr_warp.c:324) Sent packet CID=1 TYP=20 LEN=55 [Thu Jun 28 22:41:03 2001] 16006 (pr_warp.c:324) Sent packet CID=1 TYP=20 LEN=28 [Thu Jun 28 22:41:03 2001] 16006 (pr_warp.c:324) Sent packet CID=1 TYP=20 LEN=25 [Thu Jun 28 22:41:03 2001] 16006 (pr_warp.c:324) Sent packet CID=1 TYP=20 LEN=24 [Thu Jun 28 22:41:03 2001] 16006 (pr_warp.c:324) Sent packet CID=1 TYP=20 LEN=34 [Thu Jun 28 22:41:03 2001] 16006 (pr_warp.c:324) Sent packet CID=1 TYP=20 LEN=29 [Thu Jun 28 22:41:03 2001] 16006 (pr_warp.c:324) Sent packet CID=1 TYP=20 LEN=18 [Thu Jun 28 22:41:03 2001] 16006 (pr_warp.c:324) Sent packet CID=1 TYP=20 LEN=60 [Thu Jun 28 22:41:04 2001] 16037 (pr_info.c:72) INFO provider started [Thu Jun 28 22:41:04 2001] 16037 (pr_warp.c:439) Configuring application intranet for http://chngw.webslingerZ.com:80/intranet/ [Thu Jun 28 22:41:04 2001] 16037 (pr_warp.c:324) Sent packet CID=0 TYP=0 LEN=25 [Thu Jun 28 22:41:59 2001] 16006 (pr_warp.c:744) Status1 HTTP/1.1 [Thu Jun 28 22:41:59 2001] 16006 (pr_warp.c:746) Status2 OK [Thu Jun 28 22:41:59 2001] 16006 (pr_warp.c:753) Header Content-Type: text/html [Thu Jun 28 22:41:59 2001] 16006 (pr_warp.c:412) SHORT len=2048 siz=4096 and catalina.out says: java.lang.IllegalArgumentException: addChild: Child name 'chngw.webslingerz.com.80' is not unique at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:779) at org.apache.catalina.core.StandardEngine.addChild(StandardEngine.java:236) at org.apache.catalina.connector.warp.WarpEngine.addChild(WarpEngine.java:181) at org.apache.catalina.connector.warp.WarpEngine.setupChild(WarpEngine.java:166) at org.apache.catalina.connector.warp.WarpConnectionHandler.process(WarpConnectionHandler.java:105) at org.apache.catalina.connector.warp.WarpHandler.run(WarpHandler.java:156) at java.lang.Thread.run(Thread.java:484) but oddly enough, i just tried again and it's working (!) with one caveat - the connection to my web browser is never closed, or else is closed a long while after all of the data has been sent (the icon keeps spinning after the page is downloaded, in other words). are these expected bugs or should i try to isolate them and report on 'em? in general, are tomcat developers comfortable with mod_webapp's stability? or is it still very much a work in progress? - donald
Re: problem with mod_webapp (fwd)
On Thu, 28 Jun 2001, Justin Erenkrantz wrote: hate to be plaintive, but i'd really appreciate any suggestions y'all would have to offer on this. so close, and yet... As Pier said, just add ServerName. Be nice if you took all of this info and submitted a patch for the docs. I'd bet someone would commit it. I know Aaron Bannert submitted a patch for j-t-c to help installation, but no one committed it. -- justin you're damn skippy i will. good to prod me though. - donald
Re: problem with mod_webapp
On Thu, 28 Jun 2001 [EMAIL PROTECTED] wrote: Connector className=org.apache.ajp.tomcat4.Ajp13Connector port=8009 acceptCount=10 debug=0/ and i built mod_jk.so and put it in my libexec directory, but i don't know how to configure mod_jk in apache's httpd.conf for tomcat-catalina. do you have some configuration advice for this situation? The server side configuration for Ajp13 should be identical for tomcat3 and tomcat4. To get started ( and if you don't have too many static files) you can map the whole context. okay, i've got apache talking to tomcat, but i always get this message: Tomcat Error Report HTTP Status 500 - No Host matches server name foobar.webslingerZ.com my server.xml contains this service: Service name=Tomcat-Apache !-- Connector className=org.apache.catalina.connector.warp.WarpConnector port=8008 minProcessors=5 maxProcessors=75 enableLookups=true acceptCount=10 debug=0/ -- Connector className=org.apache.ajp.tomcat4.Ajp13Connector port=8009 acceptCount=10 debug=0/ Engine className=org.apache.catalina.connector.warp.WarpEngine name=Apache defaultHost=foobar.webslingerZ.com debug=0 appBase=webapps Logger className=org.apache.catalina.logger.FileLogger prefix=apache_log. suffix=.txt timestamp=true/ Realm className=org.apache.catalina.realm.MemoryRealm / /Engine /Service i tried putting a Host element underneath the Engine but it didn't like that at all. i think this must be wrong since i'm trying to associate an Ajp13Connector with a WarpEngine. how should this be configured? sorry, i've not been able to find any docs for this configuration. - donald
Re: problem with mod_webapp
On Fri, 29 Jun 2001, Donald Ball wrote: okay, i've got apache talking to tomcat, but i always get this message: Tomcat Error Report HTTP Status 500 - No Host matches server name foobar.webslingerZ.com never mind, i fixed this problem. i have a new problem, but i started a thread on tomcat-user about it so as to not clog up the dev list with conf questions - although if catalina configuration discussions should be held here, lemme know. - donald
RE: problem with mod_webapp
On Fri, 29 Jun 2001, GOMEZ Henri wrote: i tried putting a Host element underneath the Engine but it didn't like that at all. i think this must be wrong since i'm trying to associate an Ajp13Connector with a WarpEngine. how should this be configured? sorry, i've not been able to find any docs for this configuration. Hi Donald, Your best friend here is Kevin Seguin who does the AJP13 port to TC 4.0 :) well, heck, i took this over to tomcat-user, but what the hell. kevin, i'm getting this error now: 2001-06-29 14:25:00 StandardHost[foobar.webslingerz.com]: Installing web application at context path /intranet from URL file:/usr/local/jakarta-tomcat-4.0-b5/webapps/intranet 2001-06-29 14:25:00 StandardManager[/intranet]: Seeding random number generator class java.security.SecureRandom 2001-06-29 14:25:00 StandardManager[/intranet]: Seeding of random number generator has been completed 2001-06-29 14:25:01 ContextConfig[/intranet]: Added certificates - request attribute Valve 2001-06-29 14:25:01 StandardContext[/intranet]: Error initializing naming context for context /intranet 2001-06-29 14:25:01 StandardContext[/intranet]: Context startup failed due to previous errors my server.xml has this service: Service name=Tomcat-Apache Connector className=org.apache.ajp.tomcat4.Ajp13Connector port=8009 acceptCount=10 debug=0/ Engine name=Apache defaultHost=foobar.webslingerZ.com debug=0 appBase=webapps Logger className=org.apache.catalina.logger.FileLogger prefix=apache_log. suffix=.txt timestamp=true/ Realm className=org.apache.catalina.realm.MemoryRealm / Host name=chngw.webslingerZ.com debug=0 appBase=webapps unpackWARs=true Logger className=org.apache.catalina.logger.FileLogger directory=logs prefix=localhost_apache_log. suffix=.txt timestamp=true/ /Host /Engine /Service what have i done wrong now? *sigh*. oh yeah, the http error is: HTTP Status 503 - This application is not currently available - donald
Re: problem with mod_webapp
On Sat, 30 Jun 2001, Pier P. Fumagalli wrote: well, it seems mod_jk supports the same 'autoconfig' mode as mod_webapp - and it did that since the beginning Sometimes I just wish to quit this whole shit and go working for Starbucks (or Microsoft)... Thank you so much for pointing out what an idiot I am all the times... okay, so what's the upshot for connecting catalina to apache-1.3? - donald
Re: problem with mod_webapp
On Fri, 29 Jun 2001, kevin seguin wrote: jeez... it's been a while since i've used ajp13 with tomcat 4 :) if memory serves... you want to add an ajp13 connector as a child of a service, e.g.: Service name=Tomcat-Standalone Connector className=org.apache.ajp.tomcat4.Ajp13Connector port=8009 acceptCount=10 debug=0/ thanks, that works like a charm. for some reason, it did _not_ work when i duplicated the existing Service and changed the Connector to be this instead (!) but when i added this Connector to the existing Tomcat-Standalone Service, everything's coming up roses now. yeah! so is there still interest in a patch for the mod_webapp docs or has focus been shifted over to mod_jk? - donald
problems compling mod_jk for apache-1.3 on linux
i'm getting these errors with the latest cvs: [root@benjamin apache-1.3]# ./build-unix.sh APACHE_HOME=/usr/local/apache Compiling mod_jk gcc -DLINUX=2 -DMOD_SSL=206106 -DUSE_HSREGEX -DEAPI -DUSE_EXPAT -I../lib/expat-lite -fpic -DSHARED_CORE -DSHARED_MODULE -I/usr/local/apache/include -I../common -I/usr/local/java/include -I/usr/local/java/include/linux -c mod_jk.c In file included from ../common/jk_global.h:68, from mod_jk.c:94: ../common/jk_version.h:93: parse error before `' In file included from ../common/jk_global.h:92, from mod_jk.c:94: /usr/include/netinet/tcp.h:84: parse error before `:' /usr/include/netinet/tcp.h:85: parse error before `:' /usr/include/netinet/tcp.h:86: parse error before `:' /usr/include/netinet/tcp.h:87: parse error before `:' /usr/include/netinet/tcp.h:88: parse error before `:' /usr/include/netinet/tcp.h:89: parse error before `:' /usr/include/netinet/tcp.h:90: parse error before `:' /usr/include/netinet/tcp.h:91: parse error before `:' /usr/include/netinet/tcp.h:92: parse error before `:' /usr/include/netinet/tcp.h:109: parse error before `}' apxs:Break: Command failed with rc=65536 Installing mod_jk.so into /usr/local/apache/libexec cp: mod_jk.so: No such file or directory Done. Install by running ./install-unix.sh the parse error in jk_global.h looks to be a problem in j-t-c repository. the parse error in tcp.h looks to be a problem with my glibc installation, although any clues are welcome as i've never had a problem compiling anything that used tcp before. also, the build script is erroneously trying to install mod_jk.so, which it shouldn't do even if the build was successful, but absolutely shouldn't do if the build is unsuccessful. :) finally, the ./install-unix.sh script doesn't exist. fwiw, i'm using glibc-2.1.3-21 on a linux-2.2.19 box with apache-1.3.12. - donald
problem with redirects when using tomcat-4.0b5 and mod_jk
hey guys. i'm getting a problem with redirects when i use tomcat-4.0b5 and mod_jk with the ajp13 connector. my stacktrace is as follows: Error creating the resourcejava.lang.IllegalArgumentExceptiontables/trouble_ticket_table/query?clause=activeclause=for-employeejava.lang.IllegalArgumentException: tables/trouble_ticket_table/query?clause=activeclause=for-employeejava.lang.IllegalArgumentException: tables/trouble_ticket_table/query?clause=activeclause=for-employeejava.lang.IllegalArgumentException: tables/trouble_ticket_table/query?clause=activeclause=for-employee at org.apache.catalina.connector.HttpResponseBase.toAbsolute(HttpResponseBase.java:673) at org.apache.catalina.connector.HttpResponseBase.encodeRedirectURL(HttpResponseBase.java:925) at org.apache.catalina.connector.HttpResponseFacade.encodeRedirectURL(HttpResponseFacade.java:122) at org.apache.cocoon.environment.http.HttpResponse.encodeRedirectURL(HttpResponse.java:76) at org.apache.cocoon.environment.http.HttpEnvironment.redirect(HttpEnvironment.java:99) at the url is, in fact, valid, and it works great with tomcat-4.0b5 with the http connector. note i'm using mod_jk built from the jtc cvs repository from about a week ago since the current cvs won't build. does anyone have any suggestions? - donald
RE: problems compling mod_jk for apache-1.3 on linux
On Fri, 6 Jul 2001, GOMEZ Henri wrote: What about using my RPM ? i could do, but i wanted to try to get the latest cvs working. as it stands now, it doesn't build. is that to be expected? - donald
problem with redirects when using tomcat-4.0b5 and mod_jk (fwd)
i've seen no responses to this issue. does anyone have any suggestions? - donald -- Forwarded message -- Date: Thu, 5 Jul 2001 22:37:26 -0400 (EDT) From: Donald Ball [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: problem with redirects when using tomcat-4.0b5 and mod_jk hey guys. i'm getting a problem with redirects when i use tomcat-4.0b5 and mod_jk with the ajp13 connector. my stacktrace is as follows: Error creating the resourcejava.lang.IllegalArgumentExceptiontables/trouble_ticket_table/query?clause=activeclause=for-employeejava.lang.IllegalArgumentException: tables/trouble_ticket_table/query?clause=activeclause=for-employeejava.lang.IllegalArgumentException: tables/trouble_ticket_table/query?clause=activeclause=for-employeejava.lang.IllegalArgumentException: tables/trouble_ticket_table/query?clause=activeclause=for-employee at org.apache.catalina.connector.HttpResponseBase.toAbsolute(HttpResponseBase.java:673) at org.apache.catalina.connector.HttpResponseBase.encodeRedirectURL(HttpResponseBase.java:925) at org.apache.catalina.connector.HttpResponseFacade.encodeRedirectURL(HttpResponseFacade.java:122) at org.apache.cocoon.environment.http.HttpResponse.encodeRedirectURL(HttpResponse.java:76) at org.apache.cocoon.environment.http.HttpEnvironment.redirect(HttpEnvironment.java:99) at the url is, in fact, valid, and it works great with tomcat-4.0b5 with the http connector. note i'm using mod_jk built from the jtc cvs repository from about a week ago since the current cvs won't build. does anyone have any suggestions? - donald
Re: problem with redirects when using tomcat-4.0b5 and mod_jk (fwd)
On Sat, 7 Jul 2001, Donald Ball wrote:
i've seen no responses to this issue. does anyone have any suggestions?
- donald
i thought i'd go ahead and take a gander at helping myself. after futilely
trying to get catalina running in a debugger on linux (can anyone else do
this?), i resorted to good ol' System.err and patched HttpResponseBase:
private String toAbsolute(String location) {
if (location == null)
return (location);
// Construct a new absolute URL if possible (cribbed from
// the DefaultErrorPage servlet)
URL url = null;
try {
url = new URL(location);
} catch (MalformedURLException e1) {
HttpServletRequest hreq =
(HttpServletRequest) request.getRequest();
String requrl = HttpUtils.getRequestURL(hreq).toString();
System.err.println(REQURL: +requrl);
try {
url = new URL(new URL(requrl), location);
} catch (MalformedURLException e2) {
throw new IllegalArgumentException(location);
}
}
return (url.toString());
}
and i found the the request url that it's having trouble with is:
https://foobar.webslingerZ.com/foobar/login
apparantly, java.net.URL can't parse this because it doesn't recognize
https as a protocol! i've got a couple of workarounds in mind, but before
i kludge together a patch, is there anything else i can do to fix this?
adding the jsse library doesn't seem to help, but maybe the https protocol
handler needs to be registered?
- donald
Re: Question on HTTPConnector.
On Sat, 7 Jul 2001, Craig R. McClanahan wrote: Well yes, it's bad, but so will any other reaction. What choices are there in handling it? (1) Current behavior of closing the connection and go back to accepting new connections (causes a client-side protocol error) (2) Pause and try again in a bit (but in the mean time, this thread cannot accept any new connections, so they stack up inside the server socket up to acceptCount and then start getting refused) (3) Ignore the maxProcessors parameter and create a new processor (and its associated thread) anyway (can lead to denial of service attacks) Have you a suggestion on how we might deal with this more effectively? shouldn't this event be logged? it would be nice if this happened too frequently for a warning to be sent to the server's administrator. - donald
Re: please read -- need to specify current working directory
On Sun, 8 Jul 2001, Victor Wynnytsky wrote: [ WHY I NEED THIS ] It is very common for an XSL page to include another XSL page. An XSL page called orderDetail.xsl might begin like this... xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform; version=1.0 xsl:import href=nav.xsl/ xsl:import href=grid.xsl/ xsl:template match=/ ... The focus of my problem is on the xsl:import tag. I'm using a *web* path there, and I'm sure everyone using Xalan is using an *file* path. The above sample XSL shows orderDetail.xsl trying to refer to nav.xsl in the same folder (ie: web path). you should check out the javax.xml.transform.URIResolver interface. you can have trax transformers call one of your methods to resolve uris. - donald
Re: Request to Fix Tomcat Standalone 302 redirect Issue
Tim Funk wrote: A patch (which I didn't look at yet) could introduce the following: - Bypassing a security contraints, eg:index.jsp is protected but / isn't - Vulnerabilities - Through a wacky optimizations, other pages might get accidently exposed Just curious... I assume the patch uses RequestDispatcher.forward to handle the request, right? But these checks should already be done by the RequestDispatcher, otherwise _anything_ that uses rd.forward could break security. So if we trust rd, what's the issue? If we don't, um, why _not_? - donald - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
bug found and fixed in jasper in 4.x cvs
I recently had the occasion to try and make jasper's JspC work for my webapp. Unfortunately, it was did not work out of the box. Fortunately, I was able to patch it to make it work. The problem is that my directory structure looks something like this: /WEB-INF/jsp/foo.jsp /WEB-INF/jsp/foo/bar.jsp JspC complained that foo was both a package name and a class name and that that was not allowed (java.util.Map.Entry not withstanding, I guess). Note that when catalina invokes jasper via the JspServlet, the class names are mangled with a $jsp suffix, so this problem does not occur; no idea why the algorithm is different when operating in JspC mode. In any case, I patched JspC to tack on a $jsp suffix to the ctctxt class name (when one has not been manually specified on the command line, that is). I'd be happy to submit a patch if someone can tell me the preferred mechanism these days. I also have a patch for JDBCRealm that generalizes it to allow the user to specify arbitrary SQL queries for getting user and role data. I posted a note about it a month or so ago to deafening silence, perhaps I'll have better luck this time? - donald -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: JSPC refactoring/documentation
On 11/12/2002 at 4:03 PM Costin Manolache wrote: Fredrik Westermarck wrote: The problem that I and others have experienced is that proposals and/or patches, by non-committers, don't get discussed or voted about. You have to keep pushing. If you send patches and proposals you can become a committer - and then you'll start ignoring patches and proposals :-) I know you mean that in jest, but I have two big problems with what you said: 1. Simply sending patches and proposals is enough to become a committer? On the other apache projects on which I've worked, several months of consistent quality patches and involvement on the lists is necessary to achieve committer status. 2. Committers ignore patches and proposals from non-committers - though said with smilies, does seem to be the status quo, from my personal experience and that of others. Do you not see this as a problem? Not every guy who finds (and patches!) a bug in tomcat has the time or interest to become a committer (nor should they), and I don't think you should require that before their patches have a chance to get in. I know that no one ever has enough time to do everything, and staying on top of patch submissions can be a chore, yes. With enough committers, and tomcat certainly seems to have enough, you can manage - make it a rotating chore to scan the developers list, tell patchers that they should contact the module authors directly, use bugzilla to manage the patch queue, etc., etc., etc. I'm sorry - but everyone is very short on time. If you have a real interest in tomcat the best solution is to send patches, insist on getting them accepted and become a committer. I think many people here will tell you it's not that hard. Therein lies the rub. Not every joe that comes up with a patch for tomcat should get committer access, in my eyes. Nor should the tomcat developers ignore contributed patches. There's got to be a better way. - donald -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Fwd: bug found and fixed in jasper in 4.x cvs
Is anyone interested in my (or, indeed, any) patch for this bug? I hate to have to maintain a locally bugfixed version of a (meritocratic?) open source project. - donald *** BEGIN FORWARDED MESSAGE *** On 11/12/2002 at 3:51 PM Donald Ball [EMAIL PROTECTED] wrote: I recently had the occasion to try and make jasper's JspC work for my webapp. Unfortunately, it was did not work out of the box. Fortunately, I was able to patch it to make it work. The problem is that my directory structure looks something like this: /WEB-INF/jsp/foo.jsp /WEB-INF/jsp/foo/bar.jsp JspC complained that foo was both a package name and a class name and that that was not allowed (java.util.Map.Entry not withstanding, I guess). Note that when catalina invokes jasper via the JspServlet, the class names are mangled with a $jsp suffix, so this problem does not occur; no idea why the algorithm is different when operating in JspC mode. In any case, I patched JspC to tack on a $jsp suffix to the ctctxt class name (when one has not been manually specified on the command line, that is). I'd be happy to submit a patch if someone can tell me the preferred mechanism these days. I also have a patch for JDBCRealm that generalizes it to allow the user to specify arbitrary SQL queries for getting user and role data. I posted a note about it a month or so ago to deafening silence, perhaps I'll have better luck this time? - donald -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org *** END FORWARDED MESSAGE *** -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Fwd: error-page status codes broken, no response to bugzilla report
What does one have to do to get a response to a bug report around here? I submitted it to bugzilla, I followed up here. If it's a bug, I'm happy to help patch. If I'm an idiot, I'd appreciate being told so. - donald On 12/18/2002 at 1:00 PM Donald Ball [EMAIL PROTECTED] wrote: I submitted this bug report a few days ago: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15406 It seems to me that tomcat is doing the wrong thing when it tags the error page contents with status code 200 instead of the actual error status code. If this is the case, is anyone interested in fixing tomcat? If this is not the case, can someone try to explain why tomcat's behavior is correct? - donald -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: error-page status codes broken, no response to bugzilla report
On 12/19/2002 at 4:02 PM Martin Algesten wrote: The problem with this bug is that there are people here who don't agree it is a bug... which is just plain ignorant and stupid... THIS IS A BUGIT NEEDS FIXING! Thank you - now I at least know that other people have observed this behavior and I'm not merely on crack. Now it remains to show that the behavior is incorrect. The 2.3 servlet specification doesn't explicitly state that the status code attached to a response handled by an error-page element should be the original status code... (Perhaps I should write to the servlet spec group working on 2.4 to suggest making this explicit?) However, common sense and the HTTP specification both suggest that it would be the right thing to do. If you send a 200 instead of a 404 status code along with an html page which says the given resource was not found, search engines, proxy servers, et. al. will not understand that the resource is missing. Hmm. Digging around in the 2.3 spec more deeply, I note the description of HttpServletResponse.sendError reads: Sends an error response to the client using the specified status clearing the buffer. The server defaults to creating the response to look like an HTML-formatted server error page containing the specified message, setting the content type to text/html, leaving cookies and other headers unmodified. If an error-page declaration has been made for the web application corresponding to the status code passed in, it will be served back in preference to the suggested msg parameter. The first sentence clearly states that the response sent to the client must use the specified status code, regardless of whether the content body is generated by the server automatically or is read from an error-page location. I've tried get this one sorted as well... however, either someone will tell you they don't agree it is a bug and/or they will just ignore you until you go away. I can't accept that. If it's a bug, if it doesn't implement the servlet or HTTP specifications properly, it should be fixed. Apache software has always been about correctness, security, and speed, in that order. - donald -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: error-page status codes broken, no response to bugzilla report
Are any tomcat developers going to express any interest in this issue? I frankly consider being completely ignored to be quite rude and a poor way to interact with the at-large developer community. - donald On 12/19/2002 at 12:13 PM Donald Ball wrote: On 12/19/2002 at 4:02 PM Martin Algesten wrote: The problem with this bug is that there are people here who don't agree it is a bug... which is just plain ignorant and stupid... THIS IS A BUGIT NEEDS FIXING! Thank you - now I at least know that other people have observed this behavior and I'm not merely on crack. Now it remains to show that the behavior is incorrect. The 2.3 servlet specification doesn't explicitly state that the status code attached to a response handled by an error-page element should be the original status code... (Perhaps I should write to the servlet spec group working on 2.4 to suggest making this explicit?) However, common sense and the HTTP specification both suggest that it would be the right thing to do. If you send a 200 instead of a 404 status code along with an html page which says the given resource was not found, search engines, proxy servers, et. al. will not understand that the resource is missing. Hmm. Digging around in the 2.3 spec more deeply, I note the description of HttpServletResponse.sendError reads: Sends an error response to the client using the specified status clearing the buffer. The server defaults to creating the response to look like an HTML-formatted server error page containing the specified message, setting the content type to text/html, leaving cookies and other headers unmodified. If an error-page declaration has been made for the web application corresponding to the status code passed in, it will be served back in preference to the suggested msg parameter. The first sentence clearly states that the response sent to the client must use the specified status code, regardless of whether the content body is generated by the server automatically or is read from an error-page location. I've tried get this one sorted as well... however, either someone will tell you they don't agree it is a bug and/or they will just ignore you until you go away. I can't accept that. If it's a bug, if it doesn't implement the servlet or HTTP specifications properly, it should be fixed. Apache software has always been about correctness, security, and speed, in that order. - donald -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: error-page status codes broken, no response to bugzilla report
On 12/23/2002 at 9:40 AM Costin Manolache wrote: It is on my todo list ( I also need this to work, at least for 500 ). Do you have a patch ? not yet, but i'll be happy to work on one for 4.1.x. thanks for taking the time to respond. - donald -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: error-page status codes broken, no response to bugzilla report
On 12/23/2002 at 9:40 AM Costin Manolache wrote: It is on my todo list ( I also need this to work, at least for 500 ). Do you have a patch ? I have attached an erstwhile patch to the bug in bugzilla. It assumes the content type of the error-page resource to be text/html and uses rd.include instead of rd.forward to get the content body. I have a feeling that someone more well-versed with catalina's internals could write a better patch that gets both the http status code _and_ the content type correct, but I am not that person. Nonetheless, I think the patched behavior is much more correct than the current behavior and should be applied to cvs. - donald -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: error-page status codes broken, no response to bugzilla report
On 1/2/2003 at 9:23 AM Craig R. McClanahan wrote: Nonetheless, I think the patched behavior is much more correct than the current behavior and should be applied to cvs. (Sorry for being out of touch earlier -- holidays and busyness and such). I do not agree with the assertion that the current behavior is broken. snip/ I read and understand that you can map error-page handlers to locations which in fact respond with the original status codes. Nonetheless, it still seems to me that the behavior is incorrect wrt the servlet spec, not to mention http and common sense. Again, I quote: --- Hmm. Digging around in the 2.3 spec more deeply, I note the description of HttpServletResponse.sendError reads: Sends an error response to the client using the specified status clearing the buffer. The server defaults to creating the response to look like an HTML-formatted server error page containing the specified message, setting the content type to text/html, leaving cookies and other headers unmodified. If an error-page declaration has been made for the web application corresponding to the status code passed in, it will be served back in preference to the suggested msg parameter. The first sentence clearly states that the response sent to the client must use the specified status code, regardless of whether the content body is generated by the server automatically or is read from an error-page location. --- It still seems to me that the status code of the error-page should be the status code of the response. Not only is that the behavior implied by the spec, but it also prevents naive web developers from writing webapps that return pretty error response pages tagged with status 200. The default behavior should be to preserve the http conversation, not to censor it. You argue that I should do extra work to preserve the status code. I argue that (if one really wanted to for some arcane reason) one should do extra work to hide it. Regardless of what you/we decide here for tomcat, should this be brought to the servlet expert group for clarification in a forthcoming servlet spec? - donald -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: error-page status codes broken, no response to bugzilla report
The key issue is that declaring an error-page handler ***replaces*** the standard container behavior; it doesn't ***augment*** it. Consider, for example, a webapp that want to implement something like what the Redirect configuration parameter does for Apache (so that old URLs still work). In today's world, you can write such a thing by mapping 404 errors to a servlet that redirects to the desired resource (which ultimately returns a 200) for the URLs it knows about, and just returns the original 404 for everything else. With your proposed change, it would not be possible to implement this functionality. That would be bad. Sure it would be possible. You could handle that case by mapping /* to a servlet and having it do the logic - map old URLs to new URLs (with a proper 301, not a silent internal redirect and a 200, ideally), return 404s for everything else. I can't say if it's easier or harder than the solution you proposed, but it definitely looks possible. For that matter - for the solution that you propose, by a strict reading of the servlet spec, why wouldn't you get into an infinite loop if the location for a 404 error-page returns a 404 status code? or bounce back and forth between 404 and 301, say? I see that tomcat avoids the first problem, at least, but I don't see where in the servlet spec it says that it's supposed to... Regardless of what you/we decide here for tomcat, should this be brought to the servlet expert group for clarification in a forthcoming servlet spec? You're certainly welcome to send them mail: [EMAIL PROTECTED] and it's timely, since Servlet 2.4 is in Proposed Final Draft state, and still subject to correction if needed. (And I'm going to make the above argument if it's brought up for discussion -- to say nothing of the fact that this would break backwards compatibility for loads of existing applications ;-). That's certainly something to consider. Since tomcat is the reference implementation, ambiguities in the spec are resolved by looking at its (buggy :)) behavior, yes? I guess I really wonder what webapps rely on this behavior and why - it seems to me that fixing tomcat to work the way I expect would fix more webapps than it would break. However, I guess I'd be happy if the servlet spec simply explicitly declared what's supposed to happen so web developers who care about http, rest, etc. realize they need to explicitly give status codes to their pretty error pages. I'll write something in. Thanks for your patience with this pedantic problem. - donald -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
