RE: cvs commit: jakarta-tomcat-connectors/src - New directory
+1 let's do src/native, src/java :) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: Friday, May 11, 2001 4:36 AM To: [EMAIL PROTECTED] Subject: Re: cvs commit: jakarta-tomcat-connectors/src - New directory seguin 01/05/10 17:36:37 jakarta-tomcat-connectors/src - New directory I don't agree with that directory structure. I think it should be : [subproject]/src/java Remy
[PROPOSAL] jakarta-tomcat-connectors renaming
I'd like to rename the mod_jk and jk_ stuff to mod_jtc (jtc_) to let users have at the same time the actual mod_jk and the in dev mod_jtc. Are you agree ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
Re: [PROPOSAL] jakarta-tomcat-connectors renaming
+1. GOMEZ Henri wrote: I'd like to rename the mod_jk and jk_ stuff to mod_jtc (jtc_) to let users have at the same time the actual mod_jk and the in dev mod_jtc. Are you agree ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
Re: [PROPOSAL] jakarta-tomcat-connectors renaming
actually, i think i might prefer something like mod_ajp and ajp_. if jtc means jakarta-tomcat-connector, that might be a little too generic. what do you call the next connector protocal? kevin seguin wrote: +1. GOMEZ Henri wrote: I'd like to rename the mod_jk and jk_ stuff to mod_jtc (jtc_) to let users have at the same time the actual mod_jk and the in dev mod_jtc. Are you agree ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
Session per context question
Hi, Is it correct behaviour for Tomcat to create a different session when a call is made to request.getSession(true) if the context is different. I ask because I have a realm implementation that caches stuff in session relating to authentication. I have two contexts in server.xml and each context defines its own JAAS authentication parameters in web.xml. My realm can then determine if a user is authenticated in a particular context. To do this I am using session in the realm and noticed that each context has a different session. Can someone please explain how Tomcat determines if a session should be created when getSession(true) is called. Rgds Antony -- Antony Bowesman Teamware Group [EMAIL PROTECTED] tel: +358 9 5128 2562 fax: +358 9 5128 2705
Tomcat IIS problem in in-process mode
I can't get Tomcat to work correctly with IIS in the in-process mode. I successfully installed Tomcat with the ISAPI redirector (isapi_redirect.dll) the JNI adapter (jni_connect.dll), following the instructions of the in-process-howto.html tomcat-iis-howto.html files. Globally, Tomcat is working well in this configuration, but I often get errors from the redirector. These errors are not fatals to Tomcat, but they make my web application to crash. Here are the two types or errors I get, traced in isapi_redirect.log : 1) [jk_jnicb.c (352)]: Into JNIConnectionHandler::startReasponse [jk_jnicb.c (360)]: In JNIConnectionHandler::startReasponse, 6 headers follow --- [jk_jnicb.c (396)]: --- Expires=Sat, 26 May 2001 08:24:42 GMT [jk_jnicb.c (396)]: --- Content-Type=image/gif [jk_jnicb.c (396)]: --- Cache-Control=max-age=1296000 [jk_jnicb.c (396)]: --- Last-Modified=Fri, 11 May 2001 08:23:09 GMT [jk_jnicb.c (396)]: --- Content-Length=796 [jk_jnicb.c (396)]: --- Servlet-Engine=Tomcat Web Server/3.2.1 (JSP 1.1; Servlet 2.2; Java 1.3.0_02; Windows NT 4.0 x86; ava.vendor=Sun Microsystems Inc.) [jk_jnicb.c (400)]: In JNIConnectionHandler::startReasponse. - End headers. [jk_isapi_plugin.c (201)]: Into jk_ws_service_t::start_response [jk_isapi_plugin.c (261)]: jk_ws_service_t::start_response, ServerSupportFunction failed [jk_jnicb.c (420)]: In JNIConnectionHandler::startReasponse, servers startReasponse failed [jk_jnicb.c (452)]: Done JNIConnectionHandler::startReasponse. 2) [jk_isapi_plugin.c (317)]: jk_ws_service_t::read, ReadClient failed [jk_jnicb.c (131)]: In JNIConnectionHandler::read, failed to read from web server [jk_jnicb.c (139)]: Done JNIConnectionHandler::read I use Tomcat 3.2.1 with Sun's JDK 1.3.0_02, and IIS4.0. I tried to tracks these errors by examinating Tomcat sources, and I concluded that there is a misunderstanding between IIS and isapi_connect.dll, during the call of the ServerSupportFunction function. But I don't know more about this last function and now I'm blocked... Is there a known issue ? Thanks, Yann.
RE: [PROPOSAL] jakarta-tomcat-connectors renaming
actually, i think i might prefer something like mod_ajp and ajp_. if jtc means jakarta-tomcat-connector, that might be a little too generic. what do you call the next connector protocal? and ajp = Apache Jakarta Protocol (which not much clear) somebody an idea for the name ? kevin seguin wrote: +1. GOMEZ Henri wrote: I'd like to rename the mod_jk and jk_ stuff to mod_jtc (jtc_) to let users have at the same time the actual mod_jk and the in dev mod_jtc. Are you agree ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
Re: [PROPOSAL] jakarta-tomcat-connectors renaming
GOMEZ Henri wrote: actually, i think i might prefer something like mod_ajp and ajp_. if jtc means jakarta-tomcat-connector, that might be a little too generic. what do you call the next connector protocal? and ajp = Apache Jakarta Protocol (which not much clear) so, do you envision one native library and one set of connectors (for apache, iis, etc.) that support all connector protocols? if so, then mod_jtc and jtc_ make more sense to me.
RE: tomcat serves .jsp file contained in WEB-INF
This was fixed in Tomcat 3.2.1 and I've verified that Tomcat 3.2.2 does not serve the JSP file in WEB-INF either. -Original Message- From: Richard Wan [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 10, 2001 4:20 PM To: Craig R. McClanahan; [EMAIL PROTECTED] Subject: Re: tomcat serves .jsp file contained in WEB-INF From: Craig R. McClanahan [EMAIL PROTECTED] http://machine:port/appname/WEB-INF/inside.jsp would get served but http://machine:port/appname/WEB-INF/inside.html would not? Neither one should be served back to a direct client request for these URLs. The server is prohibited from returning anything under WEB-INF or META-INF. I've attached a small (4k) .war file which under tomcat 3.2 appears to violate this rule. Namely, direct browser requests to WEB-INF/inside.jsp are served. Is this a known bug? Have I found a bug? or am I just crazy? It's legal to access either of these URLs, however, in the following ways: * As the destination of a RequestDispatcher.forward() or include(): RequestDispatcher rd = getServletContext().getRequestDispatcher(/WEB-INF/inside.jsp); rd.forward(request, response); Excellent, this is precisely what I was hoping. -- Richard F. Wan email: [EMAIL PROTECTED] Phone: 403 263 3287 Fax: 403 265 5690 Servidium Inc. Suite 800, 840 7th Ave SW Calgary, Alberta, Canada T2P 3G2
Re: [PATCH] LDAPRealm implementation
I apologize if my submission of an LDAPRealm implementation appeared presumptuous - at the time that I needed it, all I could find were emails from other people asking if there was one (upon doing web searches.) So after writing it and testing it out and getting the documentation clear, I volunteered it for tomcat, since it was something that a lot of other people could use too. Apparently some discussion has already gone on about an implementation of this, as I found it later when I had some more time to review the archives, and the tomcat 4 b4 release now has an implementation :-). The jakarta website encourages people to get involved; I am a little disappointed to not receive at least a thanks but no thanks response. But I am glad that there is now a realm implementation that will work with LDAP for tomcat.
RE: [PROPOSAL] jakarta-tomcat-connectors renaming
actually, i think i might prefer something like mod_ajp and ajp_. if jtc means jakarta-tomcat-connector, that might be a little too generic. what do you call the next connector protocal? and ajp = Apache Jakarta Protocol (which not much clear) so, do you envision one native library and one set of connectors (for apache, iis, etc.) that support all connector protocols? if so, then mod_jtc and jtc_ make more sense to me. The original goal is to provide support for Apache1.3/2.0/IIS/NES/JNI using for example ajp12/ajp13/ajp14. But there is also a JNI mode used for example by IBM to link their apache to their websphere. jtc seems less related to just ajp
Re: [PATCH] LDAPRealm implementation
I actually ported this one from a 3.2.1 implementation I did, with a few changes. But since there is now a JNDIRealm implementation, wouldn't it be preferred to have a counterpart to that one on the TC 3.3 tree (same setup, etc.)? - Original Message - From: GOMEZ Henri [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, May 11, 2001 6:52 AM Subject: RE: [PATCH] LDAPRealm implementation I'll thanks you for porting the LDAPRealm implementation to the TC 3.3 tree !) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Ellen Lockhart [mailto:[EMAIL PROTECTED]] Sent: Friday, May 11, 2001 3:45 PM To: [EMAIL PROTECTED] Subject: Re: [PATCH] LDAPRealm implementation I apologize if my submission of an LDAPRealm implementation appeared presumptuous - at the time that I needed it, all I could find were emails from other people asking if there was one (upon doing web searches.) So after writing it and testing it out and getting the documentation clear, I volunteered it for tomcat, since it was something that a lot of other people could use too. Apparently some discussion has already gone on about an implementation of this, as I found it later when I had some more time to review the archives, and the tomcat 4 b4 release now has an implementation :-). The jakarta website encourages people to get involved; I am a little disappointed to not receive at least a thanks but no thanks response. But I am glad that there is now a realm implementation that will work with LDAP for tomcat.
RE: [PATCH] LDAPRealm implementation
Yes, you are right, porting JNDIRealm from TC4.0, shouldn't be a difficult task.. and is the easy, lazy and right thing :). In fact i think it's possible to abstract the realm implementation from the container details, as the ongoing effort on jasper for example.. this would be a Good Thing (tm), to have a common realms codebase for all Tomcat trees.. Saludos , Ignacio J. Ortega -Mensaje original- De: Ellen Lockhart [mailto:[EMAIL PROTECTED]] Enviado el: viernes 11 de mayo de 2001 16:04 Para: [EMAIL PROTECTED] Asunto: Re: [PATCH] LDAPRealm implementation I actually ported this one from a 3.2.1 implementation I did, with a few changes. But since there is now a JNDIRealm implementation, wouldn't it be preferred to have a counterpart to that one on the TC 3.3 tree (same setup, etc.)? - Original Message - From: GOMEZ Henri [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, May 11, 2001 6:52 AM Subject: RE: [PATCH] LDAPRealm implementation I'll thanks you for porting the LDAPRealm implementation to the TC 3.3 tree !) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Ellen Lockhart [mailto:[EMAIL PROTECTED]] Sent: Friday, May 11, 2001 3:45 PM To: [EMAIL PROTECTED] Subject: Re: [PATCH] LDAPRealm implementation I apologize if my submission of an LDAPRealm implementation appeared presumptuous - at the time that I needed it, all I could find were emails from other people asking if there was one (upon doing web searches.) So after writing it and testing it out and getting the documentation clear, I volunteered it for tomcat, since it was something that a lot of other people could use too. Apparently some discussion has already gone on about an implementation of this, as I found it later when I had some more time to review the archives, and the tomcat 4 b4 release now has an implementation :-). The jakarta website encourages people to get involved; I am a little disappointed to not receive at least a thanks but no thanks response. But I am glad that there is now a realm implementation that will work with LDAP for tomcat.
Re: [PATCH] LDAPRealm implementation
Ellen Lockhart wrote: The jakarta website encourages people to get involved; I am a little disappointed to not receive at least a thanks but no thanks response. But I am glad that there is now a realm implementation that will work with LDAP for tomcat. This list is a little slow to respond to postings. Don't be put off by not receiving a response promptly. Your contribution is appreciated, even if there are allready something like this allready. -- - Torgeir
RE: [PATCH] LDAPRealm implementation
Yes, you are right, porting JNDIRealm from TC4.0, shouldn't be a difficult task.. and is the easy, lazy and right thing :). In fact i think it's possible to abstract the realm implementation from the container details, as the ongoing effort on jasper for example.. this would be a Good Thing (tm), to have a common realms codebase for all Tomcat trees.. +1 Each contribution is fine, and if you could do JNDIRealm port to 3.3 it will be greatly appreciated by all of us. Thanks Saludos , Ignacio J. Ortega -Mensaje original- De: Ellen Lockhart [mailto:[EMAIL PROTECTED]] Enviado el: viernes 11 de mayo de 2001 16:04 Para: [EMAIL PROTECTED] Asunto: Re: [PATCH] LDAPRealm implementation I actually ported this one from a 3.2.1 implementation I did, with a few changes. But since there is now a JNDIRealm implementation, wouldn't it be preferred to have a counterpart to that one on the TC 3.3 tree (same setup, etc.)? - Original Message - From: GOMEZ Henri [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, May 11, 2001 6:52 AM Subject: RE: [PATCH] LDAPRealm implementation I'll thanks you for porting the LDAPRealm implementation to the TC 3.3 tree !) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Ellen Lockhart [mailto:[EMAIL PROTECTED]] Sent: Friday, May 11, 2001 3:45 PM To: [EMAIL PROTECTED] Subject: Re: [PATCH] LDAPRealm implementation I apologize if my submission of an LDAPRealm implementation appeared presumptuous - at the time that I needed it, all I could find were emails from other people asking if there was one (upon doing web searches.) So after writing it and testing it out and getting the documentation clear, I volunteered it for tomcat, since it was something that a lot of other people could use too. Apparently some discussion has already gone on about an implementation of this, as I found it later when I had some more time to review the archives, and the tomcat 4 b4 release now has an implementation :-). The jakarta website encourages people to get involved; I am a little disappointed to not receive at least a thanks but no thanks response. But I am glad that there is now a realm implementation that will work with LDAP for tomcat.
Re: ajp13 and tomcat 4
kevin seguin wrote: GOMEZ Henri wrote: The discussion about jakarta-tomcat-connectors is closed and the CVS is created (even if I still couldn't access it) -kevin. btw, the reason i'm so interested in this because i want to make the switch from tc3 to tc4, but i *have* to have connector support for iis and netscape before i can do that :) jakarta-tomcat-connector will contains both up to date native mod_jk code and java code for TC 3.2/3.3/4.0, so I really recommand you to commit your code there. will the ajp13 connector go in there two? currently, it relies on core catalina classes to build. if the ajp13 connector is in jakarta-tomcat-connector, it'll require a catalina.jar to build. that's fine with me though... javac --classpath /tomcat_path/.../catalina.jar *.java jar cf Ajp13.jar *.class any thoughts on the directory structure in jakarta-tomcat-connector? i'm assuming there's going to be common ajpxx code, then ajpxx-servletcontainer-connector code, then common util code (i.e. MessageBytes, OutputBuffer), etc.. any ideas on how this will all be segmented out? like jakarta-tomcat-connectors/mod_jk/java/org/apache.../ajp13/*.java jakarta-tomcat-connectors/mod_jk/java/org/apache.../ajpcommon/*.java jakarta-tomcat-connectors/mod_jk/java/org/apache.../connectors/*.java jakarta-tomcat-connectors/mod_jk/apache-1.3 for apache-1.3 and so on? Should we really use Ant? To build the C files on many platforms we will need configure, why not doing like JServ in the past? - A configure that asks or guesses the Webserver location, Tomcat location and java path - Cheers Jean-frederic
[CATALINA] Unknown protocol jndi: MalformedURLException
Hello all, I encounter the following problem using Catalina 4.0b3-4 (while it was working with Tomcat 3.2.x). I deploy a war containing a servlet and a javabean. From a JSP I invoke the servlet, that creates the javabean, that invoke a remote object via RMI calling a method that takes an instance of a parameter class as method argument. In the war I have the servlet in a jar under WEB-INF/lib, and the javabean, the stub, and parameter classes under WEB-INF/classes. Inside the javabean, I lookup JNDI and obtain a java.lang.reflect.Proxy that at the end calls the java.rmi.Remote object passing it the argument. Now, if inside the proxy I call RMIClassLoader.getClassAnnotation on the parameter class, I obtain: jndi:/WEB-INF/classes/ jar:jndi:/WEB-INF/lib/xxx.jar!/ This class annotation is written to the RMI stream and when it comes to the RMI server side, I got the MalformedURLException: unknown protocol jndi. Of course the RMI server side does not know how to handle the jndi: protocol of Catalina, and it does have the parameter class in its classpath. Also, the RMI server does not run with the SecurityManager. Another thing that bothers me is that I expected the context classloader to load the class in the RMI server (from its classpath), discarding the annotated codebase contained in the RMI stream, but this is not the case (but maybe I'm missing something). Furthermore I got a workaround: if I wrap all arguments into a wrapper class, and then the wrapper object into a java.rmi.MarshalledObject, then the whole rigmarole works, ie the call arrives to the server (since java.rmi.MarshalledObject is not loaded from WEB-INF/classes or WEB-INF/lib I have no protocol problems) and then when I call MarshalledObject.get() the context classloader loads correctly the classes from the RMI server classpath. Finally this problems happens also when the RMI server is JBoss, as recently pointed out in the JBoss' mailing list. Any thoughts ? TIA Simon
RE: ajp13 and tomcat 4
javac --classpath /tomcat_path/.../catalina.jar *.java jar cf Ajp13.jar *.class any thoughts on the directory structure in jakarta-tomcat-connector? i'm assuming there's going to be common ajpxx code, then ajpxx-servletcontainer-connector code, then common util code (i.e. MessageBytes, OutputBuffer), etc.. any ideas on how this will all be segmented out? like jakarta-tomcat-connectors/mod_jk/java/org/apache.../ajp13/*.java jakarta-tomcat-connectors/mod_jk/java/org/apache.../ajpcommon/*.java jakarta-tomcat-connectors/mod_jk/java/org/apache.../connectors/*.java jakarta-tomcat-connectors/mod_jk/apache-1.3 for apache-1.3 and so on? Should we really use Ant? To build the C files on many platforms we will need configure, why not doing like JServ in the past? - A configure that asks or guesses the Webserver location, Tomcat location and java path - The project will be in two parts, java and native. I'd like to see ant used for the java part and configure for the native. native hackers know about configure and libtool. java developpers start to learn using ant. Just to help each community find its mark. JF would you like doing the autoconf stuff for the native part ? The source is : jakarta-tomcat-connectors/src/java/ jakarta-tomcat-connectors/src/native/... In my idea native is just mod_jtc, which replace mod_jk. We have only connector projects here for now, mod_jtc (mod_jk)
Re: ajp13 and tomcat 4
The source is : jakarta-tomcat-connectors/src/java/ jakarta-tomcat-connectors/src/native/... i'm fine with that. i believe somebody else did object, though... don't know if that matters :) In my idea native is just mod_jtc, which replace mod_jk. We have only connector projects here for now, mod_jtc (mod_jk)
[GUMP] Build Failure - Tomcat 3.x
This email is autogenerated from the output from: http://jakarta.apache.org/builds/gump/2001-05-11/jakarta-tomcat.html Buildfile: build.xml detect: msg.jdk12: [echo] Detected JDK1.2 msg.jsse: [echo] Detected JSSE init: prepare: [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/classes [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/conf [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/src [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/apps [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/container [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/common [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/logs [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/bin [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/doc [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/webapps [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/native [copy] Copying 10 files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/bin [copy] Copying 19 files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/conf [copy] Copied 1 empty directory to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/conf [copy] Copying 42 files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/doc [copy] Copied 1 empty directory to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/doc [copy] Copying 89 files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/native [copy] Copied 13 empty directories to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/native [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat/build/tomcat [copy] Copying 7 files to /home/rubys/jakarta/jakarta-tomcat/build/tomcat/bin [copy] Could not find file /home/rubys/jakarta/jakarta-ant/dist/lib/jaxp.jar to copy. BUILD FAILED /home/rubys/jakarta/jakarta-tomcat/build.xml:117: Could not find file /home/rubys/jakarta/jakarta-ant/dist/lib/jaxp.jar to copy. Total time: 7 seconds
RE: [PROPOSAL] jakarta-tomcat-connectors renaming
GOMEZ Henri wrote: actually, i think i might prefer something like mod_ajp and ajp_. if jtc means jakarta-tomcat-connector, that might be a little too generic. what do you call the next connector protocal? and ajp = Apache Jakarta Protocol (which not much clear) so, do you envision one native library and one set of connectors (for apache, iis, etc.) that support all connector protocols? if so, then mod_jtc and jtc_ make more sense to me. The original goal is to provide support for Apache1.3/2.0/IIS/NES/JNI using for example ajp12/ajp13/ajp14. But there is also a JNI mode used for example by IBM to link their apache to their websphere. jtc seems less related to just ajp somebody mentioned the directory structure should look something like this: [sub-project]/src/java what would examples of subprojects be under jakarta-tomcat-connectors? jtc? mod_jtc? ajp? i guess i've gotten a little confused here jakarta-tomcat-connectors is a 'subproject' We could find there under jakarta-tomcat-connectors : src/java/jakarta-tomcat-3.2/ src/java/jakarta-tomcat-3.3/ src/java/jakarta-tomcat-4.0/ src/java/jakarta-tomcat-commons/ jakarta-tomcat-connectors/src/native/apache1.3/ jakarta-tomcat-connectors/src/native/apache2.0/ jakarta-tomcat-connectors/src/native/common/ jakarta-tomcat-connectors/src/native/iis/ jakarta-tomcat-connectors/src/native/jni/ jakarta-tomcat-connectors/src/native/netscape/ jakarta-tomcat-connectors/src/native/nt_service/ jakarta-tomcat-connectors/src/native/khttp/
Class Reloading
Sorry it's taken me a week to get back to you on this. Class-reloading is not working in the latest nightly build. I know why, but don't know what the fix is. The problem is in StandardClassLoader::loadClass. This method checks that the class exists, if it does it wants to add it to the classCache HashMap. To do this loadCLass has a loop that loops around all the 'repositories' These repositories are the .jar files in the web-inf lib directory. In the loop it does this classCache.put(name, new ClassCacheEntry (clazz, classUrl, classUrlConnection.getLastModified())); but the loop never breaks, so if you have 4 jars in your lib directory code loops 5 times (once for the classes sub dir and once for each jar) and the 'last' jar in wins. So the classes in my classes directory get added as jar:jndi:/localhost/AddressBook/WEB-INF/lib/xerces.jar!/com/develop/ewebjav a/lab/Browse.class The code should check which 'repository' the class is in and only add that entry to the directory. Of course removing all the jars or putting a break after the first loop (a brutal but effective solution in my case) fixes the problem. Hope this helps, Kevin Jones DevelopMentor www.develop.com
Re: Session per context question
On Fri, 11 May 2001, Antony Bowesman wrote: Hi, Is it correct behaviour for Tomcat to create a different session when a call is made to request.getSession(true) if the context is different. Yes. That's required by the servlet spec. It also makes sense when you think about the class loading aspect: each web application has its own class loader that provides access (for that app) to the contents of WEB-INF/classes and WEB-INF/lib. If you create a session attribute based on one of these classes, that class itself cannot be loaded from any other web app. I ask because I have a realm implementation that caches stuff in session relating to authentication. I have two contexts in server.xml and each context defines its own JAAS authentication parameters in web.xml. My realm can then determine if a user is authenticated in a particular context. To do this I am using session in the realm and noticed that each context has a different session. You might want to look at how Tomcat 4.0 addresses the single sign on feature of the servlet spec, which requires user authentication to be global across the web apps in a virtual host (even though the sessions are unique). It's done by maintaining a separate cookie, and a separate collection of available authentications, that intervenes before the usual per-web-app authentication takes place. The class you want to look at is org.apache.catalina.authenticator.SingleSignOn -- plus you will want to examine the other classes in the same package to see how the interactions work. Can someone please explain how Tomcat determines if a session should be created when getSession(true) is called. As above, sessions are required to be per-webapp. You'll need to use some different mechanism to cache stuff across webapps. Rgds Antony -- Antony Bowesman Teamware Group [EMAIL PROTECTED] tel: +358 9 5128 2562 fax: +358 9 5128 2705 Craig McClanahan
Re: [PATCH] LDAPRealm implementation
On Fri, 11 May 2001, Ellen Lockhart wrote: I apologize if my submission of an LDAPRealm implementation appeared presumptuous - at the time that I needed it, all I could find were emails from other people asking if there was one (upon doing web searches.) So after writing it and testing it out and getting the documentation clear, I volunteered it for tomcat, since it was something that a lot of other people could use too. Apparently some discussion has already gone on about an implementation of this, as I found it later when I had some more time to review the archives, and the tomcat 4 b4 release now has an implementation :-). The jakarta website encourages people to get involved; I am a little disappointed to not receive at least a thanks but no thanks response. But I am glad that there is now a realm implementation that will work with LDAP for tomcat. Ellen, I apologize for the lack of attention (or even response) to your submission -- it's on my list of things to look at, but got pushed by day job priorities (as the number of bug fixes I've done lately indicates, Sun is doing some pretty hefty internal testing of Tomcat 4.0 :-). You've covered a couple of use cases that the current JNDIRealm doesn't yet, that I'd like to see us merge those in. Craig McClanahan
Re: Class Reloading
Thanks Kevin ... I think it's safe to assume that Beta 4 still has this issue :-(. But, other than efficiency concerns, it should still work if the particular class is *only* found in WEB-INF/classes and *not* in any of the WEB-INF/lib/*.jar files, right? NOTE: automatic reloading is currently supported only for unpacked classes in WEB-INF/lib. Craig On Fri, 11 May 2001, Kevin Jones wrote: Sorry it's taken me a week to get back to you on this. Class-reloading is not working in the latest nightly build. I know why, but don't know what the fix is. The problem is in StandardClassLoader::loadClass. This method checks that the class exists, if it does it wants to add it to the classCache HashMap. To do this loadCLass has a loop that loops around all the 'repositories' These repositories are the .jar files in the web-inf lib directory. In the loop it does this classCache.put(name, new ClassCacheEntry (clazz, classUrl, classUrlConnection.getLastModified())); but the loop never breaks, so if you have 4 jars in your lib directory code loops 5 times (once for the classes sub dir and once for each jar) and the 'last' jar in wins. So the classes in my classes directory get added as jar:jndi:/localhost/AddressBook/WEB-INF/lib/xerces.jar!/com/develop/ewebjav a/lab/Browse.class The code should check which 'repository' the class is in and only add that entry to the directory. Of course removing all the jars or putting a break after the first loop (a brutal but effective solution in my case) fixes the problem. Hope this helps, Kevin Jones DevelopMentor www.develop.com
Re: [CATALINA] Unknown protocol jndi: MalformedURLException
Simon, I'm going to do some internal checking within Sun on this as well -- I've only played with RMI a little. The context class loader inside Catalina web apps is the class loader for that web application, so there might be conflicts with RMI's assumptions. I also have a question -- if the classes of the objects you are passing are themselves loaded from a parent class loader (i.e. from $CATALINA_HOME/lib) instead of the web app class loader, do you still have to do the marshalling workaround? I would have expected those classes to be annotated with a file: URL, because they are loaded by a class loader that uses file: URLs for its repository. Craig On Fri, 11 May 2001, Bordet, Simone wrote: Hello all, I encounter the following problem using Catalina 4.0b3-4 (while it was working with Tomcat 3.2.x). I deploy a war containing a servlet and a javabean. From a JSP I invoke the servlet, that creates the javabean, that invoke a remote object via RMI calling a method that takes an instance of a parameter class as method argument. In the war I have the servlet in a jar under WEB-INF/lib, and the javabean, the stub, and parameter classes under WEB-INF/classes. Inside the javabean, I lookup JNDI and obtain a java.lang.reflect.Proxy that at the end calls the java.rmi.Remote object passing it the argument. Now, if inside the proxy I call RMIClassLoader.getClassAnnotation on the parameter class, I obtain: jndi:/WEB-INF/classes/ jar:jndi:/WEB-INF/lib/xxx.jar!/ This class annotation is written to the RMI stream and when it comes to the RMI server side, I got the MalformedURLException: unknown protocol jndi. Of course the RMI server side does not know how to handle the jndi: protocol of Catalina, and it does have the parameter class in its classpath. Also, the RMI server does not run with the SecurityManager. Another thing that bothers me is that I expected the context classloader to load the class in the RMI server (from its classpath), discarding the annotated codebase contained in the RMI stream, but this is not the case (but maybe I'm missing something). Furthermore I got a workaround: if I wrap all arguments into a wrapper class, and then the wrapper object into a java.rmi.MarshalledObject, then the whole rigmarole works, ie the call arrives to the server (since java.rmi.MarshalledObject is not loaded from WEB-INF/classes or WEB-INF/lib I have no protocol problems) and then when I call MarshalledObject.get() the context classloader loads correctly the classes from the RMI server classpath. Finally this problems happens also when the RMI server is JBoss, as recently pointed out in the JBoss' mailing list. Any thoughts ? TIA Simon
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader StandardClassLoader.java
remm01/05/11 11:19:53
Modified:catalina/src/share/org/apache/catalina/loader
StandardClassLoader.java
Log:
- The resource existence check was incorrect when using a URL, which
was breaking reloading in some cases.
Revision ChangesPath
1.18 +7 -6
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/StandardClassLoader.java
Index: StandardClassLoader.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/StandardClassLoader.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- StandardClassLoader.java 2001/05/04 03:49:56 1.17
+++ StandardClassLoader.java 2001/05/11 18:19:40 1.18
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/StandardClassLoader.java,v
1.17 2001/05/04 03:49:56 remm Exp $
- * $Revision: 1.17 $
- * $Date: 2001/05/04 03:49:56 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/StandardClassLoader.java,v
1.18 2001/05/11 18:19:40 remm Exp $
+ * $Revision: 1.18 $
+ * $Date: 2001/05/11 18:19:40 $
*
*
*
@@ -110,7 +110,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.17 $ $Date: 2001/05/04 03:49:56 $
+ * @version $Revision: 1.18 $ $Date: 2001/05/11 18:19:40 $
*/
public class StandardClassLoader
@@ -730,6 +730,9 @@
try {
URLConnection classUrlConnection =
classUrl.openConnection();
+// Check for existence
+InputStream is = classUrlConnection.getInputStream();
+is.close();
if (debug = 4)
log(Caching from ' + classUrl.toString() +
' modified ' +
@@ -740,8 +743,6 @@
(clazz, classUrl,
classUrlConnection.getLastModified()));
} catch (IOException e) {
-log(Failed tracking modifications of '
-+ classUrl.toString() + ');
}
} catch(MalformedURLException ex) {
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources DirContextURLConnection.java
remm01/05/11 11:20:42
Modified:catalina/src/share/org/apache/naming/resources
DirContextURLConnection.java
Log:
- The resource existence check was incorrect when using a URL, which
was breaking reloading in some cases.
Revision ChangesPath
1.9 +5 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources/DirContextURLConnection.java
Index: DirContextURLConnection.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources/DirContextURLConnection.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- DirContextURLConnection.java 2001/04/27 19:21:04 1.8
+++ DirContextURLConnection.java 2001/05/11 18:20:34 1.9
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources/DirContextURLConnection.java,v
1.8 2001/04/27 19:21:04 remm Exp $
- * $Revision: 1.8 $
- * $Date: 2001/04/27 19:21:04 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources/DirContextURLConnection.java,v
1.9 2001/05/11 18:20:34 remm Exp $
+ * $Revision: 1.9 $
+ * $Date: 2001/05/11 18:20:34 $
*
*
*
@@ -91,7 +91,7 @@
* content is directly returned.
*
* @author a href=mailto:[EMAIL PROTECTED];Remy Maucherat/a
- * @version $Revision: 1.8 $
+ * @version $Revision: 1.9 $
*/
public class DirContextURLConnection
extends URLConnection {
@@ -199,6 +199,7 @@
collection = (DirContext) object;
} catch (NamingException e) {
// Object not found
+throw new IOException(Resource not found);
}
connected = true;
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources DirContextURLConnection.java
remm01/05/11 11:24:41
Modified:catalina/src/share/org/apache/naming/resources
DirContextURLConnection.java
Log:
- Revert the commit on URL connection.
Revision ChangesPath
1.10 +4 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources/DirContextURLConnection.java
Index: DirContextURLConnection.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources/DirContextURLConnection.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- DirContextURLConnection.java 2001/05/11 18:20:34 1.9
+++ DirContextURLConnection.java 2001/05/11 18:24:33 1.10
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources/DirContextURLConnection.java,v
1.9 2001/05/11 18:20:34 remm Exp $
- * $Revision: 1.9 $
- * $Date: 2001/05/11 18:20:34 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources/DirContextURLConnection.java,v
1.10 2001/05/11 18:24:33 remm Exp $
+ * $Revision: 1.10 $
+ * $Date: 2001/05/11 18:24:33 $
*
*
*
@@ -91,7 +91,7 @@
* content is directly returned.
*
* @author a href=mailto:[EMAIL PROTECTED];Remy Maucherat/a
- * @version $Revision: 1.9 $
+ * @version $Revision: 1.10 $
*/
public class DirContextURLConnection
extends URLConnection {
@@ -199,7 +199,6 @@
collection = (DirContext) object;
} catch (NamingException e) {
// Object not found
-throw new IOException(Resource not found);
}
connected = true;
cvs commit: jakarta-tomcat/src/share/org/apache/jasper/runtime TagHandlerPool.java TagHandlerPoolImpl.java TagPoolManager.java TagPoolManagerImpl.java
clucas 01/05/11 11:43:41
Modified:src/share/org/apache/jasper/compiler TagPoolGenerator.java
TagPoolManagerGenerator.java
src/share/org/apache/jasper/runtime TagHandlerPool.java
TagHandlerPoolImpl.java TagPoolManager.java
TagPoolManagerImpl.java
Log:
minor comment / javadoc fixes
Revision ChangesPath
1.3 +15 -13
jakarta-tomcat/src/share/org/apache/jasper/compiler/TagPoolGenerator.java
Index: TagPoolGenerator.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/TagPoolGenerator.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- TagPoolGenerator.java 2001/04/28 21:13:36 1.2
+++ TagPoolGenerator.java 2001/05/11 18:42:54 1.3
@@ -1,4 +1,8 @@
/*
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/TagPoolGenerator.java,v
1.3 2001/05/11 18:42:54 clucas Exp $
+ *
+ *
+ *
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999 The Apache Software Foundation. All rights
@@ -68,7 +72,7 @@
* during jsp initialization.
*
* @author Casey Lucas [EMAIL PROTECTED]
- * @see TagPoolManager
+ * @see org.apache.jasper.runtime.TagPoolManager
*/
public class TagPoolGenerator extends GeneratorBase
implements ClassDeclarationPhase, InitMethodPhase {
@@ -118,11 +122,11 @@
* This method returns a unique pool name based on the given
* TagLibraryInfo, TagInfo, and set of tag attributes. Tag
* attribute order does not affect the returned name.
- *
+ *
* @param tli
* @param ti
* @param attributes
- * @return
+ * @return unique pool name based on parameters
*/
public static String getPoolName(TagLibraryInfo tli, TagInfo ti, Hashtable
attributes) {
return getSafeVariableName(tli.getURI() + _ + ti.getTagName() +
getStringFromAttributes(attributes));
@@ -132,12 +136,11 @@
/**
* This method returns a unique pool variable name given
* TagLibraryInfo, TagInfo and set of tag attributes.
- *
+ *
* @param tli
* @param ti
* @param attributes
- * @return
- * @see getPoolName
+ * @return unique pool variable name based on parameters
*/
public static String getPoolVariableName(TagLibraryInfo tli, TagInfo ti,
Hashtable attributes) {
return getPoolVariableName(getPoolName(tli, ti, attributes));
@@ -147,10 +150,9 @@
/**
* This method returns a unique pool variable name given
* a unique pool name
- *
+ *
* @param poolName
- * @return
- * @see getPoolName
+ * @return unique pool variable name
*/
public static String getPoolVariableName(String poolName) {
return getSafeVariableName(POOL_VARIABLE_NAME_PREFIX + poolName);
@@ -187,9 +189,9 @@
/**
* This method generates a string based on a set of tag attributes.
* It sorts the attributes by name then concatenates them.
- *
+ *
* @param attributes
- * @return
+ * @return string based on tag attributes
*/
private static String getStringFromAttributes(Hashtable attributes) {
if (attributes == null || attributes.isEmpty()) {
@@ -240,9 +242,9 @@
* This method generates a string that can be used as a java
* variable name. Characters that cant be used are replaced
* with an underscore.
- *
+ *
* @param s
- * @return
+ * @return string that can be used as java variable name
*/
private static String getSafeVariableName(String s) {
StringBuffer buffer = new StringBuffer();
1.3 +5 -1
jakarta-tomcat/src/share/org/apache/jasper/compiler/TagPoolManagerGenerator.java
Index: TagPoolManagerGenerator.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/TagPoolManagerGenerator.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- TagPoolManagerGenerator.java 2001/04/28 21:13:36 1.2
+++ TagPoolManagerGenerator.java 2001/05/11 18:42:57 1.3
@@ -1,4 +1,8 @@
/*
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/TagPoolManagerGenerator.java,v
1.3 2001/05/11 18:42:57 clucas Exp $
+ *
+ *
+ *
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999 The Apache Software Foundation. All rights
@@ -63,7 +67,7 @@
* declares and
cvs commit: jakarta-tomcat/src/facade22/org/apache/tomcat/facade TagPoolManagerInterceptor.java
clucas 01/05/11 11:45:35
Modified:src/facade22/org/apache/tomcat/facade
TagPoolManagerInterceptor.java
Log:
minor comment / javadoc fix
Revision ChangesPath
1.2 +3 -1
jakarta-tomcat/src/facade22/org/apache/tomcat/facade/TagPoolManagerInterceptor.java
Index: TagPoolManagerInterceptor.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/TagPoolManagerInterceptor.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- TagPoolManagerInterceptor.java2001/03/31 21:53:20 1.1
+++ TagPoolManagerInterceptor.java2001/05/11 18:45:25 1.2
@@ -1,4 +1,6 @@
/*
+ * $Header:
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/TagPoolManagerInterceptor.java,v
1.2 2001/05/11 18:45:25 clucas Exp $
+ *
*
*
* The Apache Software License, Version 1.1
@@ -71,7 +73,7 @@
* dont include this interceptor.
*
* @author Casey Lucas [EMAIL PROTECTED]
- * @see TagPoolManager
+ * @see org.apache.jasper.runtime.TagPoolManager
*/
public class TagPoolManagerInterceptor extends BaseInterceptor {
container security issue
I apologize for repeating this, but I did not yet get any answer.
I wrote a servlet in a classic WAR file at an arbitrary location and NOT in the
org.apache.catalina package. From this servlet, I was able to access a method on the
Deployer, i.e. I was able to access anything public in any Container from outside.
This is only working by using reflection.
Here is the code (not clean, sorry about that) for the doGet method:
response.setContentType(text/plain);
PrintWriter writer = response.getWriter();
Object theWrapper = (Object) this.getServletConfig();
try {
Method method = theWrapper.getClass().getMethod(getParent, new Class[]
{});
Object theContext = method.invoke(theWrapper, new Object[] {});
method = theContext.getClass().getMethod(getParent, new Class[] {});
Object theDeployer = method.invoke(theContext, new Object[] {});
method = theDeployer.getClass().getMethod(findDeployedApps, new Class[]
{});
Object deployedApps = method.invoke(theDeployer, new Object[] {});
String[] apps = (String[]) deployedApps;
writer.println(detected apps:);
for (int i=0; iapps.length;i++) {
writer.println(apps[i]);
}
} catch (Exception e) {
e.printStackTrace();
writer.println(An exception occured when invoking the method,
+e.getMessage());
}
writer.flush();
writer.close();
Conclusion: there is a security issue. We don't need the prerequisite to access
Catalina core classes. I am really wondering how it would be possible to fix this
security problem without an important redesign.
Regards,
Fabien
P.S.: should I include a WAR file?
Re: [PATCH] LDAPRealm implementation
On Fri, 11 May 2001, Ellen Lockhart wrote: I actually ported this one from a 3.2.1 implementation I did, with a few changes. But since there is now a JNDIRealm implementation, wouldn't it be preferred to have a counterpart to that one on the TC 3.3 tree (same setup, etc.)? If you have a LDAP realm that works - then we should at least check it in, there is no rule that there is a single way to do something. If someone wants to port the relm from 4.0 - great too. What about checking it into proposals/modules ? It should also be possible to do a little trick to have it work with both 3.2.1 and 3.3. My only concern is about featurism in 3.3 - as long as something is not required for a (functional) servlet container I would be more happy to see it going to proposals/, and be treated as an add-on module. I would move even the JDBCRealm and few other modules - but since they are part of 3.2 it would mean to (re)move features. That wouldn't be bad for tomcat, but probably it's not a good idea. ( Apache has 3-4 database auth modules, I suspect few for LDAP - choice is good ) Costin - Original Message - From: GOMEZ Henri [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, May 11, 2001 6:52 AM Subject: RE: [PATCH] LDAPRealm implementation I'll thanks you for porting the LDAPRealm implementation to the TC 3.3 tree !) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Ellen Lockhart [mailto:[EMAIL PROTECTED]] Sent: Friday, May 11, 2001 3:45 PM To: [EMAIL PROTECTED] Subject: Re: [PATCH] LDAPRealm implementation I apologize if my submission of an LDAPRealm implementation appeared presumptuous - at the time that I needed it, all I could find were emails from other people asking if there was one (upon doing web searches.) So after writing it and testing it out and getting the documentation clear, I volunteered it for tomcat, since it was something that a lot of other people could use too. Apparently some discussion has already gone on about an implementation of this, as I found it later when I had some more time to review the archives, and the tomcat 4 b4 release now has an implementation :-). The jakarta website encourages people to get involved; I am a little disappointed to not receive at least a thanks but no thanks response. But I am glad that there is now a realm implementation that will work with LDAP for tomcat.
Re: Class Reloading
Craig R. McClanahan wrote: Thanks Kevin ... I think it's safe to assume that Beta 4 still has this issue :-(. But, other than efficiency concerns, it should still work if the particular class is *only* found in WEB-INF/classes and *not* in any of the WEB-INF/lib/*.jar files, right? NOTE: automatic reloading is currently supported only for unpacked classes in WEB-INF/lib. Craig [...] sorry for sending a email to tomcat-dev List :-) I have already installed jakarta-tomcat-4.0-b1/2/3(standalone, JDK1.3, winnt40), and this moring I installed TC4.0-b4, just from my work, I find that I can not enable auto-reloading with TC4.0-b2/3/4, auto-reloading works quite well with TC4.0-b1, the following is detail: - in conf/server.xml, I set the following: ... reloadable=true ... - my testing Servlet class(a class file, not a jar file) is in WEB-INF/classes, I find it can not be auto-reloaded with TC4.0-b2/3/4 - with the same class, with TC4.0-b1, auto-reloading works quite well. and I also have a question: NOTE: automatic reloading is currently supported only for unpacked classes in WEB-INF/lib. I think: - unpacked (Servlet) classes are in WEB-INF/classes, not in WEB-INF/lib, is this a writing error? or I also can put .class file in WEB-INF/lib? i.e. % I only can put jar file in WEB-INF/lib, I can not put class file in WEB-INF/lib % I only can put class file in WEB-INF/classes, I can not put jar file in WEB-INF/classes % or I can put both class/jar file in both classes/lib folder? - now all the jar files in TOMCAT_HOME/lib or WEB-INF/lib can Not be auto-reloaded, only those .class file in WEB-INF/classes should be auto-reloaded is the above right? Thanks in advance for your time! :-) Bo May.11, 2001
Re: container security issue
On 11 May 2001, Fabien Le Floc'h wrote:
I apologize for repeating this, but I did not yet get any answer.
I wrote a servlet in a classic WAR file at an arbitrary location and
NOT in the org.apache.catalina package. From this servlet, I was able
to access a method on the Deployer, i.e. I was able to access anything
public in any Container from outside. This is only working by using
reflection.
I'm investigating this one (and another reported security issue) right
now. I've got an equivalent test case, so I won't need a war file.
Craig
Here is the code (not clean, sorry about that) for the doGet method:
response.setContentType(text/plain);
PrintWriter writer = response.getWriter();
Object theWrapper = (Object) this.getServletConfig();
try {
Method method = theWrapper.getClass().getMethod(getParent, new Class[]
{});
Object theContext = method.invoke(theWrapper, new Object[] {});
method = theContext.getClass().getMethod(getParent, new Class[] {});
Object theDeployer = method.invoke(theContext, new Object[] {});
method = theDeployer.getClass().getMethod(findDeployedApps, new Class[]
{});
Object deployedApps = method.invoke(theDeployer, new Object[] {});
String[] apps = (String[]) deployedApps;
writer.println(detected apps:);
for (int i=0; iapps.length;i++) {
writer.println(apps[i]);
}
} catch (Exception e) {
e.printStackTrace();
writer.println(An exception occured when invoking the method,
+e.getMessage());
}
writer.flush();
writer.close();
Conclusion: there is a security issue. We don't need the prerequisite to access
Catalina core classes. I am really wondering how it would be possible to fix this
security problem without an important redesign.
Regards,
Fabien
P.S.: should I include a WAR file?
Re: Class Reloading
On Fri, 11 May 2001, Bo Xu wrote: Craig R. McClanahan wrote: Thanks Kevin ... I think it's safe to assume that Beta 4 still has this issue :-(. But, other than efficiency concerns, it should still work if the particular class is *only* found in WEB-INF/classes and *not* in any of the WEB-INF/lib/*.jar files, right? NOTE: automatic reloading is currently supported only for unpacked classes in WEB-INF/lib. Craig [...] sorry for sending a email to tomcat-dev List :-) I have already installed jakarta-tomcat-4.0-b1/2/3(standalone, JDK1.3, winnt40), and this moring I installed TC4.0-b4, just from my work, I find that I can not enable auto-reloading with TC4.0-b2/3/4, auto-reloading works quite well with TC4.0-b1, the following is detail: - in conf/server.xml, I set the following: ... reloadable=true ... - my testing Servlet class(a class file, not a jar file) is in WEB-INF/classes, I find it can not be auto-reloaded with TC4.0-b2/3/4 - with the same class, with TC4.0-b1, auto-reloading works quite well. and I also have a question: NOTE: automatic reloading is currently supported only for unpacked classes in WEB-INF/lib. You're right ... it's been a long day already (and it's only 1pm Pacific time). I meant WEB-INF/classes. The one and only place from which automatic reloading will work is unpacked classes in WEB-INF/classes of your own web app. No changes to any classes or JAR files *anywhere* else are recognized. However, you can trigger a reload manually on any app -- whether or not you've set the reloadable attribute -- by using the Manager application. I think: - unpacked (Servlet) classes are in WEB-INF/classes, not in WEB-INF/lib, is this a writing error? or I also can put .class file in WEB-INF/lib? i.e. % I only can put jar file in WEB-INF/lib, I can not put class file in WEB-INF/lib % I only can put class file in WEB-INF/classes, I can not put jar file in WEB-INF/classes % or I can put both class/jar file in both classes/lib folder? - now all the jar files in TOMCAT_HOME/lib or WEB-INF/lib can Not be auto-reloaded, only those .class file in WEB-INF/classes should be auto-reloaded is the above right? Thanks in advance for your time! :-) Bo May.11, 2001 Craig
cvs commit: jakarta-tomcat RELEASE-PLAN-3.3
larryi 01/05/11 13:22:59 Modified:.RELEASE-PLAN-3.3 Log: Update release plan. Issues and priorities aren't final and will be updated as needed. Revision ChangesPath 1.9 +68 -10jakarta-tomcat/RELEASE-PLAN-3.3 Index: RELEASE-PLAN-3.3 === RCS file: /home/cvs/jakarta-tomcat/RELEASE-PLAN-3.3,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- RELEASE-PLAN-3.3 2001/01/31 01:55:38 1.8 +++ RELEASE-PLAN-3.3 2001/05/11 20:22:52 1.9 @@ -68,11 +68,23 @@ Should that not be the case, this release may be skipped since the beta release is expected a week later. -Tomcat 3.3 Beta: +Tomcat 3.3 Milestone 3 Release: - Code Freeze/Tag Date: March 15, 2001 + Code Freeze/Tag Date: May 12, 2001 Release Manager:Larry Isaacs + Known issues in order of priority + + 1. getRequestURI() should return an encoded string (if feasible) + 2. Update build process to create archives and internal directory +structure consistent with other Jakarta projects, i.e. use +jakarta-tomcat-3.3-xxx. + +Tomcat 3.3 Beta 1: + + Code Freeze/Tag Date: March 26, 2001 + Release Manager:Larry Isaacs + No major change will be done after the Beta is build without a vote. The release team can reject any change they feel is too big and can introduce regressions, or is not needed. @@ -82,22 +94,68 @@ During the beta period we will fix all remaining bugs and run the manual tests for the bugs that have no automated test case. + + Known issues in order of priority: + 1. Port all missing updates to Jasper from Tomcat 3.2.2 and verify that +all Jasper theading issues are dealt with. This includes Bugzilla +Bugs 80,140,1039,1123,1280,1646 + 2. Check HttpSessionFacade for spec compliance. +Know problems: +A. setAttribute() calls valueBound() after storing the + object in the session. The spec calls for the reverse. +B. setAttribute() doesn't call valueUnbound() for the + object it replaces, if present. + 3. Session recyling includes keeping the HttpSessionFacade. I believe +this represents a security risk. May need to discard session +facades, or at least discard them for untrusted web applications. + 4. Update getRemoteHost() to be consistent with Tomcat 3.2.2, if +appropriate. In Tomcat 3.2.2, it no longer does a reverse DNS +lookup. + 5. Verify no reqressions. + 6. TBD... + -Tomcat 3.3 Addition Betas: +Tomcat 3.3 Beta 2: - Code Freeze/Tag Date: Weekly from March 15, 2001 + Code Freeze/Tag Date: June 2, 2001 Release Manager:Larry Isaacs - -After the first beta, we will periodically build beta releases in -order to track the evolution. + This release should fix any major bugs found in the + prior beta and any missed regressions. + + Known issues in order of priority: + 1. TBD... + + Tomcat 3.3 Final Release - Code Freeze Date: Apr 5, 2001 + Code Freeze Date: June 9, 2001 Release Manager:Larry Isaacs + + The final build. The pre-requisite for the release is having no bugs in + the test suite, resolution for all known bugs and approval by the community. + + Known issues in order of priority: + 1. Update/fix documentation as much as possible + + +Bugs That Won't Be Fixed In Tomcat 3.3 -The final build. The pre-requisite for the release is having no bugs in -the test suite, resolution for all known bugs and approval by the community. +The following Bugzilla Bugs are known issues that are not planned to be +addressed in Tomcat 3.3. + +Bug #75: Translation time attribute evaluation not provided to + TagExtraInfo class +Bug #143: Tag handlers with properties of type Object +Bug #155: Quick Blurb saying Everything is initialized +Bug #164: IIS Logging +Bug #203: `tomcat.sh env` ruins the shell if $TOMCAT_HOME is not set +Bug #451: ServletException displaying wrong lines in debug information +Bug #481: Misleading exception report +Bug #524: Can't use Apache SSI with mod_jserv +Bug #631: RequestDispatcher.include output is in wrong order +Bug #1057: Context Paths and numerals. +Bug #1433: Comments are parsed inside jsp:include tag. Release criteria
RE: Class Loader Problem?
I think it's fairly safe to postulate what happened--somewhere along the
line, the VALookup.class file was either truncated, copied over, or somehow
mangled (through actions that may have had nothing to do with
compilation--maybe some random cosmic ray passed through the case and
flipped a bit on the disk or something) such that the VM couldn't recognize
the .class file as kosher any more.
BTW, one thing you said you did was take a known good .class file (your
servlet) and rename it to VALookup.class to see if that would work--it will
never work. Java has a definite link between the name of the .class file and
the class it contains. (The name is embedded as an attribute inside the
.class file format.)
Usually 99% of all ClassFormatErrors are due to this same kind of the file
got munged strangeness--my first inclination on a CFE is to do a complete
rebuild and redeploy. (The other 1% is reserved for guys who are building
.class files by hand. :) )
Ted Neward
{.NET||Java} Instructor, DevelopMentor (http://www.develop.com)
http://www.javageeks.com/~tneward/index.html
-Original Message-
From: Wildeboer, Tonnis [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 08, 2001 5:47 PM
To: '[EMAIL PROTECTED]'
Subject: RE: Class Loader Problem?
Well, I considered all those things and finally, I did the only thing you
can do when things get this weird:
I did a completely clean checkout and rebuild of everything and
of course...
problem solved. Guess I'll never know what was really happening, but the
experience (and solution) is a lesson in itself...
Thanks for your reply.
--Tonnis
-Original Message-
From: Bip Thelin [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 08, 2001 4:48 PM
To: [EMAIL PROTECTED]
Subject: Re: Class Loader Problem?
Wildeboer, Tonnis wrote:
[...]
I have gone so far as completely removing VCALookup.class from
my classes
directory and I still get the same Exception.
I also tried instantiating the class from a different file
(first line of
my
doGet()) and still get the same Exception.
I copied a known good class (my servlet class), renamed it to
VCALookup.class, same Exception.
Ok, this is what the Javadocs say about java.lang.ClassFormatError.
snip
Thrown when the Java Virtual Machine attempts to read a class file and
determines that the file is malformed or otherwise cannot be
interpreted as
a class file.
/snip
I interpret this as that the classloader are _finding_ the class but has
problems
loading it.
What is this file/class? Something you copied from somewhere? Could it be
that
you are missing an inline class for VCALookup? i.e.
VCALookup$inlineclass.class
I would think that there's something wrong with the VCALookup class, if it
couldn't
find the file you wou'd have gotten a ClassNotFoundException. Is VCALookup
refering
to any other classed that you've missed to bring to your Tomcat env?
2001-05-01 04:19:15 - Ctx( ): Exception in: R( + /csp + /+cfi/login) -
java.lang.ClassFormatError: VCALookup (Truncated
class file)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass0(Compiled Code)
at java.lang.ClassLoader.defineClass(Compiled Code)
at java.security.SecureClassLoader.defineClass(Compiled Code)
at java.net.URLClassLoader.defineClass(Compiled Code)
at java.net.URLClassLoader.access$1(Compiled Code)
at java.net.URLClassLoader$1.run(Compiled Code)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessController.doPrivileged(Compiled Code)
at java.net.URLClassLoader.findClass(Compiled Code)
at java.lang.ClassLoader.loadClass(Compiled Code)
at sun.misc.Launcher$AppClassLoader.loadClass(Compiled Code)
at java.lang.ClassLoader.loadClass(Compiled Code)
at
org.apache.tomcat.loader.AdaptiveClassLoader.loadClass(Compiled
Code)
at java.lang.ClassLoader.loadClass(Compiled Code)
at java.lang.ClassLoader.loadClassInternal(Compiled Code)
at MediatorAgent.printTemplateResponse(Compiled Code)
at MediatorAgent.printResponse(MediatorAgent.java:606)
at MainVCAServlet.doGeneral(Compiled Code)
at MainVCAServlet.doGet(MainVCAServlet.java:196)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404)
at org.apache.tomcat.core.Handler.service(Handler.java:286)
at
org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372)
at
org.apache.tomcat.core.ContextManager.internalService(ContextManag
er.java:79
7)
at
org.apache.tomcat.core.ContextManager.service(ContextManager.java:743)
at
RE: problems running a servlet that uses core catalina classes
Glenn, just out of curiosity, how could someone create an administrative
web-app for controlling and administering Tomcat? (One of the things I've
been toying with was the idea of doing just such an administrative
interface--installing new webapps, restarting, viewing statistics,
monitoring the server's progress, and so on.)
Ted Neward
{.NET||Java} Instructor, DevelopMentor (http://www.develop.com)
http://www.javageeks.com/~tneward/index.html
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Glenn Nielsen
Sent: Tuesday, May 08, 2001 5:12 PM
To: [EMAIL PROTECTED]
Subject: Re: problems running a servlet that uses core catalina classes
In Tomcat 4 the core catalina classes in
servlet/lib/catalina.jar are hidden
from servlets. A servlet should use the standard Servlet 2.3 classes to
access public information for the request. Your servlet would
not be portable
across differenct servlet containers if you used internal servlet
container classes.
In addition, making those interal tomcat classes visible to web
applications
could allow the security of the servlet container and web
applications to be compromised.
Regards,
Glenn
Fabien Le Floc'h wrote:
Hello,
I am sorry to bother you. But I am trying to write a servlet
that uses some core apache classes and I have problems running it.
- If I use a war archive, tomcat does not find the tomcat
classes/servlet classes when it starts the servlet.
(ClassNoDefFound error). If I then add the catalina.jar and
servlet.jar to the classpath, I have a conflict between classes
loaded dynamically by tomcat and classes in the classpath. (More
precisely I have an object whose class is ServletWrapper but is
not an instance of ServletWrapper. This is because (I guess) the
object is created by the Tomcat classloader and it is compared
with an instance of the classpath objects),
- If I put the jar file in the common/lib directory, it finds
the servlet classes but not the tomcat classes.
- If I put the jar file in server/lib directory, it does not
load my servlet.
The only way I can make it work is to put it in the
catalina.jar file. But that is not nice at all.
Could someone help me with this?
Thank you.
Fabien Le Floc'h
P.S.: I was wondering if it was user or developer oriented...
As I want to use core Tomcat classes I thought it was developer
but maybe I am wrong. Then I apologize.
--
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
--
RE: Class Reloading
But, other than efficiency concerns, it should still work if the particular class is *only* found in WEB-INF/classes and *not* in any of the WEB-INF/lib/*.jar files, right? I don't think so. The class I'm trying to reload is in web-inf/classes, it is not in any of the jars in web-inf/lib (is this what you mean?). I believe (I've yet to test this) that the only way reloading works currently (for me) is if I have no jars in web-inf/lib, Kevin Jones DevelopMentor www.develop.com -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: 11 May 2001 18:58 To: Tomcat-Dev Subject: Re: Class Reloading Thanks Kevin ... I think it's safe to assume that Beta 4 still has this issue :-(. But, other than efficiency concerns, it should still work if the particular class is *only* found in WEB-INF/classes and *not* in any of the WEB-INF/lib/*.jar files, right? NOTE: automatic reloading is currently supported only for unpacked classes in WEB-INF/lib. Craig On Fri, 11 May 2001, Kevin Jones wrote: Sorry it's taken me a week to get back to you on this. Class-reloading is not working in the latest nightly build. I know why, but don't know what the fix is. The problem is in StandardClassLoader::loadClass. This method checks that the class exists, if it does it wants to add it to the classCache HashMap. To do this loadCLass has a loop that loops around all the 'repositories' These repositories are the .jar files in the web-inf lib directory. In the loop it does this classCache.put(name, new ClassCacheEntry (clazz, classUrl, classUrlConnection.getLastModified())); but the loop never breaks, so if you have 4 jars in your lib directory code loops 5 times (once for the classes sub dir and once for each jar) and the 'last' jar in wins. So the classes in my classes directory get added as jar:jndi:/localhost/AddressBook/WEB-INF/lib/xerces.jar!/com/devel op/ewebjav a/lab/Browse.class The code should check which 'repository' the class is in and only add that entry to the directory. Of course removing all the jars or putting a break after the first loop (a brutal but effective solution in my case) fixes the problem. Hope this helps, Kevin Jones DevelopMentor www.develop.com
RE: Class Loader Problem?
Ted,
Thanks for your reply. My responses below...
--Tonnis
-Original Message-
From: Ted Neward [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 11, 2001 1:35 PM
To: [EMAIL PROTECTED]
Subject: RE: Class Loader Problem?
I think it's fairly safe to postulate what
happened--somewhere along the
line, the VALookup.class file was either truncated, copied
over, or somehow
mangled (through actions that may have had nothing to do with
compilation--maybe some random cosmic ray passed through the case and
flipped a bit on the disk or something) such that the VM
couldn't recognize
the .class file as kosher any more.
I rebuilt the class, modified and rebuilt the class, renamed the class,
removed the class, searched everywhere I could think of for VCALookup*
including the Tomcat and related jar files and could not find anything
anywhere except my WEB-INF/classes directory. (Which was a symbolic link to
the real classes directory, if that's any clue.)
BTW, one thing you said you did was take a known good .class
file (your
servlet) and rename it to VALookup.class to see if that would
work--it will
never work. Java has a definite link between the name of the
.class file and
the class it contains. (The name is embedded as an attribute
inside the
.class file format.)
Yes, I figured that. That's the reason I did it, to try to get some other
Exception besides the Truncated class file. When I did that and STILL got
the same Exception, that's when I realized I'd better create a whole new
checkout. (And yes, I did restart Tomcat each time, eventhough I had the
reaload option set to false.)
Usually 99% of all ClassFormatErrors are due to this same
kind of the file
got munged strangeness--my first inclination on a CFE is to
do a complete
rebuild and redeploy. (The other 1% is reserved for guys who
are building
.class files by hand. :) )
Ted Neward
{.NET||Java} Instructor, DevelopMentor (http://www.develop.com)
http://www.javageeks.com/~tneward/index.html
-Original Message-
From: Wildeboer, Tonnis [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 08, 2001 5:47 PM
To: '[EMAIL PROTECTED]'
Subject: RE: Class Loader Problem?
Well, I considered all those things and finally, I did the
only thing you
can do when things get this weird:
I did a completely clean checkout and rebuild of everything and
of course...
problem solved. Guess I'll never know what was really
happening, but the
experience (and solution) is a lesson in itself...
Thanks for your reply.
--Tonnis
-Original Message-
From: Bip Thelin [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 08, 2001 4:48 PM
To: [EMAIL PROTECTED]
Subject: Re: Class Loader Problem?
Wildeboer, Tonnis wrote:
[...]
I have gone so far as completely removing VCALookup.class from
my classes
directory and I still get the same Exception.
I also tried instantiating the class from a different file
(first line of
my
doGet()) and still get the same Exception.
I copied a known good class (my servlet class), renamed it to
VCALookup.class, same Exception.
Ok, this is what the Javadocs say about java.lang.ClassFormatError.
snip
Thrown when the Java Virtual Machine attempts to read a
class file and
determines that the file is malformed or otherwise cannot be
interpreted as
a class file.
/snip
I interpret this as that the classloader are _finding_ the
class but has
problems
loading it.
What is this file/class? Something you copied from
somewhere? Could it be
that
you are missing an inline class for VCALookup? i.e.
VCALookup$inlineclass.class
I would think that there's something wrong with the
VCALookup class, if it
couldn't
find the file you wou'd have gotten a
ClassNotFoundException. Is VCALookup
refering
to any other classed that you've missed to bring to your Tomcat env?
2001-05-01 04:19:15 - Ctx( ): Exception in: R( + /csp +
/+cfi/login) -
java.lang.ClassFormatError: VCALookup (Truncated
class file)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass0(Compiled Code)
at java.lang.ClassLoader.defineClass(Compiled Code)
at
java.security.SecureClassLoader.defineClass(Compiled Code)
at java.net.URLClassLoader.defineClass(Compiled Code)
at java.net.URLClassLoader.access$1(Compiled Code)
at java.net.URLClassLoader$1.run(Compiled Code)
at
java.security.AccessController.doPrivileged(Native Method)
at
java.security.AccessController.doPrivileged(Compiled Code)
at java.net.URLClassLoader.findClass(Compiled Code)
at java.lang.ClassLoader.loadClass(Compiled Code)
at
sun.misc.Launcher$AppClassLoader.loadClass(Compiled Code)
at java.lang.ClassLoader.loadClass(Compiled Code)
at
R: [CATALINA] Unknown protocol jndi: MalformedURLException
Craig, Simon, I'm going to do some internal checking within Sun on this as well -- I've only played with RMI a little. The context class loader inside Catalina web apps is the class loader for that web application, so there might be conflicts with RMI's assumptions. I also have a question -- if the classes of the objects you are passing are themselves loaded from a parent class loader (i.e. from $CATALINA_HOME/lib) instead of the web app class loader, do you still have to do the marshalling workaround? I would have expected those classes to be annotated with a file: URL, because they are loaded by a class loader that uses file: URLs for its repository. I'll try this, but I still expect the context class loader to load the classes, since the file: url will reflect the host of Catalina, but I'm already on the RMI server host, so file system is different. Unless I miss somthing (which is very likely), also RMI here seems to behave not as espected... And BTW should't the classes loaded from $CATALINA_HOME/lib have a codebase annotation in form of an URL and served by a HTTP server (Catalina itself I think) so that the RMI server can dynamically download these classes in case of necessity ? I imagine a situation where I deploy a war on Catalina with some implementation classes, and a jar on a RMI server with the interface that the classes in the war implement. The RMI server should be able to download the classes from Catalina, but to do this the codebase annotation should be something like http://web_host/dynamic_download_classes/ instead of jar:file:$CATALINA_HOME/lib/xxx.jar!/, correct ? Thanks for your attention, Simon Craig On Fri, 11 May 2001, Bordet, Simone wrote: Hello all, I encounter the following problem using Catalina 4.0b3-4 (while it was working with Tomcat 3.2.x). I deploy a war containing a servlet and a javabean. From a JSP I invoke the servlet, that creates the javabean, that invoke a remote object via RMI calling a method that takes an instance of a parameter class as method argument. In the war I have the servlet in a jar under WEB-INF/lib, and the javabean, the stub, and parameter classes under WEB-INF/classes. Inside the javabean, I lookup JNDI and obtain a java.lang.reflect.Proxy that at the end calls the java.rmi.Remote object passing it the argument. Now, if inside the proxy I call RMIClassLoader.getClassAnnotation on the parameter class, I obtain: jndi:/WEB-INF/classes/ jar:jndi:/WEB-INF/lib/xxx.jar!/ This class annotation is written to the RMI stream and when it comes to the RMI server side, I got the MalformedURLException: unknown protocol jndi. Of course the RMI server side does not know how to handle the jndi: protocol of Catalina, and it does have the parameter class in its classpath. Also, the RMI server does not run with the SecurityManager. Another thing that bothers me is that I expected the context classloader to load the class in the RMI server (from its classpath), discarding the annotated codebase contained in the RMI stream, but this is not the case (but maybe I'm missing something). Furthermore I got a workaround: if I wrap all arguments into a wrapper class, and then the wrapper object into a java.rmi.MarshalledObject, then the whole rigmarole works, ie the call arrives to the server (since java.rmi.MarshalledObject is not loaded from WEB-INF/classes or WEB-INF/lib I have no protocol problems) and then when I call MarshalledObject.get() the context classloader loads correctly the classes from the RMI server classpath. Finally this problems happens also when the RMI server is JBoss, as recently pointed out in the JBoss' mailing list. Any thoughts ? TIA Simon
RE: Class Reloading
After a successful FORM login, how does Tomcat restore the original request? If it uses the forward mechanism, how does it force the browser to use the URL of the original request, and not */j_security_check? Tim Julien HP Middleware
RE: Class Reloading
On Fri, 11 May 2001, JULIEN,TIMOTHY (HP-NewJersey,ex2) wrote: After a successful FORM login, how does Tomcat restore the original request? If it uses the forward mechanism, how does it force the browser to use the URL of the original request, and not */j_security_check? Tim Julien HP Middleware Details depend on the Tomcat version. For 4.0, the original request is saved (inside the session) and, after authentication is completed, an effective forward is done to the page that was originally requested. You are correct that this can confuse the browser's resolution of relative paths. However, I don't know how else you can implement the semantics required by the spec -- in particular, if the request that triggered authentication was a POST, the post data will be lost if you do a redirect. I'm open to suggestions on implementation approaches. Craig
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util RequestUtil.java
marcsaeg01/05/11 15:34:30
Modified:src/share/org/apache/tomcat/util Tag: tomcat_32
RequestUtil.java
Log:
Fixes one last JSP source disclosure bug. On some platforms a URL ending
in .jsp%00 would cause the JSP's source text to be served back to the
client.
URLDecode() now works similar to Apache httpd and treats %00 and %2f
as forbidden characters in a URL.
Revision ChangesPath
No revision
No revision
1.14.2.4 +6 -13
jakarta-tomcat/src/share/org/apache/tomcat/util/Attic/RequestUtil.java
Index: RequestUtil.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/Attic/RequestUtil.java,v
retrieving revision 1.14.2.3
retrieving revision 1.14.2.4
diff -u -r1.14.2.3 -r1.14.2.4
--- RequestUtil.java 2001/03/17 20:52:50 1.14.2.3
+++ RequestUtil.java 2001/05/11 22:34:28 1.14.2.4
@@ -274,7 +274,7 @@
* @author: cut paste from JServ, much faster that previous tomcat impl
*/
public final static String URLDecode(String str)
- throws NumberFormatException, StringIndexOutOfBoundsException
+ throws NumberFormatException,
StringIndexOutOfBoundsException,IllegalArgumentException
{
if (str == null) return null;
@@ -312,18 +312,11 @@
strPos++;
continue;
} else if (metaChar == '%') {
- // We throw the original exception - the super will deal with it
- //try {
- dec.append((char) Integer.parseInt(
-str.substring(strPos + 1, strPos +
3), 16));
- //} catch (NumberFormatException e) {
- //throw new IllegalArgumentException(invalid
hexadecimal
- //+ str.substring(strPos + 1, strPos + 3)
- //+ in URLencoded string (illegal unescaped
'%'?) );
- //} catch (StringIndexOutOfBoundsException e) {
- //throw new IllegalArgumentException(illegal
unescaped '%'
- //+ in URLencoded string );
- //}
+char c = (char) Integer.parseInt(str.substring(strPos + 1, strPos +
3), 16);
+if(c == '/' || c == '\0')
+throw new IllegalArgumentException(URL contains encoded
special chars.);
+
+dec.append(c);
strPos += 3;
}
}
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/service/connector Ajp12ConnectionHandler.java Ajp13ConnectorRequest.java
marcsaeg01/05/11 15:37:26
Modified:src/share/org/apache/tomcat/core Tag: tomcat_32
RequestImpl.java
src/share/org/apache/tomcat/service/connector Tag: tomcat_32
Ajp12ConnectionHandler.java
Ajp13ConnectorRequest.java
Log:
getRemoteHost() now does DNS lookups (if necessary) to determine the
remote host name based on the client's IP address.
PR: 208
Revision ChangesPath
No revision
No revision
1.52.2.10 +10 -2
jakarta-tomcat/src/share/org/apache/tomcat/core/Attic/RequestImpl.java
Index: RequestImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Attic/RequestImpl.java,v
retrieving revision 1.52.2.9
retrieving revision 1.52.2.10
diff -u -r1.52.2.9 -r1.52.2.10
--- RequestImpl.java 2001/05/07 16:24:34 1.52.2.9
+++ RequestImpl.java 2001/05/11 22:37:21 1.52.2.10
@@ -813,9 +813,17 @@
}
public String getRemoteHost() {
-// This is belt and suspenders. The request adapters should have set this
correctly.
-if(remoteHost == null || remoteHost.length() == 0)
+// AJP12 defaults to empty string, AJP13 defaults to null
+if(remoteHost != null remoteHost.length() != 0)
+return remoteHost;
+
+try{
+remoteHost = InetAddress.getByName(remoteAddr).getHostName();
+}catch(Exception e){
+// If anything went wrong then fall back to using the remote hosts IP
address
remoteHost = remoteAddr;
+}
+
return remoteHost;
}
No revision
No revision
1.28.2.4 +0 -2
jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Attic/Ajp12ConnectionHandler.java
Index: Ajp12ConnectionHandler.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Attic/Ajp12ConnectionHandler.java,v
retrieving revision 1.28.2.3
retrieving revision 1.28.2.4
diff -u -r1.28.2.3 -r1.28.2.4
--- Ajp12ConnectionHandler.java 2001/05/07 16:24:40 1.28.2.3
+++ Ajp12ConnectionHandler.java 2001/05/11 22:37:23 1.28.2.4
@@ -271,8 +271,6 @@
if( doLog ) log(AJP: RA= + remoteAddr );
remoteHost = ajpin.readString();//remote host
-if(remoteHost.length() == 0)
-remoteHost = remoteAddr; // If host isn't specified then use IP
address
if( doLog ) log(AJP: RH= + remoteHost );
remoteUser = ajpin.readString(null); //remote user
1.5.2.7 +3 -5
jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Attic/Ajp13ConnectorRequest.java
Index: Ajp13ConnectorRequest.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Attic/Ajp13ConnectorRequest.java,v
retrieving revision 1.5.2.6
retrieving revision 1.5.2.7
diff -u -r1.5.2.6 -r1.5.2.7
--- Ajp13ConnectorRequest.java2001/05/07 16:24:42 1.5.2.6
+++ Ajp13ConnectorRequest.java2001/05/11 22:37:24 1.5.2.7
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Attic/Ajp13ConnectorRequest.java,v
1.5.2.6 2001/05/07 16:24:42 marcsaeg Exp $
- * $Revision: 1.5.2.6 $
- * $Date: 2001/05/07 16:24:42 $
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Attic/Ajp13ConnectorRequest.java,v
1.5.2.7 2001/05/11 22:37:24 marcsaeg Exp $
+ * $Revision: 1.5.2.7 $
+ * $Date: 2001/05/11 22:37:24 $
*
*
*
@@ -144,8 +144,6 @@
requestURI = msg.getString();
remoteAddr = msg.getString();
remoteHost = msg.getString();
-if(remoteHost == null) //If we don't have a host then use the IP
address
-remoteHost = remoteAddr;
serverName = msg.getString();
serverPort = msg.getInt();
bsc= msg.getByte();
Re: Class Reloading
Kevin Jones wrote: [...] I believe (I've yet to test this) that the only way reloading works currently (for me) is if I have no jars in web-inf/lib, Kevin Jones DevelopMentor www.develop.com [...] yes! I just test it with TC4.0-b4: - when I empty WEB-INF/lib, auto-reloading works - when I copy a jar file into WEB-INF/lib, I can not auto-reloading MyServlet which is a .class file in WEB-INF/classes thanks for your email! :-) Bo May.11, 2001
cvs commit: jakarta-tomcat/src/doc readme
marcsaeg01/05/11 15:44:33 Modified:.Tag: tomcat_32 RELEASE-NOTES src/doc Tag: tomcat_32 readme Log: Updated description of the fix for bug 208. Revision ChangesPath No revision No revision 1.1.2.8 +6 -3 jakarta-tomcat/Attic/RELEASE-NOTES Index: RELEASE-NOTES === RCS file: /home/cvs/jakarta-tomcat/Attic/RELEASE-NOTES,v retrieving revision 1.1.2.7 retrieving revision 1.1.2.8 diff -u -r1.1.2.7 -r1.1.2.8 --- RELEASE-NOTES 2001/05/08 01:31:17 1.1.2.7 +++ RELEASE-NOTES 2001/05/11 22:44:28 1.1.2.8 @@ -1,4 +1,4 @@ -$Id: RELEASE-NOTES,v 1.1.2.7 2001/05/08 01:31:17 marcsaeg Exp $ +$Id: RELEASE-NOTES,v 1.1.2.8 2001/05/11 22:44:28 marcsaeg Exp $ Release Notes for: @@ -295,6 +295,7 @@ will indicate a URL scheme of HTTP. The AJP13 protocol does not suffer from this problem. + === 7. FIXES AND ENHANCEMENTS IN UPDATES @@ -332,8 +333,10 @@ - HttpServletRequest.encodeURL() now properly encodes URLs that contain an anchor but no query string. (#1182) - Error pages now work in virtual hosts. - - ServletRequest.getRemoteHost() now returns the remote IP address - if the remote host name isn't known. (#208) + - ServletRequest.getRemoteHost() now does a DNS lookup (if necessary) to + determine the name of the remote host. As required by the spec, if this + look up fails the method returns the remote host's IP address. (#208) + Jasper - Fix for UnsupportedEncodingException due to UTF8 instead of UTF-8. (#269) No revision No revision 1.8.2.20 +6 -3 jakarta-tomcat/src/doc/readme Index: readme === RCS file: /home/cvs/jakarta-tomcat/src/doc/readme,v retrieving revision 1.8.2.19 retrieving revision 1.8.2.20 diff -u -r1.8.2.19 -r1.8.2.20 --- readme2001/05/08 01:31:19 1.8.2.19 +++ readme2001/05/11 22:44:32 1.8.2.20 @@ -1,4 +1,4 @@ -$Id: readme,v 1.8.2.19 2001/05/08 01:31:19 marcsaeg Exp $ +$Id: readme,v 1.8.2.20 2001/05/11 22:44:32 marcsaeg Exp $ Release Notes for: @@ -295,6 +295,7 @@ will indicate a URL scheme of HTTP. The AJP13 protocol does not suffer from this problem. + === 7. FIXES AND ENHANCEMENTS IN UPDATES @@ -332,8 +333,10 @@ - HttpServletRequest.encodeURL() now properly encodes URLs that contain an anchor but no query string. (#1182) - Error pages now work in virtual hosts. - - ServletRequest.getRemoteHost() now returns the remote IP address - if the remote host name isn't known. (#208) + - ServletRequest.getRemoteHost() now does a DNS lookup (if necessary) to + determine the name of the remote host. As required by the spec, if this + look up fails the method returns the remote host's IP address. (#208) + Jasper - Fix for UnsupportedEncodingException due to UTF8 instead of UTF-8. (#269)
Re: Class Reloading
Craig R. McClanahan wrote: On Fri, 11 May 2001, JULIEN,TIMOTHY (HP-NewJersey,ex2) wrote: After a successful FORM login, how does Tomcat restore the original request? If it uses the forward mechanism, how does it force the browser to use the URL of the original request, and not */j_security_check? Details depend on the Tomcat version. For 4.0, the original request is saved (inside the session) and, after authentication is completed, an effective forward is done to the page that was originally requested. You are correct that this can confuse the browser's resolution of relative paths. However, I don't know how else you can implement the semantics required by the spec -- in particular, if the request that triggered authentication was a POST, the post data will be lost if you do a redirect. I'm open to suggestions on implementation approaches. Our content management system (done over a year ago using an early tomcat version) required a more robust authentication/authorization system than was then available. We subclassed HTTPServlet, did the forward from this wrapper when authentication was required, and the form login was posted back to the originally requested url (where the authorization info was intercepted by the wrapper). It works pretty well for us. Just another implementation possibility. Paul Anguiano Seattle Public Schools
Re: Class Reloading
Quoting Bo Xu [EMAIL PROTECTED]: Kevin Jones wrote: [...] I believe (I've yet to test this) that the only way reloading works currently (for me) is if I have no jars in web-inf/lib, Kevin Jones DevelopMentor www.develop.com [...] yes! I just test it with TC4.0-b4: - when I empty WEB-INF/lib, auto-reloading works - when I copy a jar file into WEB-INF/lib, I can not auto-reloading MyServlet which is a .class file in WEB-INF/classes thanks for your email! :-) Peace :-) Sorry, I made a mistake in the code which was supposed to fix reloading : the existence check was incorrect, which led to the problem. I fixed it in the commit I did this morning, but unfortunately, it's a post beta 4 fix. Sorry again for the trouble :-( Remy
Re: Class Reloading
On Fri, 11 May 2001, Remy Maucherat wrote: but unfortunately, it's a post beta 4 fix. This is going to turn out not to be a problem, as it happens. Tomcat 4.0-beta-4 is also subject to the ...jsp%00 bug that Marc just fixed in 3.2.2 (patch will be committed in a second). However, the more serious issue is the introspection one (I can hear Costin laughing at me from 600 miles away :-). More on that soon. Remy Craig
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core LocalStrings.properties StandardContextMapper.java
craigmcc01/05/11 16:20:12
Modified:catalina/src/share/org/apache/catalina/core
LocalStrings.properties StandardContextMapper.java
Log:
Return error 400 if the user uses invalid characters (including %00 and
%7f) in a URI. This fixes a security vulnerability, present in 4.0-b4,
that exposes JSP source code when you request:
http://localhost:8080/examples/jsp/num/numguess.jsp%00
This is the same vulnerability that Marc just patched in 3.2.2.
Revision ChangesPath
1.33 +1 -0
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/LocalStrings.properties
Index: LocalStrings.properties
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/LocalStrings.properties,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -r1.32 -r1.33
--- LocalStrings.properties 2001/05/04 05:07:07 1.32
+++ LocalStrings.properties 2001/05/11 23:20:09 1.33
@@ -67,6 +67,7 @@
standardContext.stoppingWrapper=Exception stopping Wrapper for servlet {0}
standardContext.urlDecode=Cannot URL decode request path {0}
standardContext.urlPattern.patternWarning=WARNING: URL pattern {0} must start with
a '/' in Servlet 2.3
+standardContext.urlValidate=Cannot validate URL decoded request path {0}
standardContext.wrapper.error=JSP file {0} must start with a '/'
standardContext.wrapper.warning=WARNING: JSP file {0} must start with a '/' in
Servlet 2.3
standardContext.invalidEnvEntryValue={0} environment entry has an invalid value for
specified type
1.4 +31 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContextMapper.java
Index: StandardContextMapper.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContextMapper.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- StandardContextMapper.java2001/03/30 20:44:20 1.3
+++ StandardContextMapper.java2001/05/11 23:20:10 1.4
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContextMapper.java,v
1.3 2001/03/30 20:44:20 craigmcc Exp $
- * $Revision: 1.3 $
- * $Date: 2001/03/30 20:44:20 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContextMapper.java,v
1.4 2001/05/11 23:20:10 craigmcc Exp $
+ * $Revision: 1.4 $
+ * $Date: 2001/05/11 23:20:10 $
*
*
*
@@ -85,7 +85,7 @@
* codeStandardContext/code, because it relies on internal APIs.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.3 $ $Date: 2001/03/30 20:44:20 $
+ * @version $Revision: 1.4 $ $Date: 2001/05/11 23:20:10 $
*/
public final class StandardContextMapper
@@ -204,6 +204,7 @@
// servletPath and pathInfo as decoded strings
try {
relativeURI = RequestUtil.URLDecode(relativeURI);
+validate(relativeURI);
if (debug = 1)
context.log(Decoded relativeURI=' + relativeURI + ');
} catch (Exception e) {
@@ -300,6 +301,32 @@
((HttpRequest) request).setPathInfo(pathInfo);
}
return (wrapper);
+
+}
+
+
+// Private Methods
+
+
+/**
+ * Throw an exception if the specified relative URI (assumed to be already
+ * decoded) contains any control characters. See RFC 2396, Section 2.4.3,
+ * for a discussion of why these characters are not allowed in URIs.
+ *
+ * @param relativeURI The decoded relative URI to be validated
+ *
+ * @exception IllegalArgumentException if the specified relative URI
+ * contains invalid characters
+ */
+private void validate(String relativeURI) {
+
+int n = relativeURI.length();
+for (int i = 0; i n; i++) {
+char c = relativeURI.charAt(i);
+if ((c '\u0020') || (c == '\u007f'))
+throw new IllegalArgumentException
+(sm.getString(standardContext.urlValidate, relativeURI));
+}
}
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core Constants.java
marcsaeg01/05/11 16:21:46
Modified:src/webpages Tag: tomcat_32 index.html
src/share/org/apache/tomcat/core Tag: tomcat_32
Constants.java
Log:
Updated version numbers for Tomcat 3.2.2 beta 5.
Revision ChangesPath
No revision
No revision
1.13.2.17 +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.16
retrieving revision 1.13.2.17
diff -u -r1.13.2.16 -r1.13.2.17
--- index.html2001/04/30 13:34:13 1.13.2.16
+++ index.html2001/05/11 23:21:42 1.13.2.17
@@ -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 beta 4/title
+titleTomcat v3.2.2 beta 5/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 beta 4/font/font/b
+3.2.2 beta 5/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.15 +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.14
retrieving revision 1.22.2.15
diff -u -r1.22.2.14 -r1.22.2.15
--- Constants.java2001/04/30 13:34:12 1.22.2.14
+++ Constants.java2001/05/11 23:21:44 1.22.2.15
@@ -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 beta 4;
+public static final String TOMCAT_VERSION = 3.2.2 beta 5;
public static final String JSP_NAME = JSP;
public static final String JSP_VERSION = 1.1;
Re: cvs commit:jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/coreLocalStrings.propertiesStandardContextMapper.java
[EMAIL PROTECTED] wrote: craigmcc01/05/11 16:20:12 Modified:catalina/src/share/org/apache/catalina/core LocalStrings.properties StandardContextMapper.java Log: Return error 400 if the user uses invalid characters (including %00 and %7f) in a URI. This fixes a security vulnerability, present in 4.0-b4, that exposes JSP source code when you request: http://localhost:8080/examples/jsp/num/numguess.jsp%00 [...] Shouldn't we post a security hotfix or cut a new beta release? This seems like a pretty major security flaw. ..bip
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/coreLocalStrings.propertiesStandardContextMapper.java
On Fri, 11 May 2001, Bip Thelin wrote: [EMAIL PROTECTED] wrote: craigmcc01/05/11 16:20:12 Modified:catalina/src/share/org/apache/catalina/core LocalStrings.properties StandardContextMapper.java Log: Return error 400 if the user uses invalid characters (including %00 and %7f) in a URI. This fixes a security vulnerability, present in 4.0-b4, that exposes JSP source code when you request: http://localhost:8080/examples/jsp/num/numguess.jsp%00 [...] Shouldn't we post a security hotfix or cut a new beta release? This seems like a pretty major security flaw. We will ... but this is not the only problem. I pulled the downloadable directory for beta 4. ..bip Craig
Re: Tomcat Security
On Fri, 11 May 2001, Benjamin Chad wrote: Hi, What security development still needs to be done on Tomcat? Depends on what you mean by security :-) If you're talking about authentication - we need to better integrate tomcat with auth mechanisms in the web server ( that should be part of the connector work ). If you're talking about sandboxing - testing and a lot of code review is needed For anti-hacking - review of the Static file server, maybe a clean library that would allow servers to get files without beeing tricked by OS ( like case sensitivity, etc). We have some code, but it needs cleanup, review - maybe rewrite. Also: SSL certificate auth is missing ( in 3.3 ). If you need more ideas - just let me know :-) Costin I'm in a group at university that needs to find a security software project. Cheers, Ben.
RE: problems running a servlet that uses core catalina classes
On Fri, 11 May 2001, Ted Neward wrote:
Glenn, just out of curiosity, how could someone create an administrative
web-app for controlling and administering Tomcat? (One of the things I've
been toying with was the idea of doing just such an administrative
interface--installing new webapps, restarting, viewing statistics,
monitoring the server's progress, and so on.)
In tomcat3.3 - we have the trusted attribute, that allows an web
application to:
- see all internal classes
- get a reference to the real request/context ( using an attribute to
bypass the facade )
That's how the admin/ app works.
I don't know how this is done in 4.0, I suppose they have a similar
mechanism.
Costin
Ted Neward
{.NET||Java} Instructor, DevelopMentor (http://www.develop.com)
http://www.javageeks.com/~tneward/index.html
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Glenn Nielsen
Sent: Tuesday, May 08, 2001 5:12 PM
To: [EMAIL PROTECTED]
Subject: Re: problems running a servlet that uses core catalina classes
In Tomcat 4 the core catalina classes in
servlet/lib/catalina.jar are hidden
from servlets. A servlet should use the standard Servlet 2.3 classes to
access public information for the request. Your servlet would
not be portable
across differenct servlet containers if you used internal servlet
container classes.
In addition, making those interal tomcat classes visible to web
applications
could allow the security of the servlet container and web
applications to be compromised.
Regards,
Glenn
Fabien Le Floc'h wrote:
Hello,
I am sorry to bother you. But I am trying to write a servlet
that uses some core apache classes and I have problems running it.
- If I use a war archive, tomcat does not find the tomcat
classes/servlet classes when it starts the servlet.
(ClassNoDefFound error). If I then add the catalina.jar and
servlet.jar to the classpath, I have a conflict between classes
loaded dynamically by tomcat and classes in the classpath. (More
precisely I have an object whose class is ServletWrapper but is
not an instance of ServletWrapper. This is because (I guess) the
object is created by the Tomcat classloader and it is compared
with an instance of the classpath objects),
- If I put the jar file in the common/lib directory, it finds
the servlet classes but not the tomcat classes.
- If I put the jar file in server/lib directory, it does not
load my servlet.
The only way I can make it work is to put it in the
catalina.jar file. But that is not nice at all.
Could someone help me with this?
Thank you.
Fabien Le Floc'h
P.S.: I was wondering if it was user or developer oriented...
As I want to use core Tomcat classes I thought it was developer
but maybe I am wrong. Then I apologize.
--
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
--
mod_webapp and Win32
Please find attached the following: 1. Patches to enable mod_webapp to compile and work(ish) under Windows. (mod_webapp.c.diff, pr_warp.c.diff, wa.h.diff) 2. A Visual C++ project file to be put in the connectors\apache-1.3 directory. (mod_webapp.dsp) 3. A howto compile type document. (win32.txt) 4. The pre-compiled binaries. (mod_webapp.dll, libapr.dll) The patches are required so that mod_webapp would compile and load into Apache. Once up and running it does talk to the Java but will not respond to requests. I will hopefully track down the problem soon. For the moment if someone could review these patches etc. and check them in I would be most grateful. Dave. [EMAIL PROTECTED] _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. win32.zip
cvs commit: jakarta-tomcat-4.0/connectors/lib pr_warp.c
jon 01/05/11 19:31:49 Modified:connectors/apache-1.3 mod_webapp.c connectors/include wa.h connectors/lib pr_warp.c Added: connectors WIN32.txt mod_webapp.dsp Log: added patches and files for win32 support thanks to: Dave Oxley [EMAIL PROTECTED] Note: I didn't add the binary files in what he sent to CVS... Revision ChangesPath 1.1 jakarta-tomcat-4.0/connectors/WIN32.txt Index: WIN32.txt === 1. Get and extract apr and apr-utils from http://apr.apache.org to c:\apr and c:\apr-utils (for example). 2. Build them with Visual C++. (Use the aprutils.dsw in the c:\apr-utils directory and choose to batch build everything). 3. Add the following environment variables (With paths appropriate for your system): APACHE1_HOME=C:\Program Files\Apache Group\Apache APR_HOME=C:\apr 4. Build mod_webapp.dll with Visual C++. (Use the mod_webapp.dsp in the %TOMCAT4_SRC_HOME%\connectors\apache-1.3 directory and choose to batch build everything). 5. Do the following: copy %APR_HOME%\Release\libapr.dll %APACHE1_HOME%\modules copy %TOMCAT4_SRC_HOME%\connectors\apache-1.3\Release\mod_webapp.dll %APACHE1_HOME%\modules 6. Add the following lines to %APACHE1_HOME%\conf\httpd.conf: LoadModule webapp_module modules/mod_webapp.dll WebAppConnection warpConnection warp localhost:8008 WebAppDeploy examples warpConnection /examples/ 7. Change ServerName in %APACHE1_HOME%\conf\httpd.conf and defaultHost in %TOMCAT4_HOME%\conf\server.xml to match. 8. Start Tomcat followed by Apache. 1.1 jakarta-tomcat-4.0/connectors/mod_webapp.dsp Index: mod_webapp.dsp === # Microsoft Developer Studio Project File - Name=mod_webapp - Package Owner=4 # Microsoft Developer Studio Generated Build File, Format Version 6.00 # ** DO NOT EDIT ** # TARGTYPE Win32 (x86) Dynamic-Link Library 0x0102 CFG=mod_webapp - Win32 Debug !MESSAGE This is not a valid makefile. To build this project using NMAKE, !MESSAGE use the Export Makefile command and run !MESSAGE !MESSAGE NMAKE /f mod_webapp.mak. !MESSAGE !MESSAGE You can specify a configuration when running NMAKE !MESSAGE by defining the macro CFG on the command line. For example: !MESSAGE !MESSAGE NMAKE /f mod_webapp.mak CFG=mod_webapp - Win32 Debug !MESSAGE !MESSAGE Possible choices for configuration are: !MESSAGE !MESSAGE mod_webapp - Win32 Release (based on Win32 (x86) Dynamic-Link Library) !MESSAGE mod_webapp - Win32 Debug (based on Win32 (x86) Dynamic-Link Library) !MESSAGE # Begin Project # PROP AllowPerConfigDependencies 0 # PROP Scc_ProjName # PROP Scc_LocalPath CPP=cl.exe MTL=midl.exe RSC=rc.exe !IF $(CFG) == mod_webapp - Win32 Release # PROP BASE Use_MFC 0 # PROP BASE Use_Debug_Libraries 0 # PROP BASE Output_Dir Release # PROP BASE Intermediate_Dir Release # PROP BASE Target_Dir # PROP Use_MFC 0 # PROP Use_Debug_Libraries 0 # PROP Output_Dir Release # PROP Intermediate_Dir Release # PROP Ignore_Export_Lib 0 # PROP Target_Dir # ADD BASE CPP /nologo /MT /W3 /GX /O2 /D WIN32 /D NDEBUG /D _WINDOWS /D _MBCS /D _USRDLL /D MOD_WEBAPP_EXPORTS /YX /FD /c # ADD CPP /nologo /MD /W3 /O2 /I ..\include /I $(APR_HOME)\include /I $(APACHE1_HOME)\include /D WIN32 /D NDEBUG /D _WINDOWS /D _MBCS /D _USRDLL /D MOD_WEBAPP_EXPORTS /FD /c # SUBTRACT CPP /u /YX # ADD BASE MTL /nologo /D NDEBUG /mktyplib203 /win32 # ADD MTL /nologo /D NDEBUG /mktyplib203 /win32 # ADD BASE RSC /l 0x809 /d NDEBUG # ADD RSC /l 0x409 /d NDEBUG BSC32=bscmake.exe # ADD BASE BSC32 /nologo # ADD BSC32 /nologo LINK32=link.exe # ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /machine:I386 # ADD LINK32 ApacheCore.lib libapr.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /machine:I386 /libpath:$(APR_HOME)\Release /libpath:$(APACHE1_HOME)\libexec !ELSEIF $(CFG) == mod_webapp - Win32 Debug # PROP BASE Use_MFC 0 # PROP BASE Use_Debug_Libraries 1 # PROP BASE Output_Dir Debug # PROP BASE Intermediate_Dir Debug # PROP BASE Target_Dir # PROP Use_MFC 0 # PROP Use_Debug_Libraries 1 # PROP Output_Dir Debug # PROP Intermediate_Dir Debug # PROP Ignore_Export_Lib 0 # PROP Target_Dir # ADD BASE CPP /nologo /MTd /W3 /Gm /GX /ZI /Od /D WIN32 /D _DEBUG /D _WINDOWS /D _MBCS /D _USRDLL /D MOD_WEBAPP_EXPORTS /YX /FD /GZ /c # ADD CPP /nologo /MDd /W3 /GX /ZI /Od /I ..\include /I
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardContext.java
craigmcc01/05/11 19:42:00 Modified:catalina/src/share/org/apache/catalina/core StandardContext.java Log: Initialize our character set mapper (used by response.setLocale()) at startup time, to avoid access control problems if accessed for the first time by a web app. Revision ChangesPath 1.58 +10 -4 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.57 retrieving revision 1.58 diff -u -r1.57 -r1.58 --- StandardContext.java 2001/05/04 05:30:00 1.57 +++ StandardContext.java 2001/05/12 02:41:59 1.58 @@ -1,7 +1,7 @@ /* - * $Header: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v 1.57 2001/05/04 05:30:00 craigmcc Exp $ - * $Revision: 1.57 $ - * $Date: 2001/05/04 05:30:00 $ + * $Header: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v 1.58 2001/05/12 02:41:59 craigmcc Exp $ + * $Revision: 1.58 $ + * $Date: 2001/05/12 02:41:59 $ * * * @@ -141,7 +141,7 @@ * * @author Craig R. McClanahan * @author Remy Maucherat - * @version $Revision: 1.57 $ $Date: 2001/05/04 05:30:00 $ + * @version $Revision: 1.58 $ $Date: 2001/05/12 02:41:59 $ */ public class StandardContext @@ -3177,6 +3177,9 @@ setManager(new StandardManager()); } +// Initialize character set mapper +getCharsetMapper(); + // Post work directory postWorkDirectory(); @@ -3325,6 +3328,9 @@ getName())); } } + +// Finalize our character set mapper +setCharsetMapper(null); // Normal container shutdown processing if (debug = 1)
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup Bootstrap.java
craigmcc01/05/11 20:04:12
Modified:catalina/src/share/org/apache/catalina/core
ApplicationContext.java
catalina/src/share/org/apache/catalina/startup
Bootstrap.java
Log:
Make ServletContext.getResourcePaths() work under a security manager.
Revision ChangesPath
1.24 +45 -35
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationContext.java
Index: ApplicationContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationContext.java,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- ApplicationContext.java 2001/04/26 17:23:35 1.23
+++ ApplicationContext.java 2001/05/12 03:04:08 1.24
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationContext.java,v
1.23 2001/04/26 17:23:35 craigmcc Exp $
- * $Revision: 1.23 $
- * $Date: 2001/04/26 17:23:35 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationContext.java,v
1.24 2001/05/12 03:04:08 craigmcc Exp $
+ * $Revision: 1.24 $
+ * $Date: 2001/05/12 03:04:08 $
*
*
*
@@ -75,6 +75,7 @@
import java.security.PrivilegedActionException;
import java.util.ArrayList;
import java.util.Arrays;
+import java.util.Collections;
import java.util.Enumeration;
import java.util.HashMap;
import java.util.HashSet;
@@ -111,10 +112,10 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.23 $ $Date: 2001/04/26 17:23:35 $
+ * @version $Revision: 1.24 $ $Date: 2001/05/12 03:04:08 $
*/
-public final class ApplicationContext
+public class ApplicationContext
implements ServletContext {
@@ -176,6 +177,25 @@
}
+
+protected class PrivilegedGetResourcePaths
+implements PrivilegedAction {
+
+private String path;
+private DirContext resources;
+
+PrivilegedGetResourcePaths(DirContext resources, String path) {
+this.resources = resources;
+this.path = path;
+}
+
+public Object run() {
+return (getResourcePathsInternal(resources, path));
+}
+
+}
+
+
protected class PrivilegedLogMessage
implements PrivilegedAction {
@@ -625,53 +645,43 @@
/**
- * Return a Set containing the resource paths of all resources defined
- * within this web application. Each path will be a String starting with
- * a / character. The returned set is immutable.
+ * Return a Set containing the resource paths of resources member of the
+ * specified collection. Each path will be a String starting with
+ * a / character. The returned set is immutable.
+ *
+ * @param path Collection path
*/
-public Set getResourcePaths() {
+public Set getResourcePaths(String path) {
-ResourceSet set = new ResourceSet();
DirContext resources = context.getResources();
-if (resources == null) {
-set.setLocked(true);
-return (set);
-}
-
-try {
-listPaths(set, resources, );
-} catch (NamingException e) {
-// Ignore
+if (resources != null) {
+if (System.getSecurityManager() != null) {
+PrivilegedAction dp =
+new PrivilegedGetResourcePaths(resources, path);
+return ((Set) AccessController.doPrivileged(dp));
+} else {
+return (getResourcePathsInternal(resources, path));
+}
}
-
-set.setLocked(true);
-return (set);
+return (null);
}
/**
- * Return a Set containing the resource paths of resources member of the
- * specified collection. Each path will be a String starting with
- * a / character. The returned set is immutable.
- *
+ * Internal implementation of getResourcesPath() logic.
+ *
+ * @param resources Directory context to search
* @param path Collection path
*/
-public Set getResourcePaths(String path) {
+private Set getResourcePathsInternal(DirContext resources, String path) {
ResourceSet set = new ResourceSet();
-DirContext resources = context.getResources();
-if (resources == null) {
-set.setLocked(true);
-return (set);
-}
-
try {
Re: Class Reloading
On Fri, 11 May 2001, Craig R. McClanahan wrote: Tomcat 4.0-beta-4 is also subject to the ...jsp%00 bug that Marc just fixed in 3.2.2 (patch will be committed in a second). However, the more serious issue is the introspection one (I can hear Costin laughing at me from 600 miles away :-). More on that soon. Not quite. The introspection problem is not very serious - it doesn't work if sandboxing is enabled ( at least from what I know - if it works then it's a very serious VM bug ). If sandboxing is not enabled - a servlet can do much worse than accessing internal objects - it has read access to all other applications and all the permisions in the world ( read to all files that tomcat can read, write in other application's work dir, or even change anything in most cases ). Of course, even with sandboxing it may be possible to find ways to get to the internal objects ( just look at all the applet security issues in the browsers ), and that would be really serious. But I couldn't find the trick yet ( and it's not that important for me since I also have the facades). And I'm not sure I'll laugh when someone finds the trick. Costin
Re: Class Reloading
On Fri, 11 May 2001 [EMAIL PROTECTED] wrote: On Fri, 11 May 2001, Craig R. McClanahan wrote: Tomcat 4.0-beta-4 is also subject to the ...jsp%00 bug that Marc just fixed in 3.2.2 (patch will be committed in a second). However, the more serious issue is the introspection one (I can hear Costin laughing at me from 600 miles away :-). More on that soon. Not quite. The introspection problem is not very serious - it doesn't work if sandboxing is enabled ( at least from what I know - if it works then it's a very serious VM bug ). It doesn't work if you start Tomcat 4.0 with a security manager. That's what I'm cleaning up, because it's the right long term direction. But we're also going to add facades for those who want to run without a security manager installed. If sandboxing is not enabled - a servlet can do much worse than accessing internal objects - it has read access to all other applications and all the permisions in the world ( read to all files that tomcat can read, write in other application's work dir, or even change anything in most cases ). Of course, even with sandboxing it may be possible to find ways to get to the internal objects ( just look at all the applet security issues in the browsers ), and that would be really serious. But I couldn't find the trick yet ( and it's not that important for me since I also have the facades). And I'm not sure I'll laugh when someone finds the trick. Costin Craig
cvs commit: jakarta-tomcat-4.0/connectors configure.in
jon 01/05/11 21:35:58
Modified:connectors configure.in
Log:
a *vastly* improved configure.in script. some of it was lifted from the
old jserv code (imagine that)...the rest i came up with on my own.
added: better checking for APR (including libraries)
changed: --with-apache to --with-apxs to better reflect
actual functionality
added: checking for Perl since apxs depends on perl
added: auto discovery of apxs in the users path
modified: ${TEST} functionality is now more cross platform
modified: method to find ar
Revision ChangesPath
1.4 +67 -41jakarta-tomcat-4.0/connectors/configure.in
Index: configure.in
===
RCS file: /home/cvs/jakarta-tomcat-4.0/connectors/configure.in,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- configure.in 2001/05/10 06:06:30 1.3
+++ configure.in 2001/05/12 04:35:56 1.4
@@ -57,7 +57,8 @@
dnl -
dnl Author Pier Fumagalli mailto:[EMAIL PROTECTED]
-dnl Version $Id: configure.in,v 1.3 2001/05/10 06:06:30 pier Exp $
+dnl Author Jon S. Stevens mailto:[EMAIL PROTECTED]
+dnl Version $Id: configure.in,v 1.4 2001/05/12 04:35:56 jon Exp $
dnl -
dnl -
@@ -71,32 +72,40 @@
AC_PROG_CC
AC_PROG_RANLIB
-dnl -
-dnl Check out where AR is
-dnl -
-AC_CHECK_PROG(AR,ar,ar,)
-if test -z $AR ; then
- AC_MSG_ERROR([Cannot find ar])
-fi
+AC_PATH_PROG(AR,ar,$PATH)dnl
+AC_PATH_PROG(TEST,test,$PATH)dnl
+
AC_SUBST(AR)
+AC_SUBST(TEST)
dnl -
dnl Process the --with-apr=... command line argument (required)
dnl -
AC_MSG_CHECKING([APR directory])
AC_ARG_WITH(apr,
- [ --with-apr=DIR where the compiled APR sources can be found
[required]],
+ [ --with-apr=DIR where the APR installation can be found [required]],
APRDIR=$withval,
APRDIR=)
-if test -z $APRDIR ; then
+if ${TEST} -z $APRDIR ; then
AC_MSG_ERROR([Required command line argument \--with-apr=...\ not specified])
fi
-if ! test -d $APRDIR ; then
+if ${TEST} ! -d $APRDIR ; then
AC_MSG_ERROR([Invalid APR directory \$APRDIR\ specified])
fi
-if ! test -f $APRDIR/include/apr.h ; then
+if ${TEST} ! -f $APRDIR/include/apr.h ; then
AC_MSG_ERROR([No APR headers in \$APRDIR\])
fi
+for i in $APRDIR/lib/libapr*
+do
+if ${TEST} -f $i ; then
+has_apr_lib = true
+break
+fi
+done
+if ${TEST} ${has_apr_lib} ; then
+ AC_MSG_ERROR([No APR libraries in \$APRDIR\])
+fi
+
CURDIR=`pwd`
cd $APRDIR
APRDIR=`pwd`
@@ -109,35 +118,52 @@
AC_SUBST(TGTDIRS)
dnl -
-dnl Process the --with-apache=... command line argument
+dnl Process the --with-apxs=FILE... command line argument
dnl -
-AC_MSG_CHECKING([Apache HTTPd 1.3.x])
-AC_ARG_WITH(apache,
- [ --with-apache=DIR where the Apache 1.3.x APXS utility can be found],
- TMPDIR=$withval,
- TMPDIR=)
-if ! test -z $TMPDIR ; then
- if ! test -d $TMPDIR ; then
- AC_MSG_ERROR([Invalid Apache 1.3.x directory \$TMPDIR\ specified])
- fi
- if ! test -f $TMPDIR/apxs ; then
- AC_MSG_ERROR([Cannot locate \apxs\ in \$TMPDIR\])
- fi
-
- CURDIR=`pwd`
- cd $TMPDIR
- TMPDIR=`pwd`
- cd $CURDIR
- APXS=$TMPDIR/apxs
- AC_MSG_RESULT($APXS)
- AC_SUBST(APXS)
-
- TGTDIRS=$TGTDIRS apache-1.3
- AC_MSG_RESULT([setting target directories to \$TGTDIRS\])
- AC_SUBST(TGTDIRS)
-else
+AC_ARG_WITH(apxs,
+[ --with-apxs[=FILE]Build shared Apache module. FILE is the optional
+ pathname to the Apache apxs tool; defaults to apxs.],
+[
+case ${withval} in
+y | yes | true) find_apxs=true ;;
+n | no | false) find_apxs=false ;;
+*) find_apxs=true ;;
+esac
+
+if ${TEST} ${find_apxs} ; then
+AC_MSG_RESULT([need to check for Perl first, apxs depends on it...])
+AC_PATH_PROG(PERL,perl,$PATH)dnl
+
+if ${TEST} ${find_apxs} ; then
+AC_PATH_PROG(APXS_CMD,apxs,$PATH)dnl
+else
+
Re: Class Reloading
On Fri, 11 May 2001, Craig R. McClanahan wrote: The introspection problem is not very serious - it doesn't work if sandboxing is enabled ( at least from what I know - if it works then it's a very serious VM bug ). It doesn't work if you start Tomcat 4.0 with a security manager. That's what I'm cleaning up, because it's the right long term direction. But we're also going to add facades for those who want to run without a security manager installed. If the security manager is not used everything has AllPermissions - the fact that someone can access the internal objects is quite small compared with the fact that it could call System.exit() and read/change any file that tomcat has access to. Anyway: +1 on facades :-) Costin
cvs commit: jakarta-tomcat-4.0/connectors buildconf.sh README.txt configure
jon 01/05/11 21:42:34 Modified:connectors README.txt Added: connectors buildconf.sh Removed: connectors configure Log: added configure notes removed configure and added a buildconf.sh. you shouldn't check configure scripts into cvs pier. Revision ChangesPath 1.3 +8 -3 jakarta-tomcat-4.0/connectors/README.txt Index: README.txt === RCS file: /home/cvs/jakarta-tomcat-4.0/connectors/README.txt,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- README.txt2001/05/10 21:15:10 1.2 +++ README.txt2001/05/12 04:42:31 1.3 @@ -27,6 +27,11 @@ Configuration: -- -Simply issue a ./configure --help to see all the supported AutoConf parameters. -APR is required and must be compiled and installed before trying to compile the -library. APR can be found at http://apr.apache.org/ +If you are building this from CVS, you will need to first execute +./buildconf.sh to build the configure script. This assumes that you have +autoconf 2.13 installed on your machine already. + +Simply issue a ./configure --help to see all the supported AutoConf +parameters. Example: + +./configure --with-apr=/usr/local --with-apxs 1.1 jakarta-tomcat-4.0/connectors/buildconf.sh Index: buildconf.sh === #!/bin/sh # @author Jon S. Stevens [EMAIL PROTECTED] # # This script is used to build the configure script from # the configure.in. If you check these sources out of CVS, # you will need to execute this script first. autoconf
cvs commit: jakarta-tomcat-4.0/connectors/lib .cvsignore
jon 01/05/11 21:54:52 Added: connectors .cvsignore connectors/apache-1.3 .cvsignore connectors/lib .cvsignore Log: added .cvsignore files Revision ChangesPath 1.1 jakarta-tomcat-4.0/connectors/.cvsignore Index: .cvsignore === Makefile Makedefs configure config.cache config.log config.status 1.1 jakarta-tomcat-4.0/connectors/apache-1.3/.cvsignore Index: .cvsignore === Makefile 1.1 jakarta-tomcat-4.0/connectors/lib/.cvsignore Index: .cvsignore === Makefile
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core ApplicationDispatcher.java ApplicationHttpRequest.java ApplicationHttpResponse.java
craigmcc01/05/11 21:56:55
Modified:catalina/src/share/org/apache/catalina/core
ApplicationDispatcher.java
ApplicationHttpRequest.java
ApplicationHttpResponse.java
Log:
Add an innocuous public method to each class for unit tests to validate
that access is prevented.
Revision ChangesPath
1.16 +24 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java
Index: ApplicationDispatcher.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- ApplicationDispatcher.java2001/05/04 03:41:10 1.15
+++ ApplicationDispatcher.java2001/05/12 04:56:54 1.16
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java,v
1.15 2001/05/04 03:41:10 craigmcc Exp $
- * $Revision: 1.15 $
- * $Date: 2001/05/04 03:41:10 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java,v
1.16 2001/05/12 04:56:54 craigmcc Exp $
+ * $Revision: 1.16 $
+ * $Date: 2001/05/12 04:56:54 $
*
*
*
@@ -98,7 +98,7 @@
* codejavax.servlet.ServletResponseWrapper/code.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.15 $ $Date: 2001/05/04 03:41:10 $
+ * @version $Revision: 1.16 $ $Date: 2001/05/12 04:56:54 $
*/
final class ApplicationDispatcher
@@ -203,6 +203,13 @@
/**
+ * Descriptive information about this implementation.
+ */
+private static final String info =
+org.apache.catalina.core.ApplicationDispatcher/1.0;
+
+
+/**
* The servlet name for a named dispatcher.
*/
private String name = null;
@@ -238,6 +245,19 @@
* or included.
*/
private Wrapper wrapper = null;
+
+
+// - Properties
+
+
+/**
+ * Return the descriptive information about this implementation.
+ */
+public String getInfo() {
+
+return (this.info);
+
+}
// - Public Methods
1.6 +21 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationHttpRequest.java
Index: ApplicationHttpRequest.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationHttpRequest.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- ApplicationHttpRequest.java 2001/05/02 20:44:19 1.5
+++ ApplicationHttpRequest.java 2001/05/12 04:56:54 1.6
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationHttpRequest.java,v
1.5 2001/05/02 20:44:19 craigmcc Exp $
- * $Revision: 1.5 $
- * $Date: 2001/05/02 20:44:19 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationHttpRequest.java,v
1.6 2001/05/12 04:56:54 craigmcc Exp $
+ * $Revision: 1.6 $
+ * $Date: 2001/05/12 04:56:54 $
*
*
*
@@ -93,7 +93,7 @@
* keep these two classes in synchronization when making changes!
*
* @author Craig R. McClanahan
- * @version $Revision: 1.5 $ $Date: 2001/05/02 20:44:19 $
+ * @version $Revision: 1.6 $ $Date: 2001/05/12 04:56:54 $
*/
class ApplicationHttpRequest extends HttpServletRequestWrapper {
@@ -144,6 +144,13 @@
/**
+ * Descriptive information about this implementation.
+ */
+protected static final String info =
+org.apache.catalina.core.ApplicationHttpRequest/1.0;
+
+
+/**
* The request parameters for this request. This is initialized from the
* wrapped request, but updates are allowed.
*/
@@ -385,6 +392,16 @@
// Package Methods
+
+
+/**
+ * Return descriptive information about this implementation.
+ */
+public String getInfo() {
+
+return (this.info);
+
+}
/**
1.2 +21 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationHttpResponse.java
Index: ApplicationHttpResponse.java
===
RCS file:
cvs commit: jakarta-tomcat-4.0/tester/web/WEB-INF web.xml
craigmcc01/05/11 21:58:27
Modified:tester/src/bin tester.xml
tester/web/WEB-INF web.xml
Added: tester/src/tester/org/apache/tester Reflection01.java
Log:
Add a unit test that attempts to access public methods of the servlet API
objects that are exposed, via Java reflection. To test, run:
$CATALINA_HOME/tester.sh Internals
Currently, this test passes (i.e. inappropriate access is blocked) when
Tomcat is started with a security manager.
Revision ChangesPath
1.45 +18 -0 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.44
retrieving revision 1.45
diff -u -r1.44 -r1.45
--- tester.xml2001/05/10 23:57:05 1.44
+++ tester.xml2001/05/12 04:58:27 1.45
@@ -332,6 +332,24 @@
/target
+ target name=Internals
+
+
+!-- == Access Internals Via Reflection === --
+
+tester host=${host} port=${port} protocol=${protocol}
+ request=${context.path}/Reflection01
+ debug=${debug}
+ outContent=Reflection01 PASSED/
+
+tester host=${host} port=${port} protocol=${protocol}
+ request=${context.path}/WrappedReflection01
+ debug=${debug}
+ outContent=Reflection01 PASSED/
+
+ /target
+
+
target name=Jndi
!-- == JNDI Naming Context === --
1.1
jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/Reflection01.java
Index: Reflection01.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. *
* *
* 2. Redistributions in binary form must reproduce the above copyright *
*notice, this list of conditions and the following disclaimer in the *
*documentation and/or other materials provided with the distribution. *
* *
* 3. The end-user documentation included with the redistribution, if any, *
*must include the following acknowlegement: *
* *
* This product includes software developed by the Apache Software *
*Foundation http://www.apache.org/. *
* *
*Alternately, this acknowlegement may appear in the software itself, if *
*and wherever such third-party acknowlegements normally appear. *
* *
* 4. The names The Jakarta Project, Tomcat, and Apache Software *
*Foundation must not be used to endorse or promote products derived *
*from this software without prior written permission. For written *
*permission, please contact [EMAIL PROTECTED].*
* *
* 5. Products derived from this software may not be called Apache nor may *
*Apache appear in their names without prior written permission of the *
*Apache Software Foundation.*
* *
* THIS SOFTWARE IS PROVIDED AS IS AND ANY EXPRESSED OR IMPLIED WARRANTIES *
* INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY *
* AND FITNESS FOR A PARTICULAR PURPOSE
[Proposal] Default Encoding option for JSP/Tomcat in server.xml or web.xml
I read some code in catalina jasper, and found that: There is a setCharacterEncoding() for servlet request now; but I greped all Tomcat code, and found nowhere called it. It means, by default, Tomcat use a default encoding of '8859_1'. There is no option in server.xml/web.xml for tomcat to set a default encoding for a context/container(or whatever) to use a default encoding other than '8859_1'. Also, the alternative (JSP compiling) encoding option in conf/web.xml for jasper seems failed to work (at least, failed for JSP pages in big5 encoding). When there is no '% page contentType=text/html; charset=xxx %' in a JSP, jasper use '8859_1' as its the JSP's default encoding, oops. We are working on a product deploying JSP pages which targeting multiple markets in Japan, Taiwan, and probably China mainland. Sure, when we maintain our JSP pages (initially show messages in english, but should be able to handle input in localized character encodings), we don't like to maintain 3 versions of JSP pages with each version of them differed only in the page directive: '% page contentType=text/html; charset=xxx %' And, I found Tomcat does byte-char typecast first and then char-byte typecast back before converting bytes into a java string. Unfortunately, because the character encoding is never changed from '8859_1' to some other customized one assigned in somewhere other than in code. This seems to work at first, as long as you don't treat strings read from GET/POST parameters as Unicode strings, because they are NOT VALID UNICODE STRINGS. Web output generated from servlets/JSP pages may be right, simply because contents in these NOT VALID UNICODE STRINGS are converted into bytes again by simply doing char-byte typecasting. Oops! It goes too far. People can't just do internalization/localization in such a garbage in garbage out solution. Maybe it looks right both in the input/output ends, if you simply GET/POST something and out.println(xxx.getParameter(foo)). But if you are doing something serious with character encodings other than 8859_1 (if Big5, GB2312 and Shift_JIS are for localization and not serious enough, how about utf-8 character encoding? indeed, Tomcat garbaged GET/POST inputs in utf-8 encoding), you must handle this problem. Personally, I code my own connector to aim this problem. The connector works as a bridge from Sun's Brazil web server (a light-weight web server in 100% java), Brazil HTTP request objects are passed directly into the connector (rather than via some socket protocl), such that the connector does configure servlets/JSP pages to use a default encoding given by properties set in the Brazil configuration file, and it does URL encoding check against raw strings input in GET/POST parameters in localized character encoding, as to make sure Tomcat does right character conversions for these parameters. (the %xx URL decoding code in parseParameters() in Tomcat 4 beta 3/4 works fine, but the byte-char/char-byte code drops some characters) But there is no way to modify jasper's default compiling encoding, except modify its code.
cvs commit: jakarta-tomcat-connectors/jk - Imported sources
seguin 01/05/11 22:52:42 Log: initial checkin of an ajp13 connector for tomcat 4 Status: Vendor Tag: jakarta Release Tags: ajp-tomcat4-connector N jakarta-tomcat-connectors/jk/build.xml N jakarta-tomcat-connectors/jk/README.txt N jakarta-tomcat-connectors/jk/src/java/org/apache/ajp/Ajp13Packet.java N jakarta-tomcat-connectors/jk/src/java/org/apache/ajp/tomcat4/Ajp13.java N jakarta-tomcat-connectors/jk/src/java/org/apache/ajp/tomcat4/Ajp13Connector.java N jakarta-tomcat-connectors/jk/src/java/org/apache/ajp/tomcat4/Ajp13InputStream.java N jakarta-tomcat-connectors/jk/src/java/org/apache/ajp/tomcat4/Ajp13Logger.java N jakarta-tomcat-connectors/jk/src/java/org/apache/ajp/tomcat4/Ajp13OutputStream.java N jakarta-tomcat-connectors/jk/src/java/org/apache/ajp/tomcat4/Ajp13Processor.java N jakarta-tomcat-connectors/jk/src/java/org/apache/ajp/tomcat4/Ajp13Request.java N jakarta-tomcat-connectors/jk/src/java/org/apache/ajp/tomcat4/Ajp13Response.java N jakarta-tomcat-connectors/jk/src/java/org/apache/ajp/tomcat4/Constants.java N jakarta-tomcat-connectors/jk/src/java/org/apache/ajp/tomcat4/LocalStrings.properties No conflicts created by this import
ajp13 connector for tomcat4
as you probably noticed, i checked in my ajp13 connector for tomcat 4. it's in need of some refactoring (but does work, except for load-balancing), but i wanted to at least get it checked so others will have access to it. there are some (minimal) instructions for using this connector in jakarta-tomcat-connectors/jk/README.txt.
cvs commit: jakarta-tomcat-connectors/jk/src/java/org/apache/ajp/tomcat4 Ajp13Connector.java
seguin 01/05/11 23:16:40
Modified:jk/src/java/org/apache/ajp/tomcat4 Ajp13Connector.java
Log:
add setters/getters for redirect port and enabling dns lookup.
Revision ChangesPath
1.2 +48 -4
jakarta-tomcat-connectors/jk/src/java/org/apache/ajp/tomcat4/Ajp13Connector.java
Index: Ajp13Connector.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/src/java/org/apache/ajp/tomcat4/Ajp13Connector.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- Ajp13Connector.java 2001/05/12 05:52:40 1.1
+++ Ajp13Connector.java 2001/05/12 06:16:39 1.2
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-connectors/jk/src/java/org/apache/ajp/tomcat4/Ajp13Connector.java,v
1.1 2001/05/12 05:52:40 seguin Exp $
- * $Revision: 1.1 $
- * $Date: 2001/05/12 05:52:40 $
+ * $Header:
/home/cvs/jakarta-tomcat-connectors/jk/src/java/org/apache/ajp/tomcat4/Ajp13Connector.java,v
1.2 2001/05/12 06:16:39 seguin Exp $
+ * $Revision: 1.2 $
+ * $Date: 2001/05/12 06:16:39 $
*
*
*
@@ -92,7 +92,7 @@
* Implementation of an Ajp13 connector.
*
* @author Kevin Seguin
- * @version $Revision: 1.1 $ $Date: 2001/05/12 05:52:40 $
+ * @version $Revision: 1.2 $ $Date: 2001/05/12 06:16:39 $
*/
@@ -160,6 +160,16 @@
/**
+ * redirect port.
+ */
+private int redirectPort = -1;
+
+/**
+ * enable DNS lookups.
+ */
+private boolean enableLookups = false;
+
+/**
* The lifecycle event support for this component.
*/
protected LifecycleSupport lifecycle = new LifecycleSupport(this);
@@ -415,6 +425,40 @@
}
+/**
+ * Return the enable DNS lookups flag.
+ */
+public boolean getEnableLookups() {
+return this.enableLookups;
+}
+
+/**
+ * Set the enable DNS lookups flag.
+ *
+ * @param enableLookups The new enable DNS lookups flag value
+ */
+public void setEnableLookups(boolean enableLookups) {
+this.enableLookups = enableLookups;
+}
+
+/**
+ * Return the port number to which a request should be redirected if
+ * it comes in on a non-SSL port and is subject to a security constraint
+ * with a transport guarantee that requires SSL.
+ */
+public int getRedirectPort() {
+return this.redirectPort;
+}
+
+
+/**
+ * Set the redirect port number.
+ *
+ * @param redirectPort The redirect port number (non-SSL to SSL)
+ */
+public void setRedirectPort(int redirectPort) {
+this.redirectPort = redirectPort;
+}
/**
* Return the server socket factory used by this Container.
[ANNOUNCEMENT] Tomcat 3.2.2 beta 5 released
I am pleased to announce that the Tomcat 3.2.2 beta 5 release is now available for download at http://jakarta.apache.org/builds/tomcat/release/v3.2.2-beta-5 The beta 5 release fixes a security problem that caused a URL such as http://localhost:8080/examples/jsp/num/numguess.jsp%00 to return the JSP source text on some platforms. If you are using any previous beta release of Tomcat 3.2.2 please upgrade to beta 5 as soon as possible. The release notes file in src/doc/readme covers the details of the Tomcat 3.2.2 release. Marc A. Saegesser
