DO NOT REPLY [Bug 3733] - session serialization problem
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3733. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3733 session serialization problem --- Additional Comments From [EMAIL PROTECTED] 2001-09-19 23:45 --- Created an attachment (id=583) this patch should hopefully fix the problem...
DO NOT REPLY [Bug 3733] - session serialization problem
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3733. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3733 session serialization problem --- Additional Comments From [EMAIL PROTECTED] 2001-09-19 23:47 --- the patch that i just attached fixes the problem. when i force a reload, the stack traces no longer print out. however, the only problem with this is that the init() method on the servlet still doesn't get called at this point in time so i had to set the !-- Load this servlet at server startup time -- load-on-startup5/load-on-startup for the servlet in the web.xml file. this is an ok solution, but it should be documented that any servlet that needs reloading has the load-on-startup set. -jon
DO NOT REPLY [Bug 3740] New: - simple javabeans problem
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3740. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3740 simple javabeans problem Summary: simple javabeans problem Product: Tomcat 4 Version: 4.0 Final Platform: Other OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] hi, I tried a very simple javabean like this but failed(this example from wrox book:professional jsp, first edition): jsp:useBean id=mparam scope=session class=java.lang.String This is used to initialize the bean... /jsp:useBean html body Hello World ! /body /html tc4 just output htmlbody/body/html, nothing else.
DO NOT REPLY [Bug 3741] New: - custom tag support
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3741. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3741 custom tag support Summary: custom tag support Product: Tomcat 4 Version: 4.0 Final Platform: Other OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Webapps AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] hi, I have test custom tag from professional jsp, first edition of wrox book, but failed with a very simple custom tag. In fact, I failed to pass all custom tag support in Chapter 8 of this book. Please check what has happened? thanks!
Re: TC 3.3: Form authentication vs. Application reloading
Bojan Smojver wrote: Just playing with Form authentication in TC 3.3. Have two Velocity pages that are doing the authentication with a JDBC Realm (for that context only). When Tomcat starts, all is fine. I get authenticated (or not) depending on username/password combination I supply. Subsequent visits to the same page do not require additional authentication. Excellent! If I update the application (automatic reloading is enabled) and attempt to hit the same page again, I get prompted for new authentication. Cool. But although I specify the correct username/password combination, I can't log in. Is this something that happens by design or am I looking at a possible bug? It seems that context's JDBCRealm does not get hooked into Interceptors when the context reloads. These are the relevant interceptors first time around (first three from server.xml, fourth from apps-*.xml): -- Auth interceptor is: org.apache.tomcat.modules.config.PathSetter@ed8b59e Auth interceptor is: org.apache.tomcat.modules.config.ServerXmlReader@2c72759e Auth interceptor is: org.apache.tomcat.modules.aaa.CredentialsInterceptor@5393359e Auth interceptor is: org.apache.tomcat.modules.aaa.JDBCRealm@7b08b59d -- and this is after the reload (only the ones from server.xml, the stuff from apps-*xml didn't show up this time): -- Auth interceptor is: org.apache.tomcat.modules.config.PathSetter@ed8b59e Auth interceptor is: org.apache.tomcat.modules.config.ServerXmlReader@2c72759e Auth interceptor is: org.apache.tomcat.modules.aaa.CredentialsInterceptor@5393359e -- These things are printed out by me from getRemoteUser() method in Request.java. Just need to find where those things get hooked and we'll be laughing... Just to bounce the validity of it against someone with more experience, this is my apps-*.xml file: -- ?xml version=1.0 encoding=ISO-8859-1? Server Host name=www.dev.dev Context path=/ docBase=/home/httpd/html/dev.dev JDBCRealm debug=99 driverName=org.postgresql.Driver connectionURL=jdbc:postgresql:dev connectionName=dev connectionPassword=developer digest=MD5 userTable=users userNameCol=username userCredCol=password userRoleTable=usersroles roleNameCol=rolename / /Context /Host /Server -- Back to trenches now... Bojan
DO NOT REPLY [Bug 3741] - custom tag support
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3741. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3741 custom tag support --- Additional Comments From [EMAIL PROTECTED] 2001-09-20 00:22 --- Created an attachment (id=585) example custom tag not supported
Anyone solve the cache problem in Tomcat already ?
I need to restart tomcat everytime after i change my servlet program even I added reloadable=true in serevr.xml Anyone solve this problem ? please tell me thanks /* Kenny Ma [EMAIL PROTECTED] */
DO NOT REPLY [Bug 3741] - custom tag support
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3741. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3741 custom tag support --- Additional Comments From [EMAIL PROTECTED] 2001-09-20 00:51 --- In the attachment, the location of the tld file within the web application does not match the location specified in the web.xml file. (The locations do match in the projsp.war file in the code download for the book, even if my colleague who put the download together decided to place the tlds in an unusual location.)
DO NOT REPLY [Bug 3733] - session serialization problem
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3733. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3733 session serialization problem --- Additional Comments From [EMAIL PROTECTED] 2001-09-20 01:01 --- Thanks for the analysis. The lifecycle is relatively easy to figure out by looking at StandardContext.start. I'm -1 for the patch. We can't init or load a servlet before the supporting components (logger, context, servlet context) are created and / or started. This is not a spec issue since the spec doesn't say anything about this. As you point out, it's a special case anyway, since only init on startup servlets can have a chance to behave like that. I also have no idea how it can be fixed, except if we change the initialization of the manager (and load the serialized session in a post-start method). So I vote WONTFIX (I'll let Craig close the bug if he approves), although it's more CANTFIX than WONTFIX.
DO NOT REPLY [Bug 3733] - session serialization problem
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3733. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3733 session serialization problem --- Additional Comments From [EMAIL PROTECTED] 2001-09-20 01:06 --- Well, I beg to differ about CANTFIX or WONTFIX. This is a fundamental problem with the Servlet Spec then. I'm going to post to the JSR-053 list about this and see what other containers behavior is. If it is the case that others implement this properly, then I think that Catalina should be fixed to follow what the other containers are doing. I understand that it is a fundamental problem within Catalina to fix it. It isn't an easy fix, but I really think that it needs to be done because what we are doing is not outside of the realm of correctness. :-) -jon
DO NOT REPLY [Bug 3733] - session serialization problem
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3733. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3733 session serialization problem --- Additional Comments From [EMAIL PROTECTED] 2001-09-20 01:10 --- let me also point out that my patch is working perfectly for me. i haven't had any problems with it.
DO NOT REPLY [Bug 3733] - session serialization problem
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3733. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3733 session serialization problem --- Additional Comments From [EMAIL PROTECTED] 2001-09-20 01:31 --- The patch would cause problems in some specific situations, not in the general case. If it turns out we need to fix that issue because it's a spec compliance bug, we'll need a better fix. I agree we should ask the Servlet API expert group on the subject.
DO NOT REPLY [Bug 3581] - Ctx() : Error creating validation mark - java.io.FileNotFoundException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3581. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3581 Ctx() : Error creating validation mark - java.io.FileNotFoundException --- Additional Comments From [EMAIL PROTECTED] 2001-09-20 01:38 --- This tomcat was installed on a box where we test new developments -- therefore I prefer to be paranoïd concerning what traces the previous versions may have left in work Anyway, thanks a lot
Tomcat RPM polls
Hi to all, I'd like to have the opinion of Tomcat RPMS users about some points since I'm working on enhanced RPMs : 1) Do you want tomcat to be changed to run as nobody instead of root ? 2) Do you want tomcat to be enabled by default, ie having it active after installation ? 3) Do you want the config stuff to be moved from /var/tomcat/conf to : /etc/tomcat/conf (mimic Apache httpd server conf) /etc/tomcat/ 4) Do you want the webapp stuff moved to /var/www/webapps ? 5) Do you want the log stuff moved to /var/log/tomcat ? Thanks for your replies - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
RE: Tomcat RPM polls
1) Do you want tomcat to be changed to run as nobody instead of root ? Yes 2) Do you want tomcat to be enabled by default, ie having it active after installation ? Yes 3) Do you want the config stuff to be moved from /var/tomcat/conf to : Yes (but suportting --prefix too?) /etc/tomcat/conf (mimic Apache httpd server conf) /etc/tomcat/ 4) Do you want the webapp stuff moved to /var/www/webapps ? Yes (but suportting --prefix too?) 5) Do you want the log stuff moved to /var/log/tomcat ? Yes (but suportting --prefix too? and to to daemon.log?) Thanks for your replies This message and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. No confidentiality or privilege is waived or lost by any wrong transmission. If you have received this message in error, please immediately destroy it and kindly notify the sender by reply email. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Opinions, conclusions and other information in this message that do not relate to the official business of Newknow shall be understood as neither given nor endorsed by it.
DO NOT REPLY [Bug 3743] New: - double slash bypasses BASIC authentication
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3743. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3743 double slash bypasses BASIC authentication Summary: double slash bypasses BASIC authentication Product: Tomcat 3 Version: 3.2.1 Final Platform: PC URL: http://localhost:8080/admin//contextAdmin/contextAdmin.h tml OS/Version: Windows NT/2K Status: UNCONFIRMED Severity: Normal Priority: Other Component: Auth AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When you click on 'Context Admin' from http://localhost:8080/admin/index.html, you are prompted with a username/password challenge. To bypass this check, simply enter http://localhost:8080/admin//contextAdmin/contextAdmin.html
Re: Anyone solve the cache problem in Tomcat already ?
At 15:49 20/09/2001 +0800, you wrote: I need to restart tomcat everytime after i change my servlet program even I added reloadable=true in serevr.xml reloadable=true if for jsp, unfortunately, you can not reload servelt or webapp that should be a great features to add, meanwhile I personally was maze into the 3.3 code when I look into it, so... Anyone solve this problem ? please tell me thanks /* Kenny Ma [EMAIL PROTECTED] */
Re: Anyone solve the cache problem in Tomcat already ?
oh..that's is a bad news for me.. If tomcat cant reload servlet.. It is very troblemsome when I develop servlet application At 15:49 20/09/2001 +0800, you wrote: I need to restart tomcat everytime after i change my servlet program even I added reloadable=true in serevr.xml reloadable=true if for jsp, unfortunately, you can not reload servelt or webapp that should be a great features to add, meanwhile I personally was maze into the 3.3 code when I look into it, so... Anyone solve this problem ? please tell me thanks /* Kenny Ma [EMAIL PROTECTED] */ /* Kenny Ma [EMAIL PROTECTED] */
DO NOT REPLY [Bug 3745] New: - Http10Interceptor hangs on PUT without Content-Length
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3745.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3745
Http10Interceptor hangs on PUT without Content-Length
Summary: Http10Interceptor hangs on PUT without Content-Length
Product: Tomcat 3
Version: 3.3 Beta 2
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Severity: Major
Priority: Other
Component: Connectors
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
When a PUT request has no Content-Length header, tomcat hangs
on HttpServletRequest.getInputStream.read() as it will forever
return 0 and never -1.
The comment in ServletInputStreamFacade (see extract below) indicates
that this can only happen in chunked encoding. This is a wrong assumpation
as chunked encoding is only available in HTTP/1.1. In HTTP/1.0 the
end of the message body can be indicated by closing the client side
of the connection/socket. This is the behaviour working in Tomcat 3.2.x.
Returning 0 results from the interplay between the following code extracts:
In Lines 233-235 of Http10Interceptor.java
public int doRead(byte[] b, int off, int len) throws IOException {
if( available = 0 )
return 0;
In ServletInputStreamFacade.java, lines 107-119:
if (limit == -1) {
// Ask the adapter for more data. We are in the 'no content-length'
// case - i.e. chunked encoding ( acording to http spec CL is
required
// for everything else.
int rd=reqA.doRead();
if( rd0 ) {
limit=0; // no more bytes can be read.
} else {
bytesRead++; // for statistics
}
return rd;
}
Re: Tomcat RPM polls
Bonjour Henri, Thank you for your effort on RPM distribution. 1) Do you want tomcat to be changed to run as nobody instead of root ? Yes. 2) Do you want tomcat to be enabled by default, ie having it active after installation ? No. 3) Do you want the config stuff to be moved from /var/tomcat/conf to : /etc/tomcat/conf (mimic Apache httpd server conf) /etc/tomcat/ Yes. 4) Do you want the webapp stuff moved to /var/www/webapps ? Yes. 5) Do you want the log stuff moved to /var/log/tomcat ? Yes. Best regards, -- Happy Java programming! Jun Inamori OOP-Reserch E-mail: [EMAIL PROTECTED] URL:http://www.oop-reserch.com/
Session expiring(?) on UNIX platform. Help!!!!
Hello All: We are working on an application which stores successful userid in a session and used for subsequent user requests. On NT platform the app runs fine. However on UNIX platform, the values stored in session are not found (or the session not found?). Every time a request comes from user it appears to be looking for a new session. Checked application code and it works perfectly fine on NT. Seems something to do with Tomcat on UNIX platform. Appreciate if anyone can help... Thanks in Advance Bala Nemani
TC 4.0 run problem - WAS: [ANNOUNCEMENT] Apache Tomcat 4.0 Fina l Release
After rebuild of TC 4.0, I've got the following error : 1) webapps wars are not created under dist/webapp To fix, I'll have to go to /home/anyuser/jakarta-tomcat-4.0-src/webapps and to do : ant -Dwebapps.dist /home/anyuser/jakarta-tomcat-4.0-src/dist/webapps/ 2) After that one, I've still got problems /home/anyuser/jakarta-tomcat-4.0-src/dist/catalina.sh run = Using CLASSPATH: /home/anyuser/jakarta-tomcat-4.0-src/dist//bin/bootstrap.jar:/opt/IBMJava2-1 3/lib/tools.jar Using CATALINA_BASE: /home/anyuser/jakarta-tomcat-4.0-src/dist/ Using CATALINA_HOME: /home/anyuser/jakarta-tomcat-4.0-src/dist/ Using JAVA_HOME: /opt/IBMJava2-13 Starting service Tomcat-Standalone Apache Tomcat/4.0 java.lang.IllegalArgumentException: Document base /home/anyuser/jakarta-tomcat-4.0-src/dist/webapps/examples does not exist or is not a readable directory at org.apache.naming.resources.FileDirContext.setDocBase(FileDirContext.java:18 2) at org.apache.catalina.core.StandardContext.setResources(StandardContext.java:1 084) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3328) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:307) at org.apache.catalina.core.StandardService.start(StandardService.java:388) at org.apache.catalina.core.StandardServer.start(StandardServer.java:505) at org.apache.catalina.startup.Catalina.start(Catalina.java:776) at org.apache.catalina.startup.Catalina.execute(Catalina.java:681) at org.apache.catalina.startup.Catalina.process(Catalina.java:179) at java.lang.reflect.Method.invoke(Native Method) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:218) It recall me a old problem in TC 4.0beta. To fix, I've add to mkdir /home/anyuser/jakarta-tomcat-4.0-src/dist/webapps/ and then unzip /home/anyuser/jakarta-tomcat-4.0-src/dist/webapps/examples.war into it. Thanks for any informations on how to fix these problems. - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
Re: Tomcat RPM polls
On Thu, 20 Sep 2001, GOMEZ Henri wrote: I'd like to have the opinion of Tomcat RPMS users about some points since I'm working on enhanced RPMs : 1) Do you want tomcat to be changed to run as nobody instead of root ? Yes, if possible. Or as user 'tomcat' 2) Do you want tomcat to be enabled by default, ie having it active after installation ? No. It may be a security issue ( since the user may not have changed the passwords for admin, etc ). A nice thing would be to not start at all until this is done - but that should be done in the main tomcat (and later ) 3) Do you want the config stuff to be moved from /var/tomcat/conf to : /etc/tomcat/conf (mimic Apache httpd server conf) /etc/tomcat/ +1 4) Do you want the webapp stuff moved to /var/www/webapps ? +0 5) Do you want the log stuff moved to /var/log/tomcat ? +1 Costin
Re: Anyone solve the cache problem in Tomcat already ?
On Thu, 20 Sep 2001, Kenny Ma wrote: I need to restart tomcat everytime after i change my servlet program even I added reloadable=true in serevr.xml Anyone solve this problem ? please tell me What version of tomcat ? Reloading works pretty well in 3.3 and reasonably well in 3.2. As long as the servlet/jars are in WEB-INF/lib, classes - and not in the main classpath or something like that. We even detect changes in web.xml. Costin
RE: URI handling in tomcat 3.2.3
Jason, Lars, all, I've been investigating the normalized URL, encoded special characters, etc. issues with Tomcat 3.2.3 and I think I have a solution that both maintains the required level of security and allows the kind of thing that Lars and Jason are looking for. I've attached a patch that I would appreciate reviewed by committers to make sure I'm not missing something. What I've done is changed the existing RequestUtil.URLDecode() to prevent the decoding of some additional characters. There was already code there to prevent '/' and '\0' and I added the other protected chars '\\', '.' and '%'. I then removed the draconian test to 404 any URL containing these special chars. If a URI contains encoded special characters from this list then these characters *remain encoded* in the resulting URI. For example /fu/ba+r -- /fu/ba r /fu%2fba+r -- /fu%2fba r I've tested this with all the 'bad' URLs that used to expose JSP source or avoid security constraints and everything works fine. Tomcat will still normalize all URIs as soon as they arrive in the container (sorry Jason). To avoid normalizing data passed in the pathinfo you will need to encode the path characters and then have your servlet URL decode the path info. For example, assuming /fubar/* is the prefix mapping, http://server/fubar/http:%2f%2fURLInPathInfo or http://server/fubar/http:%2f/URLInPathInfo will return path info that can be decoded URLDecoder.decode() into http://URLInPathInfo. Comments? Marc Saegesser -Original Message- From: Marc Saegesser [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 12:49 PM To: [EMAIL PROTECTED] Subject: RE: URI handling in tomcat 3.2.3 Lars, I agree with you. These encoded characters should be allowed in URIs and disallowing them is a hack. Like I said, I think the approach sucks. We were faced with a very serious security problem that had to be addressed very quickly and the decision was made that it was better to forbid certain 'odd' URIs in order to guarantee that resources that the specification *requires* to be protected were indeed protected. We need to look into how to solve the security problems without forbidden valid URIs, but right now I'm about the only one around paying much attention to the tomcat_32 branch so I don't know what kind of time frame wold be involved to get this changed. I do know that the solution will not be trivial. I mentioned Apache httpd only to show that our approach to this problem is in-line with that taken by other industry leading products. We should not (and I think have not) blindly follow httpd (it does a few other things that disagree with). Patches or discussion on how to go about fixing this are certainly welcome! Marc Saegesser -Original Message- From: Lars Oppermann [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 9:23 AM To: [EMAIL PROTECTED] Subject: Re: URI handling in tomcat 3.2.3 Hi Marc, Thanks for you reply... Marc Saegesser wrote: I agree that this URI handling sucks. I'm the one that committed the change that made it happen and I still think it sucks. However, allowing these encoded characters opens some very large security problems. From what I understand, these security problems are all related to mapping URIs to filesystem paths. So how do you feel about doing this processing in the filesystem (default) servlet? Also, even if TC 3.2.x allowed these characters, the resulting URL wouldn't be portable because several other web servers impose the same restrictions. [400 with Apache 1.3.19] I think, if it is possible to do this in a better way while keeping up the protection there is no reason for copying the behaviour of httpd. However, if those security implications can not be handled in the file servlet like I mentioned before, I'd need to do some more thinking on this point. If you need to pass this sort of data to a servlet (or CGI) the most portable way is to simply use a query string. Yes, that sounds like a straight-forward solution. Unfortunatly the service that gets excuted here will access some document and return an html representation. This document contains relative references within the hierarchy represented by the 'wrapped' URI. for this to work with a browser, the request URI has to be used, because the client can not resolve relative references inside a query (why should it) I belive that there are many more use-cases where using URIs to represent hierachical names that do not map to files is desirable, espacialy in a servlet environment. In httpd, which's main work consists of serving file-system resources this might be viewed differently Cheers, Lars -- -- Lars Oppermann [EMAIL PROTECTED] Sun Microsystems Software Engineer - Sun ONE Webtop
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/server PoolTcpConnector.java
jfclere 01/09/20 07:39:17
Modified:src/share/org/apache/tomcat/modules/server
PoolTcpConnector.java
Log:
Add clientauth parameter (Otherwise Client Certificates cannot be used).
Revision ChangesPath
1.11 +8 -0
jakarta-tomcat/src/share/org/apache/tomcat/modules/server/PoolTcpConnector.java
Index: PoolTcpConnector.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/PoolTcpConnector.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- PoolTcpConnector.java 2001/09/14 15:54:26 1.10
+++ PoolTcpConnector.java 2001/09/20 14:39:17 1.11
@@ -229,12 +229,20 @@
attributes.put( keypass, k);
}
+public void setClientauth( String k ) {
+ attributes.put( clientauth, k);
+}
+
public boolean isKeystoreSet() {
return (attributes.get(keystore) != null);
}
public boolean isKeypassSet() {
return (attributes.get(keypass) != null);
+}
+
+public boolean isClientauthSet() {
+return (attributes.get(clientauth) != null);
}
public static final String SSL_CHECK=
Re: Client Certificate using http1.0 and TC3.3
Clere, Jean-Frederic wrote: Hi, I have prepared a patch to allow to use javax.servlet.request.X509Certificate with the Http10Connector of TC3.3. But I think the TC does not send a list of Acceptable client certificate CA names, therefore I am not able to test my patch. Has anyone already request for client certificate in TC3.3? My config is: +++ Http10Connector port=8443 secure=true keypass=my_password clientauth=true / +++ Any hints? I have patched src/share/org/apache/tomcat/modules/server/PoolTcpConnector.java now TC3.3 asks for the Client Certificate. Cheers Jean-frederic PS: I am going home and will go on tomorrow (it is 19:29 here now).
DO NOT REPLY [Bug 3729] - sun/tools/javac/Main not found while running Tomcat 4 as a service on Windows 2000
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3729. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3729 sun/tools/javac/Main not found while running Tomcat 4 as a service on Windows 2000 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED --- Additional Comments From [EMAIL PROTECTED] 2001-09-20 07:53 --- The Tomcat 4.0 install script, jakarta-tomcat-4.0-src\tomcat.nsi, references HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Development Kit\1.4\JavaHome to copy tools.jar to the Apache Tomcat 4.0\common\lib folder. If JavaHome doesn't point to the JDK but to the JRE as in my case tools.jar won't get copied. Either manually copy it there or correct the registry entry and reinstall Tomcat. Here's the revelant secion of tomcat.nsi: ReadRegStr $2 HKLM SOFTWARE\JavaSoft\Java Development Kit\$1 JavaHome CopyFiles $2\lib\tools.jar $INSTDIR\common\lib 4500
Re: Tomcat RPM polls
On Thu, 20 Sep 2001, GOMEZ Henri wrote: Date: Thu, 20 Sep 2001 10:48:51 +0200 From: GOMEZ Henri [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Tomcat RPM polls Hi to all, I'd like to have the opinion of Tomcat RPMS users about some points since I'm working on enhanced RPMs : 1) Do you want tomcat to be changed to run as nobody instead of root ? +1 2) Do you want tomcat to be enabled by default, ie having it active after installation ? Can't you set things up for the installer to ask the user this? It would be nice to make this easy, but enabling by default is a security risk. 3) Do you want the config stuff to be moved from /var/tomcat/conf to : /etc/tomcat/conf (mimic Apache httpd server conf) /etc/tomcat/ Does the RPM packaging support the ability (courtesy of catalina.base) to store static stuff one place, and have multiple installations of the dynamic stuff? 4) Do you want the webapp stuff moved to /var/www/webapps ? Would /var/tomcat/webapps be more consistent? Someone unfamiliar with things would not necessarily tie www to Tomcat. 5) Do you want the log stuff moved to /var/log/tomcat ? Makes sense. Thanks for your replies - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 Craig
DO NOT REPLY [Bug 3752] New: - JspFactory.getDefaultFactory().getPageContext returns always null
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3752.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3752
JspFactory.getDefaultFactory().getPageContext returns always null
Summary: JspFactory.getDefaultFactory().getPageContext returns
always null
Product: Tomcat 4
Version: 4.0 Final
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Severity: Normal
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
JspFactory.getDefaultFactory().getPageContext(...) returns null everytime i
call it.
--- test servlet ---
import java.io.IOException;
import javax.servlet.ServletException;
import javax.servlet.jsp.JspFactory;
import javax.servlet.jsp.JspWriter;
import javax.servlet.jsp.PageContext;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class PageContextServlet extends HttpServlet {
public void doGet(HttpServletRequest request,
HttpServletResponse response) throws ServletException,
IOException {
PageContext pageContext = JspFactory.getDefaultFactory()
.getPageContext(this,
request,
response,
/error.html,
false,
JspWriter.DEFAULT_BUFFER,
true);
System.out.println(pageContext = + pageContext);
}
}
--- end test servlet ---
prints out. pageContext = null
or am i just too stupid to get the PageContext the right way ;-) (btw, bea
weblogic (6.0 final, sp1, sp2 and 6.1) works.
Re: Tomcat RPM polls
Em Quinta, 20 de Setembro de 2001 09:48, escreveste: Hi to all, I'd like to have the opinion of Tomcat RPMS users about some points since I'm working on enhanced RPMs : 1) Do you want tomcat to be changed to run as nobody instead of root ? yes 2) Do you want tomcat to be enabled by default, ie having it active after installation ? no. security concerns. You can, however, add something like this to the rpc description and/or echo it at post: Tomcat is not enable by default. Run the following commands to enable it. /sbin/chkconfig tomcat on /sbin/service tomcat start 3) Do you want the config stuff to be moved from /var/tomcat/conf to : /etc/tomcat/conf (mimic Apache httpd server conf) /etc/tomcat/ yes 4) Do you want the webapp stuff moved to /var/www/webapps ? yes 5) Do you want the log stuff moved to /var/log/tomcat ? yes Thanks for your replies - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
Re: TC 3.3: Form authentication vs. Application reloading
Hi Bojan, A simpler solution is to fix ReloadInterceptor - and save the current list of interceptors before removing the context, then add all per/context interceptors after the context is added back ( those having getContext() != null ). This would deal with other configuration mechanisms as well - ContextXmlReader is not the only way to add contexts, applications embeding tomcat may use API calls as well. Dealing with changes in app.xml is a bit more difficult - and I think the right long-term solution is to consolidate all config modules and create a smart 'deploy tool' module that can take care of all the issues. Costin On Thu, 20 Sep 2001, Bojan Smojver wrote: Bojan Smojver wrote: Is this something that happens by design or am I looking at a possible bug? By following what happens when TC starts and when it reloads the context, it seems that there should be contextInit() method in ContextXmlReader. This interceptor is responsible for calling the ServerXmlReader.loadConfigFile() which in turn (after a series of XML related calls on the stack) calls Context.addInterceptor(), which is responsible for adding all local (to the context) interceptors. If ContextXmlReader had contextInit() method, this would happen every time the context is reloaded and all local interceptors (including my JDBCRealm :-) would be picked up. Swt! Now that's all cool, but I wouldn't have a clue how to write that method. If you guys can point me in the right direction... Thanks, Bojan
[PATCH] to get Client Certificates in TC3.3
Hi,
I have prepared a patch to get the javax.servlet.request.X509Certificate
working with the Http10Connector.
I will commit it tomorrow (after removing the println() and retesting with JSSE
and without JSSE).
I have enclosed the patch for Http10Interceptor.java and the 2 new CertCompat
files.
I have also committed a small patch for PoolTcpConnector.java please check it...
Any comments?
Cheers
Jean-frederic
? src/share/org/apache/tomcat/util/compat/CertCompat.java
? src/share/org/apache/tomcat/util/compat/JSSECertCompat.java
Index: src/share/org/apache/tomcat/modules/server/Http10Interceptor.java
===
RCS file:
/home/cvs/mirror/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Http10Interceptor.java,v
retrieving revision 1.23
diff -u -r1.23 Http10Interceptor.java
--- src/share/org/apache/tomcat/modules/server/Http10Interceptor.java 2001/09/17
04:56:02 1.23
+++ src/share/org/apache/tomcat/modules/server/Http10Interceptor.java 2001/09/20
+17:05:46
@@ -71,6 +71,7 @@
import org.apache.tomcat.util.net.*;
import org.apache.tomcat.util.net.ServerSocketFactory;
import org.apache.tomcat.util.log.*;
+import org.apache.tomcat.util.compat.*;
/** Standalone http.
*
@@ -204,9 +205,16 @@
Http10 http=new Http10();
private boolean moreRequests = false;
Socket socket;
+static CertCompat certcompat = CertCompat.getCertCompat();
public HttpRequest() {
super();
+}
+public Object getAttribute(String name) {
+if (name.equals(javax.servlet.request.X509Certificate)) {
+return(certcompat.getX509Certificates(socket));
+ }
+return(super.getAttribute(name));
}
public void recycle() {
package org.apache.tomcat.util.compat;
import java.io.ByteArrayInputStream;
import java.net.Socket;
import javax.net.ssl.SSLSession;
import javax.net.ssl.SSLSocket;
import java.security.cert.CertificateFactory;
import javax.security.cert.X509Certificate;
public class JSSECertCompat extends CertCompat {
/** Return the client certificate.
*/
public java.security.cert.X509Certificate [] getX509Certificates(Socket s)
{
// Make sure it is a SSLSocket.
System.out.println(getX509Certificates: JSSECertCompat.java);
if (s == null)
return null;
if (!(s instanceof SSLSocket))
return null;
SSLSocket socket = (SSLSocket) s;
// Look up the current SSLSession
System.out.println(getX509Certificates: getSession);
SSLSession session = socket.getSession();
if (session == null)
return null;
// Convert JSSE's certificate format to the ones we need
System.out.println(getX509Certificates: PeerCertificateChain);
X509Certificate jsseCerts[] = null;
java.security.cert.X509Certificate x509Certs[] = null;
try {
jsseCerts = session.getPeerCertificateChain();
if (jsseCerts == null)
jsseCerts = new X509Certificate[0];
x509Certs =
new java.security.cert.X509Certificate[jsseCerts.length];
System.out.println(getX509Certificates: jsseCerts.length +
jsseCerts.length);
for (int i = 0; i x509Certs.length; i++) {
byte buffer[] = jsseCerts[i].getEncoded();
CertificateFactory cf =
CertificateFactory.getInstance(X.509);
ByteArrayInputStream stream =
new ByteArrayInputStream(buffer);
x509Certs[i] = (java.security.cert.X509Certificate)
cf.generateCertificate(stream);
}
} catch (Throwable t) {
System.out.println(getX509Certificates: Throwable + t);
return null;
}
if ((x509Certs == null) || (x509Certs.length 1))
return null;
return x509Certs;
}
}
package org.apache.tomcat.util.compat;
import java.net.Socket;
import javax.security.cert.X509Certificate;
public class CertCompat {
/** Return the client certificate.
*/
public java.security.cert.X509Certificate [] getX509Certificates(Socket s)
{
System.out.println(getX509Certificates CertCompat.java);
return null;
}
// Factory
/** Get a compatibility helper class.
*/
public static CertCompat getCertCompat() {
return compat;
}
static CertCompat compat;
static {
init();
}
static final String JSSE_SUPPORT=
org.apache.tomcat.util.compat.JSSECertCompat;
private static void init() {
System.out.println(init CertCompat.java);
try {
Class c=Class.forName(JSSE_SUPPORT);
compat=(CertCompat)c.newInstance();
} catch( Exception ex ) {
System.out.println(init failed: + ex);
compat=new
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startupEmbedded.java
On 19 Sep 2001 [EMAIL PROTECTED] wrote: remm01/09/19 16:53:02 Modified:catalina/src/share/org/apache/catalina/startup Embedded.java Log: - Use reflection to load the SSLServerSocketFactory, which removes the last compilation problem when trying to build with JDK 1.3 + servlet.jar + regexp.jar. - Hopefully, everyone's happy with the build process now :) I'm impressed ! If you check in the 2 jar files ( like all jakarta projects do, while allowing them to be overriden by gump of course ) - the build will be close to perfect. Costin
DO NOT REPLY [Bug 3740] - simple javabeans problem
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3740. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3740 simple javabeans problem --- Additional Comments From [EMAIL PROTECTED] 2001-09-20 10:36 --- I got a NullPointerException in JakartaCommentGenerator.generateEndComment when I tried it. Hmm... If I just add a comment line %-- --% as the first line, then everyting works as expected, including the Hello World. I'll fix the NPE and see what happen next.
cvs commit: jakarta-tomcat-4.0/lib tyrex.license
remm01/09/20 10:33:15 Added: lib Tag: tomcat_40_branch tyrex.license Log: - Add a Tyrex license document. Revision ChangesPath No revision No revision 1.1.2.1 +0 -0 jakarta-tomcat-4.0/lib/tyrex.license Index: tyrex.license === RCS file: /home/cvs/jakarta-tomcat-4.0/lib/tyrex.license,v retrieving revision 1.1 retrieving revision 1.1.2.1 diff -u -r1.1 -r1.1.2.1
Re: [PATCH] to get Client Certificates in TC3.3
Hi, Regarding CertCompat: I'm not sure we need it, the functions could be added to jdk11Compat. It's not a big deal, I can change this after you commit ( unless you have reasons or a preference to create a compat class for cert-related code - which is ok ). It seems ok - the only question is if we should put it in before or after RC1. Costin On Thu, 20 Sep 2001, jean-frederic clere wrote: Hi, I have prepared a patch to get the javax.servlet.request.X509Certificate working with the Http10Connector. I will commit it tomorrow (after removing the println() and retesting with JSSE and without JSSE). I have enclosed the patch for Http10Interceptor.java and the 2 new CertCompat files. I have also committed a small patch for PoolTcpConnector.java please check it... Any comments? Cheers Jean-frederic
cvs commit: jakarta-tomcat-4.0/catalina build.xml
remm01/09/20 10:41:03
Modified:catalina Tag: tomcat_40_branch build.xml
Log:
- Don't copy ldap.jar until further notice.
- Copy tyrex.license.
- Revert Sam's patch on conditional copy of Tyrex (if we're using conditional
compilation, we should backport from the HEAD branch IMO).
Revision ChangesPath
No revision
No revision
1.60.2.2 +7 -5 jakarta-tomcat-4.0/catalina/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/build.xml,v
retrieving revision 1.60.2.1
retrieving revision 1.60.2.2
diff -u -r1.60.2.1 -r1.60.2.2
--- build.xml 2001/09/19 16:32:43 1.60.2.1
+++ build.xml 2001/09/20 17:41:03 1.60.2.2
@@ -85,11 +85,7 @@
!-- === BUILD: Copy Static Files === --
- target name=copy-tyrex depends=build-prepare if=tyrex.present
-copy todir=${catalina.build}/common/lib file=${tyrex.jar}/
- /target
-
- target name=build-static depends=build-prepare,copy-tyrex
+ target name=build-static depends=build-prepare
!-- Executable Commands --
copy todir=${catalina.build}/bin
@@ -108,13 +104,19 @@
copy todir=${catalina.build}/common/lib file=${copy.jaxp.jar}/
copy todir=${catalina.build}/common/lib file=${jdbc20ext.jar}/
copy todir=${catalina.build}/common/lib file=${jndi.jar}/
+!-- Cannot redistribute JSSE
copy todir=${catalina.build}/common/lib file=${jnet.jar}/
copy todir=${catalina.build}/common/lib file=${jsse.jar}/
copy todir=${catalina.build}/common/lib file=${jcert.jar}/
+--
copy todir=${catalina.build}/common/lib file=${jta.jar}/
+!-- Connot redistribute LDAP
copy todir=${catalina.build}/common/lib file=${ldap.jar}/
+--
copy todir=${catalina.build}/common/lib file=${mail.jar}/
copy todir=${catalina.build}/common/lib file=${servlet.jar}/
+copy todir=${catalina.build}/common/lib file=${tyrex.jar}/
+copy todir=${catalina.build}/common/lib file=../lib/tyrex.license/
!-- Configuration Files --
copy todir=${catalina.build}/conf
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader WebappClassLoader.java
remm01/09/20 10:47:23
Modified:catalina/src/share/org/apache/catalina/loader Tag:
tomcat_40_branch WebappClassLoader.java
Log:
- According to paragraph 9.7.2 of the Servlet 2.3 spec, we should refuse loading
any class related to J2SE or the servlet API from the webapp class repository.
- This prevents ClassCasts when putting an old servlet.jar in the webapp
repository, BUT JSPs will still fail to build (the reason is that javac uses a
classpath
String to lookup the JARs .). I have no idea how to fix the JSP
problem.
Revision ChangesPath
No revision
No revision
1.15.2.1 +31 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java
Index: WebappClassLoader.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
retrieving revision 1.15
retrieving revision 1.15.2.1
diff -u -r1.15 -r1.15.2.1
--- WebappClassLoader.java2001/09/07 19:16:31 1.15
+++ WebappClassLoader.java2001/09/20 17:47:23 1.15.2.1
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
1.15 2001/09/07 19:16:31 remm Exp $
- * $Revision: 1.15 $
- * $Date: 2001/09/07 19:16:31 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
1.15.2.1 2001/09/20 17:47:23 remm Exp $
+ * $Revision: 1.15.2.1 $
+ * $Date: 2001/09/20 17:47:23 $
*
*
*
@@ -123,7 +123,7 @@
*
* @author Remy Maucherat
* @author Craig R. McClanahan
- * @version $Revision: 1.15 $ $Date: 2001/09/07 19:16:31 $
+ * @version $Revision: 1.15.2.1 $ $Date: 2001/09/20 17:47:23 $
*/
public class WebappClassLoader
extends URLClassLoader
@@ -1414,6 +1414,9 @@
protected Class findClassInternal(String name)
throws ClassNotFoundException {
+if (!validate(name))
+throw new ClassNotFoundException(name);
+
String tempPath = name.replace('.', '/');
String classPath = tempPath + .class;
@@ -1733,6 +1736,30 @@
// Some policy files may restrict this, even for the core,
// so this exception is ignored
}
+
+}
+
+
+/**
+ * Validate a classname. As per SRV.9.7.2, we must restict loading of
+ * classes from J2SE (java.*) and classes of the servlet API
+ * (javax.servlet.*). That should enhance robustness and prevent a number
+ * of user error (where an older version of servlet.jar would be present
+ * in /WEB-INF/lib).
+ *
+ * @param name class name
+ * @return true if the name is valid
+ */
+protected boolean validate(String name) {
+
+if (name == null)
+return false;
+if (name.startsWith(java.))
+return false;
+if (name.startsWith(javax.servlet.))
+return false;
+
+return true;
}
cvs commit: jakarta-tomcat-4.0/webapps/examples/jsp/simpletag foo.jsp
remm01/09/20 10:48:27 Modified:webapps/examples/jsp/simpletag Tag: tomcat_40_branch foo.jsp Log: - Remove the debug-taglib declaration (was it used for testing ?). Revision ChangesPath No revision No revision 1.2.2.1 +0 -1 jakarta-tomcat-4.0/webapps/examples/jsp/simpletag/foo.jsp Index: foo.jsp === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/examples/jsp/simpletag/foo.jsp,v retrieving revision 1.2 retrieving revision 1.2.2.1 diff -u -r1.2 -r1.2.2.1 --- foo.jsp 2001/09/05 05:14:01 1.2 +++ foo.jsp 2001/09/20 17:48:27 1.2.2.1 @@ -4,7 +4,6 @@ reserved. -- body -%@ taglib uri=http://jakarta.apache.org/tomcat/debug-taglib; prefix=d% %@ taglib uri=http://jakarta.apache.org/tomcat/examples-taglib; prefix=eg% Radio stations that rock:
cvs commit: jakarta-tomcat-4.0/webapps/examples/jsp/simpletag foo.jsp
remm01/09/20 10:48:49 Modified:webapps/examples/jsp/simpletag foo.jsp Log: - Remove the debug-taglib declaration (was it used for testing ?). Revision ChangesPath 1.3 +0 -1 jakarta-tomcat-4.0/webapps/examples/jsp/simpletag/foo.jsp Index: foo.jsp === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/examples/jsp/simpletag/foo.jsp,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- foo.jsp 2001/09/05 05:14:01 1.2 +++ foo.jsp 2001/09/20 17:48:49 1.3 @@ -4,7 +4,6 @@ reserved. -- body -%@ taglib uri=http://jakarta.apache.org/tomcat/debug-taglib; prefix=d% %@ taglib uri=http://jakarta.apache.org/tomcat/examples-taglib; prefix=eg% Radio stations that rock:
DO NOT REPLY [Bug 3739] - custom tag support error
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3739. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3739 custom tag support error [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2001-09-20 10:56 --- Fixed (in CVS).
DO NOT REPLY [Bug 3709] - Tyrex license is not being followed
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3709. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3709 Tyrex license is not being followed [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2001-09-20 10:59 --- Added the appropriate license file in the CVS, and copy it to the binary distribution.
DO NOT REPLY [Bug 3708] - ldap.jar has a questionable license
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3708. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3708 ldap.jar has a questionable license [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2001-09-20 11:01 --- Fix in CVS: don't copy ldap.jar until further notice.
RE: [PATCH] to get Client Certificates in TC3.3
I'm +1 for trying to include this. Having it in RC1 will give it some more testing and one less change for RC2. I'm also in favor of getting the IIS connector to pass the certificate to Tomcat as well for the same reason. I have been helping Jean-frederic and Nacho work on that. I looks like I will be building RC1 over the weekend anyway. Too many other fires to deal with at the moment. :-( Cheers, Larry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 20, 2001 1:51 PM To: [EMAIL PROTECTED] Subject: Re: [PATCH] to get Client Certificates in TC3.3 Hi, Regarding CertCompat: I'm not sure we need it, the functions could be added to jdk11Compat. It's not a big deal, I can change this after you commit ( unless you have reasons or a preference to create a compat class for cert-related code - which is ok ). It seems ok - the only question is if we should put it in before or after RC1. Costin On Thu, 20 Sep 2001, jean-frederic clere wrote: Hi, I have prepared a patch to get the javax.servlet.request.X509Certificate working with the Http10Connector. I will commit it tomorrow (after removing the println() and retesting with JSSE and without JSSE). I have enclosed the patch for Http10Interceptor.java and the 2 new CertCompat files. I have also committed a small patch for PoolTcpConnector.java please check it... Any comments? Cheers Jean-frederic
Session expiring(?) on UNIX platform. Help!!!!...
Hello All: We are working on an application which stores successful userid in a session and used for subsequent user requests. On NT platform the app runs fine. However on UNIX platform, the values stored in session are not found (or the session not found?). Every time a request comes from user it appears to be looking for a new session. Checked application code and it works perfectly fine on NT. Seems something to do with Tomcat on UNIX platform. Appreciate if anyone can help... Thanks in Advance Bala Nemani
[PATCH] TC4.0 Throws NPE in JakartaCommentGenerator
This patch fixes the NPE raised when a jsp:useBean has a non empty body.
However, it does not fix the problem reported in #3740, since I couldn't
reproduce the same bug, though the test now works!
misto% runsocks cvs diff -u Parser.java
Index: Parser.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/P
arser.java,v
retrieving revision 1.13
diff -u -r1.13 Parser.java
--- Parser.java 2001/09/15 01:18:10 1.13
+++ Parser.java 2001/09/20 20:55:57
@@ -1096,11 +1096,12 @@
boolean noJspElement = false;
while (reader.hasMoreInput()) {
+if (tmplStart == null)
+tmplStart = reader.mark();
+if (tmplStop == null)
+tmplStop = reader.mark();
+
if (until != null reader.matches(until)) {
-if (tmplStart == null)
-tmplStart = reader.mark();
-if (tmplStop == null)
-tmplStop = reader.mark();
return;
}
Proposed Patch for #3733
Jon Stevens has proposed a patch to change the event order during the process of a context reload (either because a modified class was detected when you set reloadable to true, or manually via the Manager webapp). Here's the current event order (in StandardContext.reload()): (1) Pause requests temporarily (2) Set the thread context class loader to the webapp's class loader (3) Shut down and unload all defined servlets (calls destroy() if they have ever been initialized (4) Remove all application-created attributes from the servlet context attributes (to avoid dangling references when we change class loaders) (5) Shut down all registered filters and application event listeners (6) Shut down the session manager (and serialize sessions to disk) (7) Unset the thread context class loader (8) Shut down, recreate, and restart the application's class loader (9) Recreate the JNDI naming context for this application (10) Set the thread context class loader to the webapp's class loader (11) Restart the session manager (and deserialize sessions from disk) (12) Restart registered application event listeners and filters (13) Restart all currently defined servlets (but do not call init() on any of them yet) (14) If defined servlets were marked load-on-startup, call init() on them in the same order that they were originally started. (15) Unset the thread context class loader (16) Unpause request processing The proposed patch moves items (13) and (14) to be after item (10). This would have the effect of reloading (and re-init()-ing for load-on-startup servlets) before the saved sessions were deserialized. In principle, this change should not cause any difficulties -- the only potential problem would be if a servlet attempted to reference a session from within the init() method, but this is not possible because you need a reference to a request in order to acquire a reference to a session. However, I would like to propose a slight alteration to thischange to the reload() method, so that listeners and filters are also restarted before the servlets are. This is consistent with what happens when the application originally starts up, and allows the init() method of a servlet to assume that servlet context attributes created by a listener (for example) will already be present. Using this approach, the second half of the list (using the original item numbers but the revised order) would look like this: (10) Set the thread context class loader (12) Restart registered application event listeners and filters (13) Restart currently defined servlets (14) Call init() on load-on-startup servlets (11) Restart the session manager (and deserialize sessions from disk) (15) Unset the thread context class loader (16) Unpause request processing Finally, the StandardContext.start() method should be modified so that session reloading during initial application startup (i.e. right after you start Tomcat) is also done after the listeners, filters, and servlets have been initialized. That way, session state reloading happens consistently under all circumstances in which it is executed. I cannot see that this would cause any difficulties with dependencies. Can anyone else see a problem with it? Craig McClanahan
Re: [PATCH] Error in examples/simpletag/foo.jsp
This patch fixes #3739. runsocks cvs diff -u foo.jsp Index: foo.jsp === RCS file: /home/cvspublic/jakarta-tomcat-4.0/webapps/examples/jsp/simpletag/foo.jsp,v retrieving revision 1.2 diff -u -r1.2 foo.jsp --- foo.jsp 2001/09/05 05:14:01 1.2 +++ foo.jsp 2001/09/20 21:28:47 @@ -4,7 +4,6 @@ reserved. -- body -%@ taglib uri=http://jakarta.apache.org/tomcat/debug-taglib; prefix=d% %@ taglib uri=http://jakarta.apache.org/tomcat/examples-taglib; prefix=eg% Radio stations that rock:
Re: Proposed Patch for #3733
on 9/20/01 2:21 PM, Craig R. McClanahan [EMAIL PROTECTED] wrote: I cannot see that this would cause any difficulties with dependencies. Can anyone else see a problem with it? Craig McClanahan +1 I'm ok with the filters being initialized first since I'm not using any. :-) Thanks for the quick turnaround! -jon
cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler Parser.java
remm01/09/20 14:47:32
Modified:jasper/src/share/org/apache/jasper/compiler Parser.java
Log:
- Fixes bug 3740.
Patch submitted by Kin-Man Chung.
Revision ChangesPath
1.14 +5 -4
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/Parser.java
Index: Parser.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/Parser.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- Parser.java 2001/09/15 01:18:10 1.13
+++ Parser.java 2001/09/20 21:47:32 1.14
@@ -1096,11 +1096,12 @@
boolean noJspElement = false;
while (reader.hasMoreInput()) {
+if (tmplStart == null)
+tmplStart = reader.mark();
+if (tmplStop == null)
+tmplStop = reader.mark();
+
if (until != null reader.matches(until)) {
-if (tmplStart == null)
-tmplStart = reader.mark();
-if (tmplStop == null)
-tmplStop = reader.mark();
return;
}
cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler Parser.java
remm01/09/20 14:50:58
Modified:jasper/src/share/org/apache/jasper/compiler Tag:
tomcat_40_branch Parser.java
Log:
- Fixes bug 3740.
Patch submitted by Kin-Man Chung.
Revision ChangesPath
No revision
No revision
1.13.2.1 +5 -4
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/Parser.java
Index: Parser.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/Parser.java,v
retrieving revision 1.13
retrieving revision 1.13.2.1
diff -u -r1.13 -r1.13.2.1
--- Parser.java 2001/09/15 01:18:10 1.13
+++ Parser.java 2001/09/20 21:50:58 1.13.2.1
@@ -1096,11 +1096,12 @@
boolean noJspElement = false;
while (reader.hasMoreInput()) {
+if (tmplStart == null)
+tmplStart = reader.mark();
+if (tmplStop == null)
+tmplStop = reader.mark();
+
if (until != null reader.matches(until)) {
-if (tmplStart == null)
-tmplStart = reader.mark();
-if (tmplStop == null)
-tmplStop = reader.mark();
return;
}
Re: URI handling in tomcat 3.2.3
Marc, Thanks for still thinking about this. :-) And thanks to Lars for raising the interesting point from 2396 that a / has a reserved purpose in a URI and if you want to use it for a different purpose you should escape it. That makes it sound like your patch is a highly reasonable solution, and perhaps the best we can do until the spec can provide more guidance. -jh- Marc Saegesser wrote: Jason, Lars, all, I've been investigating the normalized URL, encoded special characters, etc. issues with Tomcat 3.2.3 and I think I have a solution that both maintains the required level of security and allows the kind of thing that Lars and Jason are looking for. I've attached a patch that I would appreciate reviewed by committers to make sure I'm not missing something. What I've done is changed the existing RequestUtil.URLDecode() to prevent the decoding of some additional characters. There was already code there to prevent '/' and '\0' and I added the other protected chars '\\', '.' and '%'. I then removed the draconian test to 404 any URL containing these special chars. If a URI contains encoded special characters from this list then these characters *remain encoded* in the resulting URI. For example /fu/ba+r -- /fu/ba r /fu%2fba+r -- /fu%2fba r I've tested this with all the 'bad' URLs that used to expose JSP source or avoid security constraints and everything works fine. Tomcat will still normalize all URIs as soon as they arrive in the container (sorry Jason). To avoid normalizing data passed in the pathinfo you will need to encode the path characters and then have your servlet URL decode the path info. For example, assuming /fubar/* is the prefix mapping, http://server/fubar/http:%2f%2fURLInPathInfo or http://server/fubar/http:%2f/URLInPathInfo will return path info that can be decoded URLDecoder.decode() into http://URLInPathInfo. Comments? Marc Saegesser -Original Message- From: Marc Saegesser [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 12:49 PM To: [EMAIL PROTECTED] Subject: RE: URI handling in tomcat 3.2.3 Lars, I agree with you. These encoded characters should be allowed in URIs and disallowing them is a hack. Like I said, I think the approach sucks. We were faced with a very serious security problem that had to be addressed very quickly and the decision was made that it was better to forbid certain 'odd' URIs in order to guarantee that resources that the specification *requires* to be protected were indeed protected. We need to look into how to solve the security problems without forbidden valid URIs, but right now I'm about the only one around paying much attention to the tomcat_32 branch so I don't know what kind of time frame wold be involved to get this changed. I do know that the solution will not be trivial. I mentioned Apache httpd only to show that our approach to this problem is in-line with that taken by other industry leading products. We should not (and I think have not) blindly follow httpd (it does a few other things that disagree with). Patches or discussion on how to go about fixing this are certainly welcome! Marc Saegesser -Original Message- From: Lars Oppermann [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 9:23 AM To: [EMAIL PROTECTED] Subject: Re: URI handling in tomcat 3.2.3 Hi Marc, Thanks for you reply... Marc Saegesser wrote: I agree that this URI handling sucks. I'm the one that committed the change that made it happen and I still think it sucks. However, allowing these encoded characters opens some very large security problems. From what I understand, these security problems are all related to mapping URIs to filesystem paths. So how do you feel about doing this processing in the filesystem (default) servlet? Also, even if TC 3.2.x allowed these characters, the resulting URL wouldn't be portable because several other web servers impose the same restrictions. [400 with Apache 1.3.19] I think, if it is possible to do this in a better way while keeping up the protection there is no reason for copying the behaviour of httpd. However, if those security implications can not be handled in the file servlet like I mentioned before, I'd need to do some more thinking on this point. If you need to pass this sort of data to a servlet (or CGI) the most portable way is to simply use a query string. Yes, that sounds like a straight-forward solution. Unfortunatly the service that gets excuted here will access some document and return an html representation. This document contains relative references within the hierarchy represented by the 'wrapped' URI. for this to work with a browser, the request URI has to be used, because the client can not resolve relative references
Re: URI handling in tomcat 3.2.3
You only use http:// in the GET request if you're talking to a proxy server. That's probably why you got the bad request error, not because of the %2f. You should try: GET /cgi-bin/dumpenv.bat/fu%2fbar HTTP/1.1 -jh- Marc Saegesser wrote: Oops, minor correction. Apache actually returns 400 Bad Request Here's the telnet session GET http://localhost:8081/cgi-bin/dumpenv.bat/fu%2fbar HTTP/1.1 server: msaegesserlpt HTTP/1.1 400 Bad Request Date: Thu, 13 Sep 2001 13:51:21 GMT Server: Apache/1.3.19 (Win32) mod_jk Connection: close Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-1 18b !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN HTMLHEAD TITLE400 Bad Req uest/TITLE /HEADBODY H1Bad Request/H1 Your browser sent a request that th is server could not understand.P client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /cgi-bin/dumpenv.bat/fu%2fbarP HR ADDRESSApache /1.3.19 Server at msaegesserlpt Port 8081/ADDRESS /BODY/HTML 0 Connection to host lost. Marc Saegesser -Original Message- From: Marc Saegesser [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 8:48 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: URI handling in tomcat 3.2.3 I agree that this URI handling sucks. I'm the one that committed the change that made it happen and I still think it sucks. However, allowing these encoded characters opens some very large security problems. Also, even if TC 3.2.x allowed these characters, the resulting URL wouldn't be portable because several other web servers impose the same restrictions. In fact we lifted our restriction on encoded special characters straight from Apache HTTPD. In your example URL, if /app/UCB was a CGI script then you would still get a 404 on Apache (at least on Apache 1.3.19 which is what I tested with). If you need to pass this sort of data to a servlet (or CGI) the most portable way is to simply use a query string. Marc Saegesser -Original Message- From: Lars Oppermann [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 5:00 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: URI handling in tomcat 3.2.3 Hi everyone, we were in progress of moving our project to tomcat 3.2.3 when we came accross the new handling of URIs (release-notes sec. 7.2). Since we are using the URI to transport other hierarchical information then filesystem paths, we have the feeling, that this kind of functionality belongs to the default servlet serving filesystem requests. Especialy the fact that %25, %2E, %2F and %5c inside an URI lead to a 404 error seems to somewhat strange. For Example: http://server/app/UCB/vnd.sun.star.hier:%2F/address/myresource would be rejected, before app has teh possibilty to look at the request and ...hier://address/myfile... would be normalized to hier:/address. We are perfectly aware of the security concerns behind these changes. However, they only apply when serving resources from the filesystem. A URL's path-components however are in no way bound to the representaion of filesystem paths.(After all, the U in URL stands for universal :) RFC 2396 states that '/' in an URI has another semantic meaning then %2F in an URI. The '/' seperates path-components, while the %2F means a slash character in a path-component. When such an URI is mapped to a filesystem this would denote a filename that contains a slash. When the system does not allow for such names, it is the responsebilty of the filesystem servlet to report an error (404 since such a file must not exist on unix for example). What are your opinions on this? Cheers -Lars -- -- Lars Oppermann [EMAIL PROTECTED] Sun Microsystems Software Engineer - Sun ONE Webtop Sachsenfeld 4 Phone: +49 40 23646 959D-20097 Hamburg Fax: +49 40 23646 550 http://www.sun.com/webtop
cvs commit: jakarta-tomcat-4.0/catalina/src/conf web.xml
craigmcc01/09/20 15:27:27 Modified:catalina/src/conf Tag: tomcat_40_branch web.xml Log: Correct the comment above the session-timeout element -- the web.xml value is really in minutes. Revision ChangesPath No revision No revision 1.22.2.1 +1 -1 jakarta-tomcat-4.0/catalina/src/conf/web.xml Index: web.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/conf/web.xml,v retrieving revision 1.22 retrieving revision 1.22.2.1 diff -u -r1.22 -r1.22.2.1 --- web.xml 2001/09/10 04:22:35 1.22 +++ web.xml 2001/09/20 22:27:27 1.22.2.1 @@ -273,7 +273,7 @@ !-- Default Session Configuration = -- - !-- You can set the default session timeout (in seconds) for all newly -- + !-- You can set the default session timeout (in minutes) for all newly -- !-- created sessions by modifying the value below. -- session-config
cvs commit: jakarta-tomcat-4.0/catalina/src/conf web.xml
craigmcc01/09/20 15:28:32 Modified:catalina/src/conf web.xml Log: Session timeouts in web.xml are in minutes, not seconds. Submitted by: Jim Urban [EMAIL PROTECTED] Revision ChangesPath 1.23 +1 -1 jakarta-tomcat-4.0/catalina/src/conf/web.xml Index: web.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/conf/web.xml,v retrieving revision 1.22 retrieving revision 1.23 diff -u -r1.22 -r1.23 --- web.xml 2001/09/10 04:22:35 1.22 +++ web.xml 2001/09/20 22:28:31 1.23 @@ -273,7 +273,7 @@ !-- Default Session Configuration = -- - !-- You can set the default session timeout (in seconds) for all newly -- + !-- You can set the default session timeout (in minutes) for all newly -- !-- created sessions by modifying the value below. -- session-config
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets InvokerServlet.java
remm01/09/20 16:34:42
Modified:catalina/src/share/org/apache/catalina/servlets
InvokerServlet.java
Log:
- Fix for bug 3736. Tricky bug caused by using the invoker servlet
Revision ChangesPath
1.14 +12 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/InvokerServlet.java
Index: InvokerServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/InvokerServlet.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- InvokerServlet.java 2001/08/24 23:19:06 1.13
+++ InvokerServlet.java 2001/09/20 23:34:42 1.14
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/InvokerServlet.java,v
1.13 2001/08/24 23:19:06 craigmcc Exp $
- * $Revision: 1.13 $
- * $Date: 2001/08/24 23:19:06 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/InvokerServlet.java,v
1.14 2001/09/20 23:34:42 remm Exp $
+ * $Revision: 1.14 $
+ * $Date: 2001/09/20 23:34:42 $
*
*
*
@@ -87,7 +87,7 @@
* in the web application deployment descriptor.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.13 $ $Date: 2001/08/24 23:19:06 $
+ * @version $Revision: 1.14 $ $Date: 2001/09/20 23:34:42 $
*/
public final class InvokerServlet
@@ -273,6 +273,7 @@
String inPathInfo = null;
boolean included =
(request.getAttribute(Globals.REQUEST_URI_ATTR) != null);
+
if (included) {
inRequestURI =
(String) request.getAttribute(Globals.REQUEST_URI_ATTR);
@@ -422,6 +423,13 @@
context.removeChild(wrapper);
throw new ServletException
(sm.getString(invokerServlet.allocate, inRequestURI), e);
+}
+
+// After loading the wrapper, restore some of the fields when including
+if (included) {
+wrequest.setRequestURI(request.getRequestURI());
+wrequest.setPathInfo(request.getPathInfo());
+wrequest.setServletPath(request.getServletPath());
}
// Invoke the service() method of the allocated servlet
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup Bootstrap.java
remm01/09/20 16:46:27
Modified:catalina/src/share/org/apache/catalina/startup
Bootstrap.java
Log:
- Don't load ldap.jar if the system CL has the LDAP classes already (that's similar
to the jndi.jar hack).
Revision ChangesPath
1.27 +6 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Bootstrap.java
Index: Bootstrap.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Bootstrap.java,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- Bootstrap.java2001/09/13 14:26:18 1.26
+++ Bootstrap.java2001/09/20 23:46:27 1.27
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Bootstrap.java,v
1.26 2001/09/13 14:26:18 glenn Exp $
- * $Revision: 1.26 $
- * $Date: 2001/09/13 14:26:18 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Bootstrap.java,v
1.27 2001/09/20 23:46:27 remm Exp $
+ * $Revision: 1.27 $
+ * $Date: 2001/09/20 23:46:27 $
*
*
*
@@ -85,7 +85,7 @@
* class path and therefore not visible to application level classes.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.26 $ $Date: 2001/09/13 14:26:18 $
+ * @version $Revision: 1.27 $ $Date: 2001/09/20 23:46:27 $
*/
public final class Bootstrap {
@@ -275,6 +275,8 @@
if (!filename.endsWith(.jar))
continue;
if ((!loadJNDI) filename.equals(jndi.jar))
+continue;
+if ((!loadJNDI) filename.equals(ldap.jar))
continue;
if (filename.equals(bootstrap.jar))
continue;
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util ProcessHelper.java
remm01/09/20 16:48:13
Modified:catalina/src/share/org/apache/catalina/servlets
CGIServlet.java
catalina/src/share/org/apache/catalina/util
ProcessHelper.java
Log:
- Javadoc errors make Jon nervous (fix for bug 3681).
Revision ChangesPath
1.7 +10 -9
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
Index: CGIServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- CGIServlet.java 2001/08/20 02:42:11 1.6
+++ CGIServlet.java 2001/09/20 23:48:13 1.7
@@ -1,6 +1,6 @@
/*
- * CGIServlet.java $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java,v
1.6 2001/08/20 02:42:11 amyroh Exp $
- * $Revision: 1.6 $, $Date: 2001/08/20 02:42:11 $
+ * CGIServlet.java $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java,v
1.7 2001/09/20 23:48:13 remm Exp $
+ * $Revision: 1.7 $, $Date: 2001/09/20 23:48:13 $
*
*
*
@@ -283,7 +283,7 @@
*
* @author Martin T Dengler [[EMAIL PROTECTED]]
* @author Amy Roh
- * @version $Revision: 1.6 $, $Date: 2001/08/20 02:42:11 $
+ * @version $Revision: 1.7 $, $Date: 2001/09/20 23:48:13 $
* @since Tomcat 4.0
*
*/
@@ -642,7 +642,7 @@
try {
ServletOutputStream out = res.getOutputStream();
out.println(HTMLHEADTITLE$Name: $/TITLE/HEAD);
-out.println(BODY$Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java,v
1.6 2001/08/20 02:42:11 amyroh Exp $p);
+out.println(BODY$Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java,v
1.7 2001/09/20 23:48:13 remm Exp $p);
if (cgiEnv.isValid()) {
out.println(cgiEnv.toString());
@@ -685,7 +685,7 @@
/** For future testing use only; does nothing right now */
public static void main(String[] args) {
-System.out.println($Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java,v
1.6 2001/08/20 02:42:11 amyroh Exp $);
+System.out.println($Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java,v
1.7 2001/09/20 23:48:13 remm Exp $);
}
@@ -701,7 +701,7 @@
* /p
*
* @author Martin Dengler [[EMAIL PROTECTED]]
- * @version $Revision: 1.6 $, $Date: 2001/08/20 02:42:11 $
+ * @version $Revision: 1.7 $, $Date: 2001/09/20 23:48:13 $
* @sinceTomcat 4.0
*
*/
@@ -1323,7 +1323,7 @@
* /p
*
* @authorMartin Dengler [[EMAIL PROTECTED]]
- * @version $Revision: 1.6 $, $Date: 2001/08/20 02:42:11 $
+ * @version $Revision: 1.7 $, $Date: 2001/09/20 23:48:13 $
*/
protected class CGIRunner {
@@ -1507,10 +1507,11 @@
* /UL
* /p
*
+ * For more information, see java.lang.Runtime#exec(String command,
+ * String[] envp, File dir)
+ *
* @exception IOException if problems during reading/writing occur
*
- * @seejava.lang.Runtime#exec(String command, String[] envp,
- *File dir)
*/
protected void run() throws IOException {
1.3 +6 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/ProcessHelper.java
Index: ProcessHelper.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/ProcessHelper.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ProcessHelper.java2001/07/22 20:25:13 1.2
+++ ProcessHelper.java2001/09/20 23:48:13 1.3
@@ -1,6 +1,6 @@
/*
- * ProcessHelper.java $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/ProcessHelper.java,v
1.2 2001/07/22 20:25:13 pier Exp $
- * $Revision: 1.2 $, $Date: 2001/07/22 20:25:13 $
+ * ProcessHelper.java $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/ProcessHelper.java,v
1.3 2001/09/20 23:48:13 remm Exp $
+ * $Revision: 1.3 $, $Date: 2001/09/20 23:48:13 $
*
*
*
@@ -123,7 +123,7 @@
* /p
*
* @authorMartin Dengler
DO NOT REPLY [Bug 3681] - javadoc errors
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3681. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3681 javadoc errors [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2001-09-20 16:54 --- Fixed.
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startupBootstrap.java
On 20 Sep 2001 [EMAIL PROTECTED] wrote: Date: 20 Sep 2001 23:46:27 - From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup Bootstrap.java remm01/09/20 16:46:27 Modified:catalina/src/share/org/apache/catalina/startup Bootstrap.java Log: - Don't load ldap.jar if the system CL has the LDAP classes already (that's similar to the jndi.jar hack). I was just in the process of generalizing this to a class loader factory that can automatically skip JAR files that contain any class from a list of trigger class names. That way, we can also ensure consistency across class loaders that are created by Bootstrap, BootstrapService, Catalina, and CatalinaService, without using a hack. Craig
DO NOT REPLY [Bug 3695] - Do not add ldap.jar to class path on JDK 1.3 or later
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3695. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3695 Do not add ldap.jar to class path on JDK 1.3 or later [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2001-09-20 16:53 --- Fixed (in HEAD).
DO NOT REPLY [Bug 3698] - ServletContext.getRealPath() no longer adds trailing slash to result.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3698. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3698 ServletContext.getRealPath() no longer adds trailing slash to result. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2001-09-20 16:02 --- The spec for ServletContext.getRealPath() says: Returns a String containing the real path for a given virtual path. ... The real path will be in a form appropriate to the computer and operating system on which the servlet container is running, including the appropriate path separators. It seems to me that the current behavior conforms to this requirement, and that (in fact) the Tomcat 3.2 behavior is incorrect for some operating systems.
DO NOT REPLY [Bug 3754] New: - DataSource Requires Tyrex
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3754. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3754 DataSource Requires Tyrex Summary: DataSource Requires Tyrex Product: Tomcat 4 Version: 4.0 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I'm having some difficulty creating a DataSource using the default Tyrex factory provided in Tomcat 4. In the DefaultContext, I have: ResourceParams name=jdbc/SomeDB parameter nameuser/name valueusername/value /parameter parameter namepassword/name valuepass/value /parameter parameter namedriverClassName/name valuecom.jnetdirect.jsql.JSQLDriver/value /parameter parameter namedriverName/name valuejdbc:JSQLConnect://dbhost/database=somedata/value /parameter /ResourceParams And in my code I: Context initCtx = new InitialContext(); Context envCtx = (Context) initCtx.lookup(java:comp/env); DataSource ds = (DataSource) envCtx.lookup(jdbc/SomeDB); Connection conn = ds.getConnection(); However, at runtime, I get the following error on the third line of the above code fragment: java.lang.ClassCastException: tyrex.jdbc.xa.EnabledDataSource If I change DataSource to EnabledDataSource, and import the appropriate Tyrex class, then things work perfectly, as expected, but shouldn't I be able to cast an EnabledDataSource to a DataSource? I do not have the Tyrex jar in my classpath at compile time, and I don't believe I should have to. I recognize this is probably a defect in Tyrex itself, but this certainly affects Tomcat's usability, and even it's specification compliance, from what I can tell.
DO NOT REPLY [Bug 3736] - incorrect PathInfo on first invocation of servlet chain
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3736. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3736 incorrect PathInfo on first invocation of servlet chain [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2001-09-20 16:42 --- I think it's fixed now (in the HEAD branch). We should add a test case for it.
DO NOT REPLY [Bug 3739] - custom tag support error
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3739. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3739 custom tag support error --- Additional Comments From [EMAIL PROTECTED] 2001-09-20 14:32 --- Yea, there is an error in the test foo.jsp. The line %@ taglib uri=http://jakarta.apache.org/tomcat/debug-taglib; prefix=d% should be removed.
DO NOT REPLY [Bug 3725] - Drive letter required for absolute paths under Windows
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3725. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3725 Drive letter required for absolute paths under Windows [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2001-09-20 14:32 --- It's not appropriate for Tomcat to second guess what the JDK determines is a relative path.
DO NOT REPLY [Bug 3736] - incorrect PathInfo on first invocation of servlet chain
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3736. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3736 incorrect PathInfo on first invocation of servlet chain [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2001-09-20 14:38 --- Your examples are using request URIs that utilize the Tomcat invoker servlet. Because invoker service is *not* defined in the servlet specification, there are no requirements for how it is to behave. In particular, in Tomcat, the invoker is mapped to /servlet/*. The very first time a request for servlet S3 is processed (say /servlet/S3/path/info), the invoker servlet will create a *new* servlet definition for this servlet dynamically, and map it to /servlet/S3/* for all future requests. However, at the moment your filter is called, this has not happened yet (because your filter is called before the invoker servlet). Therefore, your filter will see the servlet path set to /servlet and extra path info set to /S3/path/info on the very first request. This is exactly what the Servlet Specification requires, and cannot be changed. If you want consistent results even on the first request, you should explicitly map your servlet to a particular mapping pattern. That way, your filter will always get consistent results (and your application will also be portable to other servlet containers, which it is not right now).
DO NOT REPLY [Bug 3736] - incorrect PathInfo on first invocation of servlet chain
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3736. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3736 incorrect PathInfo on first invocation of servlet chain --- Additional Comments From [EMAIL PROTECTED] 2001-09-20 14:42 --- Oops, ignore the previous comment -- it was intented for a very similar report that was using a filter chain. Let me do a little more looking -- I will reopen this if needed.
DO NOT REPLY [Bug 3736] - incorrect PathInfo on first invocation of servlet chain
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3736. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3736 incorrect PathInfo on first invocation of servlet chain [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2001-09-20 14:43 --- Reopen during investigation so that this bug doesn't disappear.
DO NOT REPLY [Bug 3755] New: - freezes at shutdown
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3755. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3755 freezes at shutdown Summary: freezes at shutdown Product: Tomcat 4 Version: 4.0 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] After execution shutdown script, tomcat display shutdown request, but never ends. Last line in log looks like: 2001-09-18 13:18:35 StandardHost[localhost]: Removing web application at context path /ChatHouse 2001-09-18 13:18:35 StandardWrapper[/ChatHouse:ChatHouse]: Waiting for 4 instance(s) to be deallocated web application war available at: http://tjws.sourceforge.net/download/ChatHouse.war
DO NOT REPLY [Bug 3740] - simple javabeans problem
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3740. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3740 simple javabeans problem [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2001-09-20 14:58 --- Fixed. Thanks for the report.
DO NOT REPLY [Bug 3752] - JspFactory.getDefaultFactory().getPageContext returns always null
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3752. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3752 JspFactory.getDefaultFactory().getPageContext returns always null [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2001-09-20 15:03 --- The JspFactory.getDefaultFactory() method will only return a non-null result if someone has called JspFactory.setDefaultFactory() to set it. In Tomcat, this only happens automatically for JSP pages themselves, so it won't work in an arbitrary servlet. And I don't see any spec requirement that it is supposed to.
DO NOT REPLY [Bug 3727] - Switched included request parameters
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727 Switched included request parameters --- Additional Comments From [EMAIL PROTECTED] 2001-09-20 17:53 --- Since you have a servlet-mapping for /*, Tomcat's values are exactly what you would expect them to be.
cvs commit: jakarta-tomcat-4.0/catalina build.xml
remm01/09/20 17:50:24
Modified:.build.properties.sample
catalina build.xml
Log:
- Add flag for Ant style task.
- Add copy JSSE (which doesn't do anything siince we can't redistribute JSSE).
- Reorganize a bit the target hierarchy (some were executed multiple times).
- Display flags by default (define a flags.hide variable to hide them).
Revision ChangesPath
1.13 +2 -1 jakarta-tomcat-4.0/build.properties.sample
Index: build.properties.sample
===
RCS file: /home/cvs/jakarta-tomcat-4.0/build.properties.sample,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- build.properties.sample 2001/09/19 20:49:23 1.12
+++ build.properties.sample 2001/09/21 00:50:23 1.13
@@ -6,7 +6,7 @@
# modules that Tomcat depends on. Copy this file to build.properties
# in the top-level source directory, and customize it as needed.
#
-# $Id: build.properties.sample,v 1.12 2001/09/19 20:49:23 remm Exp $
+# $Id: build.properties.sample,v 1.13 2001/09/21 00:50:23 remm Exp $
# -
@@ -19,6 +19,7 @@
# - Build Control Flags
#full.dist=on
#build.sysclasspath=ignore
+#flags.hide=on
# - Default Base Path for Dependent Packages -
1.65 +35 -10jakarta-tomcat-4.0/catalina/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/build.xml,v
retrieving revision 1.64
retrieving revision 1.65
diff -u -r1.64 -r1.65
--- build.xml 2001/09/19 20:51:11 1.64
+++ build.xml 2001/09/21 00:50:24 1.65
@@ -73,6 +73,10 @@
classname=java.lang.reflect.Proxy /
available property=jdk.1.4.present classname=java.nio.Buffer /
+!-- Ant flags --
+available property=style.available
+ classname=org.apache.tools.ant.taskdefs.optional.TraXLiaison /
+
!-- Class availability flags --
condition property=javamail.present
and
@@ -130,7 +134,10 @@
/and
/condition
available property=jdbc20ext.jar.present file=${jdbc20ext.jar} /
+available property=jcert.jar.present file=${jcert.jar} /
available property=jndi.jar.present file=${jndi.jar} /
+available property=jnet.jar.present file=${jnet.jar} /
+available property=jsse.jar.present file=${jsse.jar} /
available property=jta.jar.present file=${jta.jar} /
available property=junit.jar.present file=${junit.jar} /
available property=ldap.jar.present file=${ldap.jar} /
@@ -244,6 +251,19 @@
/and
/or
/condition
+condition property=copy.jsse.jar
+ or
+equals arg1=${full.dist} arg2=on /
+and
+ equals arg1=${jcert.jar.present} arg2=true /
+ equals arg1=${jnet.jar.present} arg2=true /
+ equals arg1=${jsse.jar.present} arg2=true /
+ not
+equals arg1=${jdk.1.4.present} arg2=true /
+ /not
+/and
+ /or
+/condition
condition property=copy.tyrex.jar
or
equals arg1=${full.dist} arg2=on /
@@ -255,7 +275,7 @@
!-- === BUILD: Set compile flags === --
- target name=flags.display depends=flags
+ target name=flags.display depends=flags unless=flags.hide
echo message=--- Build environment for Catalina --- /
@@ -268,6 +288,9 @@
echo message=compile.deprecation=${compile.deprecation} /
echo message=compile.optimize=${compile.optimize} /
+echo message=--- Ant Flags --- /
+echo message=lt;stylegt; task available (required)=${style.available} /
+
echo message=--- JDK --- /
echo message=jdk.1.2.present=${jdk.1.2.present} /
echo message=jdk.1.3.present=${jdk.1.3.present} /
@@ -320,7 +343,7 @@
/target
!-- === BUILD: Create Directories == --
- target name=build-prepare depends=flags
+ target name=build-prepare
mkdir dir=${catalina.build}/
mkdir dir=${catalina.build}/bin/
@@ -352,10 +375,17 @@
copy todir=${catalina.build}/common/lib file=${jta.jar}/
/target
target name=copy-ldap.jar if=copy.ldap.jar
-!-- Licensing issue: don't copy ldap.jar
+!-- Cannot redistribute LDAP
copy todir=${catalina.build}/common/lib file=${ldap.jar}/
--
/target
+ target name=copy-jsse.jar if=copy.jsse.jar
+!-- Cannot redistribute JSSE
+copy todir=${catalina.build}/common/lib file=${jcert.jar}/
+copy todir=${catalina.build}/common/lib file=${jnet.jar}/
+copy todir=${catalina.build}/common/lib file=${jsse.jar}/
+--
+ /target
target
3.3 Client Authentication Status?
I had something urgent come up at the D.D.J. over the past few days, and now I've naturally got hundreds of e-mails to sort through =) Anyway, can someone quick fill me in on the status update on Client Authetication in 3.3? I've seen a few patch e-mails and such, so does that mean you tough guys already fixed it? Let me know if I can still be of any help, now that I'm back to the land of the living. I even managed to convert an X509 so that I could get it into Nutscrape, just in case ;-) - Christopher /** * Pleurez, pleurez, mes yeux, et fondez vous en eau! * La moitié de ma vie a mis l'autre au tombeau. *---Corneille */
cvs commit: jakarta-tomcat/src/native/mod_jk/iis jk_isapi_plugin.c
larryi 01/09/20 19:58:17
Modified:src/native/mod_jk/iis jk_isapi_plugin.c
Log:
Patch to include the certificate data for ssl requests.
Submitted by: Ignacio J. Ortega
Lifted a Base64 encoder routine from Apache's apr-util and modified it
to Base64 encode the certificate data since IIS supplies straight Der
encoded data.
I couldn't find support for SSL PWS on Win9x. However, isapi_redirect.dll
on Win9x still works for HTTP requests.
Revision ChangesPath
1.7 +107 -2jakarta-tomcat/src/native/mod_jk/iis/jk_isapi_plugin.c
Index: jk_isapi_plugin.c
===
RCS file: /home/cvs/jakarta-tomcat/src/native/mod_jk/iis/jk_isapi_plugin.c,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- jk_isapi_plugin.c 2001/09/13 01:49:51 1.6
+++ jk_isapi_plugin.c 2001/09/21 02:58:16 1.7
@@ -57,9 +57,12 @@
* Description: ISAPI plugin for IIS/PWS *
* Author: Gal Shachor [EMAIL PROTECTED] *
* Author: Ignacio J. Ortega [EMAIL PROTECTED] *
- * Version: $Revision: 1.6 $ *
+ * Version: $Revision: 1.7 $ *
***/
+// This define is needed to include wincrypt,h, needed to get client certificates
+#define _WIN32_WINNT 0x0400
+
#include httpext.h
#include httpfilt.h
#include wininet.h
@@ -179,6 +182,13 @@
DWORD bufsz,
char *def_val);
+static int base64_encode_cert_len(int len);
+
+static int base64_encode_cert(char *encoded,
+ const unsigned char *string,
+ int len);
+
+
static int uri_is_web_inf(char *uri)
{
char *c = uri;
@@ -913,6 +923,7 @@
for(i = 0 ; i 9 ; i++) {
GET_SERVER_VARIABLE_VALUE(ssl_env_names[i], ssl_env_values[i]);
if(ssl_env_values[i]) {
+ jk_log(logger, JK_LOG_DEBUG, SSL vars %s:%s.\n,
ssl_env_names[i], ssl_env_values[i]);
num_of_vars++;
}
}
@@ -933,6 +944,28 @@
}
}
s-num_attributes = num_of_vars;
+ if (ssl_env_values[4] ssl_env_values[4][0] == '1') {
+ CERT_CONTEXT_EX cc;
+ DWORD cc_sz = sizeof(cc);
+ cc.cbAllocated = sizeof(huge_buf);
+ cc.CertContext.pbCertEncoded = (BYTE*) huge_buf;
+ cc.CertContext.cbCertEncoded = 0;
+
+ if
(private_data-lpEcb-ServerSupportFunction(private_data-lpEcb-ConnID,
+
(DWORD)HSE_REQ_GET_CERT_INFO_EX,
+
(LPVOID)cc,NULL,NULL) != FALSE)
+ {
+ jk_log(logger, JK_LOG_DEBUG,Client
Certificate encoding:%d sz:%d flags:%ld\n,
+
cc.CertContext.dwCertEncodingType X509_ASN_ENCODING ,
+
cc.CertContext.cbCertEncoded,
+ cc.dwCertificateFlags);
+s-ssl_cert=jk_pool_alloc(private_data-p,
+
base64_encode_cert_len(cc.CertContext.cbCertEncoded));
+
+s-ssl_cert_len = base64_encode_cert(s-ssl_cert,
+huge_buf,cc.CertContext.cbCertEncoded) - 1;
+ }
+ }
}
}
@@ -1057,4 +1090,76 @@
}
return JK_TRUE;
-}
\ No newline at end of file
+}
+
+static const char begin_cert [] =
+ -BEGIN CERTIFICATE-\r\n;
+
+static const char end_cert [] =
+ -END CERTIFICATE-\r\n;
+
+static const char basis_64[] =
+ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/;
+
+static int base64_encode_cert_len(int len)
+{
+ int n = ((len + 2) / 3 * 4) + 1; // base64 encoded size
+ n += (n + 63 / 64) * 2; // add CRLF's
+ n += sizeof(begin_cert) + sizeof(end_cert) - 2; // add enclosing strings.
+return n;
+}
+
+static int base64_encode_cert(char *encoded,
+ const unsigned char *string, int len)
+{
+int i,c;
+char *p;
+ const char *t;
+
+p = encoded;
+
+ t
Re: TC 3.3: Form authentication vs. Application reloading
[EMAIL PROTECTED] wrote: Hi Bojan, A simpler solution is to fix ReloadInterceptor - and save the current list of interceptors before removing the context, then add all per/context interceptors after the context is added back ( those having getContext() != null ). OK. I'll look into producing a patch along those lines. Just to be clear on what you meant here, if there was, for instance this JDBCRealm local interceptor object, you'd just store its reference ,somewhere else while context is being reloaded and then attach the same object back as an interceptor after the reload is done. I was thinking about that but what if that old instance of the interceptor object relied on something in the old context? That would screw things up. But if that's not the case (ie. there can't be any relationship with the context), it should be fine. Still don't know enough to tell. My understanding is that ContextXmlReader actually produces 'fresh' instances every time. This would deal with other configuration mechanisms as well - ContextXmlReader is not the only way to add contexts, applications embeding tomcat may use API calls as well. Dealing with changes in app.xml is a bit more difficult - and I think the right long-term solution is to consolidate all config modules and create a smart 'deploy tool' module that can take care of all the issues. Sounds good. Bojan
cvs commit: jakarta-tomcat-4.0 BUILDING.txt
ccain 01/09/20 22:20:01 Modified:.BUILDING.txt Log: Minor semantical changes for JDBC 2.0 Opt. install instructions. There's nothing to unpack, you just get the jar :) Revision ChangesPath 1.6 +3 -4 jakarta-tomcat-4.0/BUILDING.txt Index: BUILDING.txt === RCS file: /home/cvs/jakarta-tomcat-4.0/BUILDING.txt,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- BUILDING.txt 2001/09/17 06:18:57 1.5 +++ BUILDING.txt 2001/09/21 05:20:01 1.6 @@ -1,4 +1,4 @@ -$Id: BUILDING.txt,v 1.5 2001/09/17 06:18:57 ccain Exp $ +$Id: BUILDING.txt,v 1.6 2001/09/21 05:20:01 ccain Exp $ Building The Tomcat 4.0 Servlet/JSP Container @@ -138,14 +138,13 @@ distribution resides in its own directory. -(6) Download and Install JDBC Optional Package API +(6) Download and Install JDBC Optional Package API Binary Distribution * Download the JDBC Optional Pacakge API package (version 2.0) from: http://java.sun.com/products/jdbc/download.html -* Unpack the package into a convenient location so that it resides - in its own subdirectory. +* Place the jar in a convenient location. (7) Download and Install the JMX 1.0 Reference Implementation
datasource
hi, i am encountering naming exception, null exception etc. i am using tomcat 3.3 ver and my application is from a servlet i have to display records from a databse table (db2) using data source. i am using ibm visual age for java tool. i hope i'll get good reponse in this regard. thanks and regards challa Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie
