Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm RealmBase.java
N.B. The Filter mapping code looks broken to me. It looks like if I have a mapping for a url-pattern '*.jsp' that has dispatcherINCLUDE/dispatcher, then it will incorrectly match a jsp:include page=header.jspf /. However, I haven't actually tested it. :). Bill Barker [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, December 11, 2003 1:40 AM Subject: Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm RealmBase.java [EMAIL PROTECTED] wrote: billbarker2003/12/10 21:50:39 Modified:catalina/src/share/org/apache/catalina Realm.java catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java catalina/src/share/org/apache/catalina/realm RealmBase.java Log: First attempt to get Tomcat compliant with the Servlet 2.4 Spec for AA. This one isn't very efficient (but not much worse than it was before :). Longer term, I'm looking to modify the j-t-c mapper to be able to return a Collection of mapped objects, and use that. In that case it could also be used for Filter mappings. Filter mapping is simple, and should be efficient enough right now. It was really horrible in 4.1.x (except if somehow all filters are mapped to /* or the exact path :-D), and is obviously used a lot more in 5.0.x, so I did fix it. I was planning to use something fancy when I noticed the requirements for this algorithm: - we have try all the mappings in order, which voids any possible optimization - I think we only have a String at our disposal for filter mapping: getting a char array would remove any performance benefit - we don't have to generate any paths or similar stuff from the mapping results - there was this regionMatches method in String that could do that matching test efficiently And the profiler seems happy :) Maybe it's lying though. For the contraint mapping, since we also have to test them all and return yes/no for each, I recommend using a similar custom algorithm. I see your point on char array. I'll probably leave it as Strings. I'll also look at the Filter mapping code. However, the entire point of the exercise is that we *don't* have to test all of the security-constraints. If I have a security-constriaint with a url-pattern/protected/*/url-pattern, and another one with url-pattern*.jsp/url-pattern, then for a request to /myapp/protected/index.jsp, only the first constraint is checked. If you don't believe me, read 12.8.3 ;-). This version is just to get a Spec compliant version out there that can be tested. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm RealmBase.java
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Thursday, December 11, 2003 11:55 PM
Subject: Re: cvs commit:
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm
RealmBase.java
Remy Maucherat wrote:
Bill Barker wrote:
N.B. The Filter mapping code looks broken to me. It looks like if I
have a
mapping for a url-pattern '*.jsp' that has
dispatcherINCLUDE/dispatcher,
then it will incorrectly match a jsp:include page=header.jspf /.
However, I haven't actually tested it. :).
I think there's an extra check for that case (this problem existed
previously). I'll check.
I confirm that revision 1.10 of the filter factory fixed this.
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/cor
e/ApplicationFilterFactory.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -r1.9 -r1.10
292c292,294
(period != requestPath.length() - 1)) {
---
(period != requestPath.length() - 1)
((requestPath.length() - period)
== (testPath.length() - 1))) {
So it compares the two extensions length, and was bug 22546.
So it does. Apologies for misreading the code (and wasting your time). And
it seems that through the magic of cut-and-paste, I've got the exact same
logic in the current security-constraint code ;).
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message is intended only for the use of the person(s) listed above as the
intended recipient(s), and may contain information that is PRIVILEGED and
CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or
distribute this message or any attachment. If you received this communication in
error, please notify us immediately by e-mail and then delete all copies of this
message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the
Internet is not secure. Do not send confidential or sensitive information, such as
social security numbers, account numbers, personal identification numbers and
passwords, to us via ordinary (unencrypted) e-mail.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AbstractMethodError
You could try asking on the users list for more info. TC 3.2.x has been unsupported for a very long time. The only advice I can offer is to upgrade to a supported version of Tomcat (e.g. 3.3.x, 4.1.x, 5.0.x). - Original Message - From: Katalin Fónagy (IJ/ETH) [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 10, 2003 3:04 AM Subject: AbstractMethodError Hi, I am writing in connection with tomcat. I would like to use openorb-1.3.1 on linux. But the servlet (it is started through tomcat) cannot work. The following error msg appears: Location: /Toolbox/servlet/ToolboxGenerator Internal Servlet Error: java.lang.AbstractMethodError at org.openorb.CORBA.kernel.Configurator.handleXMLImport(Unknown Source) at org.openorb.CORBA.kernel.Configurator.(Unknown Source) at org.openorb.CORBA.kernel.OpenORBLoader.init(Unknown Source) at org.openorb.CORBA.ORB.set_parameters(Unknown Source) at org.omg.CORBA.ORB.init(ORB.java:324) at se.ericsson.lmc.Toolbox.LoginManager.getOrb(LoginManager.java:44) at se.ericsson.lmc.Toolbox.LoginManager.(LoginManager.java:58) at se.ericsson.lmc.Toolbox.ToolboxGenerator.service(ToolboxGenerator.java:111) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:405) at org.apache.tomcat.core.Handler.service(Handler.java:287) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:81 2) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:758) at org.apache.tomcat.service.connector.Ajp12ConnectionHandler.processConnection (Ajp12ConnectionHandler.java:166) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:501) at java.lang.Thread.run(Thread.java:479) The appropriate jar files are in the classpath of tomcat: logkit.jar, avalon-framework.jar, openorb-1.3.1.jar, xerces.jar I suspect other class and method is called instead of the one being in xerces.jar (If parser.jar is before xerces.jar in the CLASSPATH, then NoSuchMethodError is written ) thank you for the help in advance: Katalin Fonagy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm RealmBase.java
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, December 11, 2003 1:40 AM Subject: Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm RealmBase.java [EMAIL PROTECTED] wrote: billbarker2003/12/10 21:50:39 Modified:catalina/src/share/org/apache/catalina Realm.java catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java catalina/src/share/org/apache/catalina/realm RealmBase.java Log: First attempt to get Tomcat compliant with the Servlet 2.4 Spec for AA. This one isn't very efficient (but not much worse than it was before :). Longer term, I'm looking to modify the j-t-c mapper to be able to return a Collection of mapped objects, and use that. In that case it could also be used for Filter mappings. Filter mapping is simple, and should be efficient enough right now. It was really horrible in 4.1.x (except if somehow all filters are mapped to /* or the exact path :-D), and is obviously used a lot more in 5.0.x, so I did fix it. I was planning to use something fancy when I noticed the requirements for this algorithm: - we have try all the mappings in order, which voids any possible optimization - I think we only have a String at our disposal for filter mapping: getting a char array would remove any performance benefit - we don't have to generate any paths or similar stuff from the mapping results - there was this regionMatches method in String that could do that matching test efficiently And the profiler seems happy :) Maybe it's lying though. For the contraint mapping, since we also have to test them all and return yes/no for each, I recommend using a similar custom algorithm. I see your point on char array. I'll probably leave it as Strings. I'll also look at the Filter mapping code. However, the entire point of the exercise is that we *don't* have to test all of the security-constraints. If I have a security-constriaint with a url-pattern/protected/*/url-pattern, and another one with url-pattern*.jsp/url-pattern, then for a request to /myapp/protected/index.jsp, only the first constraint is checked. If you don't believe me, read 12.8.3 ;-). This version is just to get a Spec compliant version out there that can be tested. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat authorization handling seems not to function according to Servlet 2.4 Spec
Yes, this looks like it changed between pfd3 to fr :(. Security-constraints now work like 'grants' instead of 'constraints'. IMHO, this make the 2.4 security model all but useless. whine It would be natural to configure something like: security-constraint web-resource-collection web-resource-nameClient Area/web-resource-name url-pattern/clients/*/url-pattern /web-resource-collection auth-constraint !-- Any authenticated user -- role-name*/role-name /auth-constraint /security-constraint security-constraint web-resource-collection web-resource-nameProduct1 Client Area/web-resource-name url-pattern/clients/product1/*/url-pattern /web-resource-collection auth-constraint !-- Any product1 user -- role-nameproduct1/role-name /auth-constraint /security-constraint security-constraint web-resource-collection web-resource-nameProduct2 Client Area/web-resource-name url-pattern/clients/product2/*/url-pattern /web-resource-collection auth-constraint !-- Any product2 user -- role-nameproduct2/role-name /auth-constraint /security-constraint The way the 2.4 spec is written, all authenticated users have access to everything under /myapp/clients/. To get what I want is now a configuration nightmare :(. /whine Now back to fixing things. I sort of like the idea of changing the Realm interface so that 'hasUserDataPermissions' and 'hasResourcePermissions' take a SecurityConstraint []. However, after a GA release, this may be a bit much. Philippe's solution looks a bit over-kill to me, but I'm not going to object if someone wants to commit it. I'm thinking of moving the header-setting stuff out of RealmBase and into AuthenticatorBase. It may cause some custom realms to stop working, but there shouldn't be that many for TC 5 yet :). Of course, I'm volunteering for the code-monkey (copy; Pier) part of this. Since anyway we go is a pretty big change, I just wanted to get a consensus first. Opinions, Comments, Flames? - Original Message - From: philippe.leothaud [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 08, 2003 6:43 PM Subject: Tomcat authorization handling seems not to function according to Servlet 2.4 Spec Hi all, I am new to Tomcat's mailing lists, and I don't really know if this list is the right place for such a post : excuse me if it is not the case. I wonder if I didn't notice something which is not a real bug in Tomcat, as it seems to do exactly what developers want it to do, but more a difference between the implementation of authorization policy (the handling of a Web Application web.xml security-constraint elements) in Tomcat5 and what the Servlet 2.4 Spec says. Example of the problem (from the Tomcat Jsp-examples WebApp) : ?xml version='1.0' encoding='utf-8'? tomcat-users role rolename=tomcat/ role rolename=role1/ role rolename=manager/ role rolename=admin/ user username=tomcat password=tomcat roles=tomcat/ user username=both password=tomcat roles=tomcat,role1/ user username=role1 password=tomcat roles=role1/ user username=admin password=tomcat roles=admin,manager,tomcat/ /tomcat-users tomcat-users.xml security-constraint display-nameExample Security Constraint/display-name web-resource-collection web-resource-nameProtected Area/web-resource-name !-- Define the context-relative URL(s) to be protected -- url-pattern/security/protected/*/url-pattern !-- If you list http methods, only those methods are protected -- http-methodDELETE/http-method http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method /web-resource-collection auth-constraint !-- Anyone with one of the listed roles may access this area -- role-nametomcat/role-name /auth-constraint /security-constraint security-constraint display-nameExample Security Constraint/display-name web-resource-collection web-resource-nameProtected Area/web-resource-name !-- Define the context-relative URL(s) to be protected -- url-pattern/security/protected/*/url-pattern !-- If you list http methods, only those methods are protected -- http-methodDELETE/http-method http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method /web-resource-collection auth-constraint !-- Anyone with one of the listed roles may access this area -- role-namerole1/role-name /auth-constraint /security-constraint !-- Default login configuration uses form-based authentication -- login-config auth-methodFORM/auth-method realm-nameExample Form-Based Authentication Area/realm-name form-login-config form-login-page/security/protected/login.jsp/form-login-page form-error-page/security/protected/error.jsp/form-error-page /form-login-config /login-config !-- Security roles referenced by this web application -- security-role role-namerole1/role-name /security-role
Re: Tomcat authorization handling seems not to function according to Servlet 2.4 Spec
Ok, I take back my whine/. It seems that they have really made a hash out of the security-constraints. Something like Philippe's implementation is required. Section 12.8.3 requires that only the 'best match' constraints are processed, and those in a 'grant' fashion (i.e. you get the least restrictive privilege of the most restrictive constraints). Now you just need to be a rocket-scientist to figure out how your security-constraints work ;-). So in my example below, a request for /myapp/clients/product1/ will only consider the 'product1' constraint, and ignore the constraint for '/clients/*'. If I had added a security-constraint for '*.jsp', then a request for /myapp/clients/product1/index.jsp would use the 'product1' constraint, and ignore the '*.jsp' constraint. Isn't life going to be fun on the user-list ;-). This means that RealmBase.findSecurityConstraints is going to have to change to only pass back the 'best-match' constraints. At least this isn't an interface change. The decision on whether to change the Realm interface, or move the header processing to AuthenticatorBase is still open. - Original Message - From: Bill Barker [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, December 08, 2003 9:00 PM Subject: Re: Tomcat authorization handling seems not to function according to Servlet 2.4 Spec Yes, this looks like it changed between pfd3 to fr :(. Security-constraints now work like 'grants' instead of 'constraints'. IMHO, this make the 2.4 security model all but useless. whine It would be natural to configure something like: security-constraint web-resource-collection web-resource-nameClient Area/web-resource-name url-pattern/clients/*/url-pattern /web-resource-collection auth-constraint !-- Any authenticated user -- role-name*/role-name /auth-constraint /security-constraint security-constraint web-resource-collection web-resource-nameProduct1 Client Area/web-resource-name url-pattern/clients/product1/*/url-pattern /web-resource-collection auth-constraint !-- Any product1 user -- role-nameproduct1/role-name /auth-constraint /security-constraint security-constraint web-resource-collection web-resource-nameProduct2 Client Area/web-resource-name url-pattern/clients/product2/*/url-pattern /web-resource-collection auth-constraint !-- Any product2 user -- role-nameproduct2/role-name /auth-constraint /security-constraint The way the 2.4 spec is written, all authenticated users have access to everything under /myapp/clients/. To get what I want is now a configuration nightmare :(. /whine Now back to fixing things. I sort of like the idea of changing the Realm interface so that 'hasUserDataPermissions' and 'hasResourcePermissions' take a SecurityConstraint []. However, after a GA release, this may be a bit much. Philippe's solution looks a bit over-kill to me, but I'm not going to object if someone wants to commit it. I'm thinking of moving the header-setting stuff out of RealmBase and into AuthenticatorBase. It may cause some custom realms to stop working, but there shouldn't be that many for TC 5 yet :). Of course, I'm volunteering for the code-monkey (copy; Pier) part of this. Since anyway we go is a pretty big change, I just wanted to get a consensus first. Opinions, Comments, Flames? - Original Message - From: philippe.leothaud [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 08, 2003 6:43 PM Subject: Tomcat authorization handling seems not to function according to Servlet 2.4 Spec Hi all, I am new to Tomcat's mailing lists, and I don't really know if this list is the right place for such a post : excuse me if it is not the case. I wonder if I didn't notice something which is not a real bug in Tomcat, as it seems to do exactly what developers want it to do, but more a difference between the implementation of authorization policy (the handling of a Web Application web.xml security-constraint elements) in Tomcat5 and what the Servlet 2.4 Spec says. Example of the problem (from the Tomcat Jsp-examples WebApp) : ?xml version='1.0' encoding='utf-8'? tomcat-users role rolename=tomcat/ role rolename=role1/ role rolename=manager/ role rolename=admin/ user username=tomcat password=tomcat roles=tomcat/ user username=both password=tomcat roles=tomcat,role1/ user username=role1 password=tomcat roles=role1/ user username=admin password=tomcat roles=admin,manager,tomcat/ /tomcat-users tomcat-users.xml security-constraint display-nameExample Security Constraint/display-name web-resource-collection web-resource-nameProtected Area/web-resource-name !-- Define the context-relative URL(s) to be protected -- url-pattern/security/protected/*/url
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, December 02, 2003 8:59 AM Subject: Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java [EMAIL PROTECTED] wrote: jfarcand2003/12/02 08:27:11 Modified:coyote/src/java/org/apache/coyote Request.java ActionCode.java catalina/src/share/org/apache/coyote/tomcat5 CoyoteRequest.java http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: Implement getLocalPort using ActionCode instead of getServerPort. Associate 1 ActionCode for each getXXX method. Please review. I'll have to vote -0 for implementing getLocalPort as mandated in the specification, since I think this is a huge mistake, and the spec authors intention is misinterpreted (or they didn't think about all the consequences of the wording they used, thinking only about the case of a server without any proxies, or using an AJP-like scheme). BTW, I also think your patch has a sky high likelihood of breaking the JK 2 connector ;-) I said it would be ok, yesterday, but I changed my mind, as this looks wrong. If Bill votes -1 to this, I'll change my vote to -1. I'm fine with the patch (although not a great fan of getLocalPort :). The problem is that this call is likely intended to allow users to build URLs to the server. Actually, this won't work, since the server may not be accessible with the connector hostname or port. What actually should be returned is what is in the Host header (HTTP/1.0 is a broken spec, since it can't possibly work when behind a reverse proxy). Otherwise, we're returning completely useless information to the user, and the getLocalPort is simply useless. Users should be using getServerPort to build URLs to the server. The problem with yesterdays patch is that it broke getServerPort (which is defined to be the value of the Host header). I agree that getLocalPort is simply useless, but it's in the spec so we have to implement it :). About the only thing that it is good for is to grant rights to requests coming in on one connector, but not on another (which points to a bad design). Note: Compliant HTTP/1.1 clients must send correct Host header, and proxy servers are not allowed to modify them. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, December 02, 2003 9:47 AM Subject: Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java Jeanfrancois Arcand wrote: Remy Maucherat wrote: [EMAIL PROTECTED] wrote: jfarcand2003/12/02 08:27:11 Modified:coyote/src/java/org/apache/coyote Request.java ActionCode.java catalina/src/share/org/apache/coyote/tomcat5 CoyoteRequest.java http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: Implement getLocalPort using ActionCode instead of getServerPort. Associate 1 ActionCode for each getXXX method. Please review. I'll have to vote -0 for implementing getLocalPort as mandated in the specification, since I think this is a huge mistake, and the spec authors intention is misinterpreted (or they didn't think about all the consequences of the wording they used, thinking only about the case of a server without any proxies, or using an AJP-like scheme). BTW, I also think your patch has a sky high likelihood of breaking the JK 2 connector ;-) Can you explain how? The only changes I did was to remove the code associated with remoteAddr (which was duplicated and useless IMO). I don't see how JK would set the localPort field (since the new action isn't handled yet), so I thought it would always return -1. Maybe I'm wrong, I didn't try it. Yes, the JK connector is going to need some changes to support this. However they should be pretty minor. Make sense.That will also apply to LocalAddr too then. What the specs states is: public java.lang.String getLocalAddr() Returns the Internet Protocol (IP) address of the interface on which the request was received. public int getLocalPort() Returns the Internet Protocol (IP) port number of the interface on which the request was received. I think parsing/using the Host header is the way to go, since it will work with/without proxy. Can I -1 on myself ;-) I don't know, maybe you can talk to the Servlet spec people first to see what they have to say on this issue ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
- Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 01, 2003 12:44 PM Subject: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java jfarcand2003/12/01 12:44:14 Modified:http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: Use the socket info instead of hardcoded value. HttpServletRequest.getLocalPort() is currently broken if the port are not the default one. -1 for the patch. It breaks NATs, proxies, etc. It also breaks the servlet-spec for ServletRequest.getServerPort. This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question on Tomcat 4
The secureCookie attribute was added to 3.3.2 only to allow backwards compatibility with 3.3.1. Like Tomcat 4 and higher, the default is 'true'. It's a pretty small patch: http://cvs.apache.org/viewcvs/jakarta-tomcat/src/share/org/apache/tomcat/mod ules/session/SessionId.java.diff?r1=1.20r2=1.21 if you just want to add the feature to 3.3.1. Like Yoav said, TC 4 and higher always uses secure cookies. - Original Message - From: Shapira, Yoav [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, November 26, 2003 8:37 AM Subject: RE: Question on Tomcat 4 Howdy, Tomcat 4 and later are so different from 3.x. I suggest you do the migration, if only for the speed and feature increases. I don't think there's an attribute called secureCookie in tomcat4, as there is no un-secure mode. Perhaps a tomcat 3 guru like Senor Barker can fill in more information... Yoav Shapira Millennium ChemInformatics -Original Message- From: Eduardo Campoy [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 26, 2003 11:33 AM To: [EMAIL PROTECTED] Cc: Jason Rivard Subject: Question on Tomcat 4 Hello, I am using Tomcat 3.3.1 with Internet Web Application and after doing a ETHICAL HACKING TEST, they discovered a problem in Tomcat session cookie (JSESSIONID). After reading Tomcat 3.3.2 manual , there is a atribute called secureCookie that resolve my issue. BUT tomcat 3.3.2 is not released yet. My question is Does this atribute called secureCookie exist in TOMCAT 4 ? Thanks in advanced Eduardo Campoy Technology Account Manager Novell, THE leading provider of net business solutions Tel - 55 11 3345-3938 Cel - 55 11 9232-7456 AIM - ecampoy sao MSN - [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, November 25, 2003 12:27 AM Subject: Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java [EMAIL PROTECTED] wrote: amyroh 2003/11/24 15:01:22 Modified:http11/src/java/org/apache/coyote/http11 Http11Protocol.java util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java Log: Add getters for all attributes defined in MBeanInfo so getAttribute calls suceed. Rectification: I'll integrate your patch, but it would be best to remove the fields which are duplicated with the thread pool MBean. +1. While I'm totally swamped right now to be able to properly review Amy's original patch, the Endpoint is not the place for doing this type of JMX configs. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LB with mod_jk 2
Remy Maucherat [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi, I got a support question about LB with mod_jk 2 (and I saw posts about that on tomcat-user). Either there's something I don't understand, or the jk2_get_most_suitable_worker method in jk_worker_lb will always return the first worker which is not in an error state (assuming there was no session), causing all requests to be redirected to the first declared worker in a group. So did I miss something, or is the algorithm bad ? My recollection is that the algorithm is bad. Of course, I'm currently of the opinion that mod_jk2 is hopelessly broken, so I don't spend much time there :). At best, it suffers from the same problems as mod_jk if you are using the pre-fork MPM, so it doesn't work at all. mod_jk2 will need to save this to the smem file in order to work with pre-fork. Thanks, Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Justification for URIEncoding addition?
Remy Maucherat [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Larry Isaacs wrote: Hi Remy, Okay, re-reviewed the original 22666 thread. To complete this thread, I'll assume the following from RFC2718 is our justification for the new behavior: Unless there is some compelling reason for a particular scheme to do otherwise, translating character sequences into UTF-8 (RFC 2279) [3] and then subsequently using the %HH encoding for unsafe octets is recommended. Tomcat will default to US-ASCII instead of UTF-8 so it won't break too many existing webapps. If there are other parts to this story, I would be interested in learning of them. I'm still concerned that this makes Tomcat less useful by creating deployment problems for webapps that aren't technically broken. However, these issues were covered in the prior e-mail thread (http://www.mail-archive.com/[EMAIL PROTECTED]/msg46479.html), so I'll drop the issue. Thanks. The idea for the change is that there's no compelling reason (except hacking) to have one part of the URI be in some encoding (US-ASCII or UTF-8, if you want to have any chance of mapping it successfully), and the rest encoded in something else. There's indeed a bug thread on this issue, and I was on your side at first. +1 (For Remy) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] New committer: Mark Thomas
+1 - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, November 20, 2003 1:19 PM Subject: [VOTE] New committer: Mark Thomas Hi, I'd like to nominate Mark Thomas as a Tomcat committer. He has contibuted a significant amount of fixes already, and does what nobody else does: roam Bugzila to fix older issues and cleanup the database. He has special interest in the WebDAV code, which currently has no maintainer. He has my +1. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote Response.java
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Sunday, November 16, 2003 3:05 AM Subject: Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote Response.java [EMAIL PROTECTED] wrote: billbarker2003/11/15 21:20:23 Modified:coyote/src/java/org/apache/coyote Response.java Log: Restore the ability to explicitly set the charset to iso-latin-1. Now, you won't get the charset unless you ask for it (so no more Content-Type: image/gif; charset=iso-8859-1). However, if you call response.setCharacterEncoding(iso-9959-1), you now get it in the respose. Constants.DEFAULT_CHARACTER_ENCODING is equal to iso-9959-1, so I do not understand how my patch prenvented setting the charset to iso-latin-1. At this point, if we could avoid gratuitous fancy fixes, it would be a lot better ... If I explicitly call response.setCharacterEncoding(iso-8859-1), it means I expect that the charset will be in the Content-Type header. If it is not sent, then non-western-european browsers are likely to mangle my page by using whatever their default encoding is. Of course, iso-latin-1 is just a standard alias for iso-8859-1. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteConnector.java CoyoteRequest.java LocalStrings.properties
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Sunday, November 16, 2003 2:34 AM
Subject: Re: cvs commit:
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5
CoyoteConnector.java CoyoteRequest.java LocalStrings.properties
Bill Barker wrote:
I'm -1 on this. It gives the Servlet no indication that anything is
wrong,
and leaves junk in the input stream for the next keep-alive request. I
think that it would be better to handle this in the Adaptor's
postParseRequest method.
I disagree: the problem with this is that we allocate one array right
away based on content-length, not that there's a big upload (which is
fine).
The Adaptor can check for this:
if(POST.equalsIgnoreCase(request.getMethod())
application/x-www-form-urlencoded.equals(contentType)
request.getContentLength() connector.getMaxPostSize()) {
response.setStatus(413);
response.setMessage(POST Body exceeds maximum);
return false;
}
Obviously, keep-alive is not an option in that case (and Tomcat will
attempt to swallow any remaining output).
Remy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message is intended only for the use of the person(s) listed above as the
intended recipient(s), and may contain information that is PRIVILEGED and
CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or
distribute this message or any attachment. If you received this communication in
error, please notify us immediately by e-mail and then delete all copies of this
message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the
Internet is not secure. Do not send confidential or sensitive information, such as
social security numbers, account numbers, personal identification numbers and
passwords, to us via ordinary (unencrypted) e-mail.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteConnector.java CoyoteRequest.java LocalStrings.properties
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, November 15, 2003 1:45 AM
Subject: cvs commit:
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5
CoyoteConnector.java CoyoteRequest.java LocalStrings.properties
remm2003/11/15 01:45:02
Modified:catalina/src/share/org/apache/coyote/tomcat5
CoyoteConnector.java CoyoteRequest.java
LocalStrings.properties
Log:
- Add a limit to the size of a POST which will be processed using
getParameter
(which does allocate a significant amount of objects).
int len = getContentLength();
if (len 0) {
+if (len ((CoyoteConnector) connector).getMaxPostSize()) {
+log(sm.getString(coyoteRequest.postTooLarge));
+return;
+}
try {
byte[] formData = null;
if (len CACHED_POST_LEN) {
I'm -1 on this. It gives the Servlet no indication that anything is wrong,
and leaves junk in the input stream for the next keep-alive request. I
think that it would be better to handle this in the Adaptor's
postParseRequest method.
This message is intended only for the use of the person(s) listed above as the
intended recipient(s), and may contain information that is PRIVILEGED and
CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or
distribute this message or any attachment. If you received this communication in
error, please notify us immediately by e-mail and then delete all copies of this
message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the
Internet is not secure. Do not send confidential or sensitive information, such as
social security numbers, account numbers, personal identification numbers and
passwords, to us via ordinary (unencrypted) e-mail.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] content-type and charset issues
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, November 11, 2003 7:10 AM Subject: [5.0] content-type and charset issues Hi, Tomcat 5.0 always adds a charset=ISO-8859-1 to the content type. While this is I think relatively legal, it is rather risky (it causes problems with some clients, as I've read on tomcat-user), and very dubious when dealing with non text data. Example: GET /tomcat.gif HTTP/1.0 User-Agent: ApacheBench/1.3d Host: 127.0.0.1 Accept: */* HTTP/1.1 200 OK ETag: W/1934-1068549702000 Last-Modified: Tue, 11 Nov 2003 11:21:42 GMT Content-Type: image/gif;charset=ISO-8859-1 Content-Length: 1934 Date: Tue, 11 Nov 2003 14:59:56 GMT Server: Apache-Coyote/1.1 Connection: close (lol) Maybe Jan's changes to charset handling caused that. If charset is not explicitely added, I think it should not be added to content-type either. What about adding the charset only when contentType.startsWith(text)? A better choice would be when usingWriter is true, but that's not available here. Since Writer output is sent out as iso-latin-1 if the Servlet doen't set the charset, I think that it would be better to add the charset to the header, rather than trust that the browser's default encoding is compatible. Other than that, 5.0.14 looks quite good :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC 5.0.14 Breaks UTF-8 Content via HTTP Header
See inline. - Original Message - From: Tony LaPaso [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, November 10, 2003 8:15 PM Subject: TC 5.0.14 Breaks UTF-8 Content via HTTP Header Hi everyone, It seems a change to TC v5.0.14 may have broken the serving of UTF-8 documents. Specifically, one of the HTTP headers seems wrong. I'd like to describe what I'm seeing TC v5.0.14 compared with v5.0.12. For both v5.0.12 and v5.0.14 I'm running TC as it comes out of the box i.e., with no changes to the default configurations. In both cases I tested with four browsers (IE 5, IE 6, Netscape 7.1 and Firebird 0.7), all on Win 2K. Here's What I Did - In both versions of TC, I added an em dash character to the /tomcat-docs/cgi-howto.html documents that come with the TC documentation. The UTF-8 representation for the em dash character is the three bytes 0xE28094. I also made sure both documents had the following META tag in its head: meta http-equiv='Content-Type' content='text/html; charset=utf-8'/ I then saved the documents as UTF-8 (without a BOM). Finally, I brought the document into a hex editor to check that the em dash was properly encoded as three bytes (which it was). This indicated to me that the document was indeed encoded as UTF-8. Here's What I Saw (TC v5.0.12) -- Under TC v5.0.12, everything looked great using all browsers -- the em dash was rendered correctly. I put a sniffer on the HTTP stream. The v5.0.12 Coyote Connector was sending this HTTP response header: Content-Type: text/html Here's What I Saw (TC v5.0.14) -- Under TC v5.0.14 the em dash character was rendered as *THREE SEPARATE CHARACTERs* (one for each byte). Moreover, putting a sniffer on the HTTP stream indicated the following response header was being sent by the v5.0.14 Coyote Connector: Content-Type: text/html;charset=ISO-8859-1 Aside - For the heck of it I re-saved the v5.0.14 UTF-8 document with a BOM (0xEFBBBF). Doing this made IE correctly render it but Netscape and Firebird still had problems. I'm pretty sure that Unicode says the BOM is optional anyway. Conclusion (?) -- It seems that v5.0.14 of the Coyote Connector is incorrectly sending the wrong response header. I'm not sure what the HTTP spec says *should* be sent for the header if the document's head contains: The spec says nothing about META tags. Tomcat (correctly) treats then as just so much output text. meta http-equiv='Content-Type' content='text/html; charset=utf-8'/ My guess is that either the response header in v5.0.14 needs to be changed to: Content-Type: text/html;charset=UTF-8 or possibly: Content-Type: text/html as it was with TC v5.0.12. Can anyone comment? Is this a TC v5.0.14 bug? It would seem to be. It looks like a 5.0.12 bug, that was subsequently fixed :). The 2.4 Servlet-spec clearly states: spec-quote version=Servlet-2.4-pfd3 section=14.2.22 If no character encoding has been specified, ISO-8859-1 is returned. /spec-quote Thanks, Tony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Vegas Anyone? :-)
Amy Roh [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] ApacheCon 2003 will be held in Las Vegas this November 16-19. Who is going to be there from Tomcat Dev? Maybe we can coordinate Tomcat get together... :-) I have way too much work to stay for the conference :(. But I could drive over if something was planned for the weekend. Amy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Connector ObjectName includes address
- Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 06, 2003 9:05 PM Subject: Re: Connector ObjectName includes address Jan Luehe wrote: Bill Barker wrote: Currently, connector objectname includes address in this format: domain:type=Connector,port=8080,address=0.0.0.0. This causes a problem when IPV6 addresses are used since IPV6 addresses include colons. The javax.management.ObjectName doesn't allow to have colon character in it and this causes javax.management.MalformedObjectNameException: ObjectName: invalid character ':' in value part of property. I propose to exclude address as connector objectname property since port number alone should keep the objectnames unique. What about the case where I have several V-Hosts, each with it's own Connector listening on port 80? This seems a possible use case, but is that really useful ? I would always put the connector at the engine level, personally. Regardless of where you put it, you still have one connector per V-Host IP address. I may be totally off here, but in the most common cases, all your domain names (one for each V-Host) will map to the same IP address, in which case you cannot have more than one Connector listening on the same port (if you do that, you'll get a java.net.BindException when starting the 2nd and so forth Connector). Not quite :-) It is common to have multiple IP addresses - either by using multiple ethernet cards, or by using ifconfig aliases. That's how virtual hosting worked in the old days, and it is still used if you want to support old clients ( or command line / other tools that don't include Host ). For vhost - it is probably valid to have different engines or configs for different vhosts. If the port happens to be 443 instead of 80, then that is still the way it works :-). You can't used NamedVirtualHosts with SSL. I think it would be a bad idea to use only the port ( which will be 80 for most hosts anyway ). If mangling the IPv6 address is not a solution, then we'll need some unique name or something. I'm surprised that this thread has lasted as long as it has. I'd just assumed that Amy would do something like replacing ':' in the address with, say, '%3a', and be done with it. I'm all for mangling the IPv6 address. Costin You can only have more than one Connector listening on the same port when they're listening on different IP addresses on the same server. This is the case we need to resolve, right? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Connector ObjectName includes address
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, November 05, 2003 1:02 AM Subject: Re: Connector ObjectName includes address Bill Barker wrote: Currently, connector objectname includes address in this format: domain:type=Connector,port=8080,address=0.0.0.0. This causes a problem when IPV6 addresses are used since IPV6 addresses include colons. The javax.management.ObjectName doesn't allow to have colon character in it and this causes javax.management.MalformedObjectNameException: ObjectName: invalid character ':' in value part of property. I propose to exclude address as connector objectname property since port number alone should keep the objectnames unique. What about the case where I have several V-Hosts, each with it's own Connector listening on port 80? This seems a possible use case, but is that really useful ? I would always put the connector at the engine level, personally. Regardless of where you put it, you still have one connector per V-Host IP address. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NSAPI and Solaris
AFAIK, IPlanet is still supported. However, there hasn't been an active developer on the project for a very long time, and so there hasn't been anyone to generate the binaries. I would suggest getting the source distro, and compiling yourself. And, unless you plan to offer the binaries back, stop whining. - Original Message - From: James McGovern [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, November 03, 2003 4:16 AM Subject: NSAPI and Solaris Was looking for the binaries for the NSAPI Plugin for IPlanet that supports APJ13 protocol running on Solaris and couldn't find it. Noticed that the Solaris code hasn't been updated in a 1 1/2 years. Is this an unsupported configuration? Are there alternatives? This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Connector ObjectName includes address
- Original Message - From: Amy Roh [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, November 04, 2003 6:01 PM Subject: Connector ObjectName includes address Currently, connector objectname includes address in this format: domain:type=Connector,port=8080,address=0.0.0.0. This causes a problem when IPV6 addresses are used since IPV6 addresses include colons. The javax.management.ObjectName doesn't allow to have colon character in it and this causes javax.management.MalformedObjectNameException: ObjectName: invalid character ':' in value part of property. I propose to exclude address as connector objectname property since port number alone should keep the objectnames unique. What about the case where I have several V-Hosts, each with it's own Connector listening on port 80? Are we using address value from connector objectname anywhere? Thanks, Amy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
Jan Luehe [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Remy, I agree we should help users come up with reasonable config values, but I'm just afraid rejecting any maxThreads 10 or 20 will send the wrong message, as if there was a bug in the way we dispatch incoming requests that requires at least 10 threads. Nope, I disagree. If maxThreads (say) 10, then set it to 10. Allowing broken settings is bad, as there will be people out there who will use them, and then will assume Tomcat is broken. I think changing people's config values behind their backs is not such a good idea in general. I think we should make any maxThreads setting work, as my patch attempts to do, and update the documentation to make users aware of the limitations they will run into when picking a low maxThreads. I think that would be the cleanest solution. The rationale is that there's no point adding complexity and checks into the very critical algorithm, simply to be able to support broken cases. I think we have 2 options: 1. Support any maxThreads setting (including 1, 2, etc.). 2. Reject any maxThreads values that are smaller than some threshold and throw an error. The problem with 2. is that picking a value for the threshold (10? 20?) seems rather arbitrary. Therefore, I think we should do 1. The complexity it is adding is not significant and is well-documented. Please tell me you agree. :) Well, I don't agree :). There is no reason to accept a config value that won't work, and it is cheaper and safer to handle in the config code then in the critical runtime code (although, in this particular case, I admit that the perfomance hit should be minimal). Personally, I would be perfectly happy with an enforced min setting of '2' (but Remy's suggestion is much more practical, given that TC 5 does so much hand-holding already :). As long as the override is logged at WARN level, I don't see any problem with enforcing a minimum. I'm still -1 on this patch at heart, but I could be talked down to an official -0 if enough of the rest of the community thinks that it is useful. Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, October 30, 2003 1:45 PM Subject: Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java [EMAIL PROTECTED] wrote: luehe 2003/10/30 13:01:39 Modified:util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java Log: Fixed problem where if maxThreads is set to 1, ThreadPool.findControlRunnable() will log this error on the first request: SEVERE: All threads (1) are currently busy, waiting. Increase maxThreads (1) or check the servlet status and then block forever -1 for this patch. 1 is obviously a stupid configuration value, so the pool should refuse it. I agree with Remy: The place to check this is ThreadPool. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: http://www.apache.org/dist/jakarta/tomcat-4/source/
Remy has been packaging Jasper in the j-t-4.1.x-src tarball (as jasper). - Original Message - From: jean-frederic clere [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 23, 2003 8:52 AM Subject: http://www.apache.org/dist/jakarta/tomcat-4/source/ Hi, I am playing building binaries of Tomcat: In http://www.apache.org/dist/jakarta/tomcat-4/source/ we only have jakarta-tomcat and jakarta-tomcat-connectors. I think we should add jakarta-tomcat-jasper/jasper2 and jakarta-servletapi-4 otherwise it is quite hard to rebuild a binary from the sources. Comments? Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Coyote Connector logging
- Original Message - From: Glenn Nielsen [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, October 22, 2003 11:39 AM Subject: Re: Coyote Connector logging Remy Maucherat wrote: Glenn Nielsen wrote: The Coyote docs state the following regarding coyote connector logging: Any debugging or exception logging information generated by this Connector will be automatically routed to the Logger that is associated with our related Engine. No special configuration is required to enable this support. But this doesn't seem to work. The Connector is configured in the Service scope and the Logger is configured in the Engine scope. A Service can not have a Logger configured, and an Engine can't have a Connector configured. I see logging output from the Coyote Connector going to the default stdout/stderr Tomcat logs rather than to to the log configured for the Engine. Am I just mistaken, or is the documented logging behaviour broken? As many components, the connector now logs to commons-logging (with categories according to its classname), so this particular page in the docs would need updates :-( Right, I saw that. So how would you configure Coyote to log to the same log as you configured for the Engine in Tomcat 4.1? Change the Engine logging to use c-l? ;-). I don't see that it could be done since none of the components outside of o.a.c.t5 understand anything about Catalina (and I'm strongly -1 to changing this, since it will break 3.3). Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 evolution plan
- Original Message - From: Henri Gomez [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, October 20, 2003 12:53 AM Subject: Re: jk2 evolution plan Glenn Nielsen wrote: +1 I can help out. This is a significant change for a minor revision to 2.0.4, perhaps we should bump it to 2.1 or even 3.0? Since it's an 'internal rewrite', it should stay 2.x, may be 2.1 could be the right name But first we should cleanup all jk2 from #iddef APR defines and custom OS includes. I could get on-board with this, after Mladen's suggestion to change the return-type of most methods to jk_status_t. Without this, mod_jk2 is hopelessly broken (and I'll contunue to ignore it :). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to make CLIENT-CERT protection work?
- Original Message - From: Jan Luehe [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, October 15, 2003 6:38 PM Subject: How to make CLIENT-CERT protection work? Consider the following scenario: 1. Client sends POST request (with content type other than application/x-www-form-urlencoded) to SSL-enabled server (with client auth turned off). 2. Server parses request header, and determines that the resource identified by the request-URI is CLIENT-CERT protected. 3. Server's SSLAuthenticator valve reinitiates SSL handshake, w/ client auth turned on. 4. The server sends its HelloRequest, and expects to read the client's ClientHello. However, what it gets is the POST request's body which hadn't been read yet. 5. SSL handshake fails. In order to avoid this problem, SSLAuthenticator.authenticate() clears the socket in the case of a POST request by reading the POST request's body *before* reinitiating the handshake. To read the POST body, it calls CoyoteRequest.getParameterMap(), which reads and processes the POST body only if the content type equals application/x-www-form-urlencoded. Therefore, the SSL re-handshake works according to plan if the content type equals application/x-www-form-urlencoded, but fails for any other content type. Should we always read the POST body in getParameterMap(), and cache it in a byte[] if content type is different from application/x-www-form-urlencoded, and have CoyoteRequest.getInputStream()/getReader() return wrappers around this byte[]? Any better suggestions? It would probably be better to remove the POST check from SSLAuthenticator, and move it to Http11Processor.action. Then when it is processing ACTION_REQ_SSL_CERTIFICATE, it simply need to add a new InputFilter (say, BufferedInputFilter) that does a full read of the Request data. Thanks, Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf CharChunk.java
+
+// Optimize on a common case.
+// If the source is going to fill up all the space in buffer,
may
+// as well write it directly to the output, and avoid an extra
copy
+if ( len == limit end == 0) {
+out.realWriteChars( src, off, len );
+return;
+}
It should be end == start (although start == 0 is the most common case).
This message is intended only for the use of the person(s) listed above as the
intended recipient(s), and may contain information that is PRIVILEGED and
CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or
distribute this message or any attachment. If you received this communication in
error, please notify us immediately by e-mail and then delete all copies of this
message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the
Internet is not secure. Do not send confidential or sensitive information, such as
social security numbers, account numbers, personal identification numbers and
passwords, to us via ordinary (unencrypted) e-mail.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] System properties in server.xml (and elsewhere)
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Wednesday, October 15, 2003 8:31 AM
Subject: Re: [5.0] System properties in server.xml (and elsewhere)
Henri Gomez wrote:
Do you speak about the ${xxx} properties as present in Tomcat 3.3.x ?
Possibly. Basically, if you have a foo.bar sys property, you can put
${foo.bar} in server.xml, and it will be replaced with the property
value (like in Ant). I didn't know this was present in 3.3.
Yes it was in TC 3.3.1 and you could also set the properties in the
command line if I recall well ;)
http://jakarta.apache.org/tomcat/tomcat-3.3-doc/tomcat-ug.html#configuring_t
omcat
...
In Tomcat 3.3.1, each attribute value may use the ant-style variable
substitution by using ${variable} in the attribute string, i.e.
attribute=text${variable}text.
Let me guess. James did code all that stuff aeons ago, right ? :-D
Well, the aeons ago part is right ;-). But it was the other ant person
(Costin).
The guts of the 3.3 replacement is
o.a.t.u.IntrospectionUtils.replaceProperties, so most of the code is already
in Tomcat 5.
Remy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message is intended only for the use of the person(s) listed above as the
intended recipient(s), and may contain information that is PRIVILEGED and
CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or
distribute this message or any attachment. If you received this communication in
error, please notify us immediately by e-mail and then delete all copies of this
message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the
Internet is not secure. Do not send confidential or sensitive information, such as
social security numbers, account numbers, personal identification numbers and
passwords, to us via ordinary (unencrypted) e-mail.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Digester and external entities with systemId only : Was: Important requirement : Re: [next] What's next ?
You will probably get more traction by posting to commons-dev. While
tomcat-dev still has a couple of commons committers (and, no, I'm not one of
them) that hang out here, its not like the old days :(.
- Original Message -
From: Henri Gomez [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Tuesday, October 14, 2003 12:29 AM
Subject: Digester and external entities with systemId only : Was: Important
requirement : Re: [next] What's next ?
I traced TC 5.0 and Digester and suspect what could be the problem
with external entities when only SYTEM is defined ie :
!ENTITY appset1 SYSTEM appset1.xml
!ENTITY appset2 SYSTEM appset2.xml
In Digester.java, at least in the 1.5 release, resolveEntity return
null if publicId is null even if systemId is set.
To make it works, I just replaced :
--
if (entityURL == null){
return (null);
by ---
if (entityURL == null){
if (systemId == null)
return (null);
else
entityURL = systemId;
}
FYI, in resolveEntity we got as parms for previous app1app2 entities
declaration:
systemid=jndi:/localhost/myapp/WEB-INF/appset1.xml and publicid=null
systemid=jndi:/localhost/myapp/WEB-INF/appset2.xml and publicid=null
This hack will solve the resolution of entities presents in WEB-INF.
Now for entities located outside webapp / WEB-INF.
I know what the spec say about entities outside WAR but there is many
case where you should serve the SAME application for many customers,
and where specific settings for each customer MUST exist outside WAR.
Let see my case :
if the entity is defined like this :
!ENTITY appset1 SYSTEM file:../etc/appset1.xml
!ENTITY appset2 SYSTEM file:/var/www/customer1/etc/appset2.xml
resolveEntity got systemId=file:../etc/appset1.xml and
systemId=file:/var/www/customer1/etc/appset2.xml
So if you have to specify a resource somewhere on your system,
outside the webapp you should :
1) Know what the appBase and use .. trick to get it (relative).
2) Give an absolute reference on the file system, which is bad
when you want to use the .war for many customers.
Let consider the following layout for an ISP/ASP provider wich
use the same application for many clients (running their own TC 5).
/var/www/customer1/etc/appset1.xml
/var/www/customer1/etc/appset2.xml
/var/www/customer1/var/tomcat5/...
/var/www/customer1/var/tomcat5/webapps/themainapp.war
/var/www/customer2/etc/appset1.xml
/var/www/customer2/etc/appset2.xml
/var/www/customer2/var/tomcat5/...
/var/www/customer2/var/tomcat5/webapps/themainapp.war
You could use the file:.. trick to go from
/var/www/customerx/var/tomcat5/, which is the appBase to
/var/www/customerx/etc, where the customer specific settings
are located.
Now consider another layout for an ISP/ASP provider wich
use the same application for many clients but using a shared TC5.
/var/www/customer1/etc/appset1.xml
/var/www/customer1/etc/appset2.xml
/var/www/customer1/webapps/themainapp1.war
/var/www/customer1/webapps/themainapp1/WEB-INF/...
/var/www/customer2/etc/appset1.xml
/var/www/customer2/etc/appset2.xml
/var/www/customer2/webapps/themainapp2.war
/var/www/customer2/webapps/themainapp1/WEB-INF/...
themainapp1.war and themainapp2.war are copy of or symlink to the
generic themainapp.war and are decompressed at startup time.
TC 5 is in shared mode, so it live outside customer layout :
/var/tomcat5/...
You couldn't use anymore the file:.. trick to go from /var/tomcat5/,
which is the appBase to /var/www/customerx/etc, where the customer
specific settings are located.
The only way to developpers and admins to have it works in both case is
to set the current directory when web.xml is parsed to WEB-INF/.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message is intended only for the use of the person(s) listed above as the
intended recipient(s), and may contain information that is PRIVILEGED and
CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or
distribute this message or any attachment. If you received this communication in
error, please notify us immediately by e-mail and then delete all copies of this
message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the
Internet is not secure. Do not send confidential or sensitive information, such as
social security numbers, account numbers, personal identification numbers and
passwords, to us via ordinary (unencrypted) e-mail.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Digester and external entities with systemId only : Was: Important requirement : Re: [next] What's next ?
- Original Message - From: Henri Gomez [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, October 14, 2003 12:42 AM Subject: Re: Digester and external entities with systemId only : Was: Important requirement : Re: [next] What's next ? Bill Barker a écrit : You will probably get more traction by posting to commons-dev. While tomcat-dev still has a couple of commons committers (and, no, I'm not one of them) that hang out here, its not like the old days :(. Sure but Remy has written the Digester so it must still be commiter :-) Off of the top of my head, the following are both Tomcat committers and Commons committers: Remy,Costin,Craig(since, while announced as non-active, I assume that he hasn't removed himself),Mladin,Yoav BTW, I take a look at XmlMapper (the Digester ancestor) and it didn't have problems with SYSTEM only entities - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC 3.3.2-dev and endorsed lib
- Original Message - From: Henri Gomez [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, October 13, 2003 1:28 AM Subject: TC 3.3.2-dev and endorsed lib In TC 4.1.x and 5.0.x there is support for endorsed lib but nothing like this in tc 3.3.2-dev. Since we may have people (including myself), who will have to use SDK 1.4.x with Tomcat 3.3.2, I like to add such feature to Tomcat 3.3.2-dev. It's not really necessary for 3.3.x, since the XML parsing requirements for Tomcat are pretty limited (without looking, we are currently shipping with a jaxp1.x version I believe). I was thinking put the endorsed in lib/endorsed, ie next to lib/common, lib/apps and lib/container. I'm +0 as long as the lib/endorsed directory is empty in the default install. Otherwise, I'm -1. I'll modify run scripts and build for such feature. If a classloader specialist could see if something is required (from TC 4.1 it seems yes). The Tomcat 3.3 ClassLoaders are all delegating loaders (so it is much simpler than the 4.x/5.x case). If you are using a 1.4.x JVM, Tomcat 3.3 will always grap the XML parser from the System ClassLoader (either the one that ships-with, or the endorsed). Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC 3.3.2-dev and endorsed lib
- Original Message - From: Henri Gomez [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, October 13, 2003 2:09 AM Subject: Re: TC 3.3.2-dev and endorsed lib Bill Barker a écrit : - Original Message - From: Henri Gomez [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, October 13, 2003 1:28 AM Subject: TC 3.3.2-dev and endorsed lib In TC 4.1.x and 5.0.x there is support for endorsed lib but nothing like this in tc 3.3.2-dev. Since we may have people (including myself), who will have to use SDK 1.4.x with Tomcat 3.3.2, I like to add such feature to Tomcat 3.3.2-dev. It's not really necessary for 3.3.x, since the XML parsing requirements for Tomcat are pretty limited (without looking, we are currently shipping with a jaxp1.x version I believe). I was thinking put the endorsed in lib/endorsed, ie next to lib/common, lib/apps and lib/container. I'm +0 as long as the lib/endorsed directory is empty in the default install. Otherwise, I'm -1. I'll modify run scripts and build for such feature. If a classloader specialist could see if something is required (from TC 4.1 it seems yes). The Tomcat 3.3 ClassLoaders are all delegating loaders (so it is much simpler than the 4.x/5.x case). If you are using a 1.4.x JVM, Tomcat 3.3 will always grap the XML parser from the System ClassLoader (either the one that ships-with, or the endorsed). Even if we set -Djava.endorsed and fill the directory with the jars we want it to use ? That should work much like it does for 4.1.x/5.0.x (but I haven't tried it :). Once you get out of the WebappClassLoader, the 4.1.x/5.0.x ClassLoaders are delegating CLs. Again, I'm +0 to set the -Djava.endorsed.dir to an empty directory (that the user can copy their favorite xerces version to), and -1 to populate it by default. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote Response.java
+/*
+ * Remove the charset param (if any) from the Content-Type, and
use it
+ * to set the response encoding.
+ * The most recent response encoding setting will be appended
to the
+ * response Content-Type (as its charset param) by
getContentType();
+ */
+int beginCharsetValue = BEGIN_CHARSET_VALUE;
+int beginCharsetParam = contentType.indexOf(;charset=);
+if (beginCharsetParam == -1) {
+beginCharsetParam = contentType.indexOf(; charset=);
+beginCharsetValue++;
+}
Of course, this doesn't work if I do setContentType(text/html;
charset=utf-8);.
+if (beginCharsetParam == -1) {
+// no charset
+this.contentType = contentType;
+return;
+}
This message is intended only for the use of the person(s) listed above as the
intended recipient(s), and may contain information that is PRIVILEGED and
CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or
distribute this message or any attachment. If you received this communication in
error, please notify us immediately by e-mail and then delete all copies of this
message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the
Internet is not secure. Do not send confidential or sensitive information, such as
social security numbers, account numbers, personal identification numbers and
passwords, to us via ordinary (unencrypted) e-mail.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote Response.java
@@ -510,14 +509,19 @@
}
this.contentType = contentType.substring(0, beginCharsetParam);
-String tail = contentType.substring(beginCharsetParam + 1);
+// Trim the semicolon preceding the charset
+int charsetSemi = this.contentType.lastIndexOf(';');
This is still not working for me. Now I can't do stuff like:
setContentType(text/html;charset=utf-8; altcharset=iso-latin-1);
I don't know any current browser that uses this, but it is completely valid
in RFC 2616.
+if (charsetSemi != -1) {
+this.contentType = this.contentType.substring(0,
charsetSemi);
+}
+String tail = contentType.substring(beginCharsetParam);
int nextParam = tail.indexOf(';');
String charsetValue = null;
if (nextParam != -1) {
this.contentType += tail.substring(nextParam);
-charsetValue = tail.substring(beginCharsetValue,
nextParam);
+charsetValue = tail.substring(BEGIN_CHARSET_VALUE,
nextParam);
} else {
-charsetValue = tail.substring(beginCharsetValue);
+charsetValue = tail.substring(BEGIN_CHARSET_VALUE);
}
// The charset value may be quoted, but must not contain any
quotes.
charsetValue = charsetValue.replace('', ' ');
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: TOMCAT-fix for os/390??
Try http://www.apache.org/dist/jakarta/tomcat-4/v4.1.28-alpha/. The 'alpha' is just because it is still in it's evaluation stage. It's likely to graduate to at least beta (if not 'stable'). However, your ability to test it on an os/390 system makes you particularly valuable to the developers, so I hope that you will try it out :). - Original Message - From: [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, October 10, 2003 12:35 AM Subject: Re: Re: TOMCAT-fix for os/390?? Well well ... being a simpleton (=user) I don't quite manage to manage cvs ... I would love to install tomcat 4.1.28 (having 4.1.27), bit I cannot find such a distribution. So what it boils down to if I cannot get 4.1.28 is: install rls 6 BETA - does it go well with JDK 1.3? thank you very much for your help Anna Von: Dirk Verbeeck [EMAIL PROTECTED] Datum: 2003/10/09 Do PM 10:53:59 GMT+02:00 An: Tomcat Developers List [EMAIL PROTECTED] Betreff: Re: TOMCAT-fix for os/390?? Hi Anna I don't use tomcat on os390 but by reading you problem I suspect your problem is solved in cvs, you need at least revision 1.16.2.1 http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-tomcat-connectors/http 11/src/java/org/apache/coyote/http11/InternalOutputBuffer.java?rev=1.16.2.1 or 1.18 http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-tomcat-connectors/http 11/src/java/org/apache/coyote/http11/InternalOutputBuffer.java?rev=1.18 of the following file: http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/InternalOutputBuffer.java Releases including this fix are TOMCAT_5_0_13 http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/http11/src/java/org /apache/coyote/http11/InternalOutputBuffer.java?only_with_tag=TOMCAT_5_0_13 , TOMCAT_5_0_12 http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/http11/src/java/org /apache/coyote/http11/InternalOutputBuffer.java?only_with_tag=TOMCAT_5_0_12 , TOMCAT_4_1_28 http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/http11/src/java/org /apache/coyote/http11/InternalOutputBuffer.java?only_with_tag=TOMCAT_4_1_28 Cheers Dirk Anna Fuhrmann wrote: Hi all, like a good girl I have been using the user-mailing-list up to now to search for user experience installing tomcat on os390. Most (if not all) contributions are in the form has anyone successfully installed tomcat on os390? From some other I got partly valuable ideas. I have been TRYING to get tomcat run on os390 in the last couple of days. Done everything I could - everything seems to be allright up to this pont: tomcat IS running at last without any serious signs of disbehaviour - no error messages at all, xml's behaving well. But if we connect to localhost:tomcatport/index.jsp (or wahtever else for that matter), the browser does not show anything. Doing the same with a perl script shows that the server is ansering and is supplying the requested page, BUT EACH LINE OF THE HTTP_HEADER CONTAINS AN INVALID (i.e.: ebcdic) LINE SEPARATOR. So thats the reason why. Today I tried to identify the .java-file giving us the header (looking for \r\n) . I thought I found it, by my hex.editor did not show me any 0x0d15 (which ought to be the suspect, i.e. Newline in ebcdic). What I would like to know: Is there any kind of patch for os/390? Do you have any suggestions? Is anybody working on it? What should I do? I want to have this beast running. PLEASE. We have os390 2.10 IBM-JDK 1.3 tomcat 4.1.27 Anna Fuhrmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Committing binaries in CVS [Was] RE: cvs commit: jakarta-tomcat-connectors/procrun/bin tomcat.exe tomcatw.exe
- Original Message - From: jean-frederic clere [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, October 10, 2003 12:52 AM Subject: Re: Committing binaries in CVS [Was] RE: cvs commit: jakarta-tomcat-connectors/procrun/bin tomcat.exe tomcatw.exe Remy Maucherat wrote: Ignacio J. Ortega wrote: Hola a todos: (Many time from my last post, things are settling here, so hope i will contribute some code in future :) shields up, nacho will be messing things shortly, now i'm only moderating our lists, and as some person said time ago moderation is to coding what washing dishes is to cooking :)) I know this was discussed before, but i dont really understand why it's needed to have a binary (moreover a win32 binary ) in CVS, and if there isn't a very good reason to do so, i'm against, and if there is a very good reason, i hope i should be applicable to any other binary we produce.. thing that i sincerely doubt .. Sorry to disagree, but it's impossible to build the said binaries without expensive compilers. (please do not suggest Cygwin) Why? Is the Makefile broken? AFAIK, no. It's just that Remy can't publish a version that requires Cygwin. And, as Remy has pointed out, to build a version of procrun that runs under a plain-vanilla install of Windows requires that you have a commercial (read MSVC) compiler. The cost of requiring this is just too high to demand of an O/S project. Now, if someone wants to suggest an O/S C-compiler for Windows that doesn't require Cygwin, I'm all ears :). So -1 to remove them, I need them where they are. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteConnector.java
- Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, October 05, 2003 2:00 PM Subject: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteConnector.java luehe 2003/10/05 14:00:38 Modified:catalina/src/share/org/apache/coyote/tomcat5 CoyoteConnector.java Log: Set the tcpNoDelay property on the underlying socket even if this property has not been set explicitly on CoyoteConnector (in which case the property of the underlying socket is set to TRUE, the default in CoyoteConnector). This restores the behaviour in earlier CoyoteConnector versions and fixes a huge performance degradation. I'm -1 on this. There shouldn't be default properties set from the Connector. If you want the default to be 'true', then change either default it in the Http11Protocol, or change the current default value in PoolTcpEndpoint. This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
- Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, October 04, 2003 11:05 AM Subject: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java remm2003/10/04 11:05:29 Modified:util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java Log: - No bug fix ! - Use the appropriate exception for killing the thread, - Improve ifs. - Replace while + break with a simpler (IMO) if. - Please let me know ASAP if there's a problem. +1 for the patch. But you still need to recycle the connection if the ServerSocket is re-started. This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
- Original Message - From: Bill Barker [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Saturday, October 04, 2003 3:10 PM Subject: Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, October 04, 2003 11:05 AM Subject: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java remm2003/10/04 11:05:29 Modified:util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java Log: - No bug fix ! - Use the appropriate exception for killing the thread, - Improve ifs. - Replace while + break with a simpler (IMO) if. - Please let me know ASAP if there's a problem. +1 for the patch. But you still need to recycle the connection if the ServerSocket is re-started. Never mind. I'm blind today. This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Schedule change
By the way, is there any plan to certify Tomcat 5? As everyone knows, Sun controls the RI now. While it's rumored to be based on Tomcat code, that's not the same thing. Also, as everyone knows, Geronimo is planning to test the Sun/Apache agreement by getting the test-suite under the Sun/Apache agreement to certify them as a JSEE container once they've gotten up and running. I really think that Tomcat should request the test-suite for Servlet 2.4/JSP 2.0. At the very least, it might give Remy something to do while waiting for the specs to go final ;-). Remy Maucherat [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi, The signals I'm getting from Sun about the schedule of the specifications is highly confusing. Since I'm tired of having Tomcat depend on these, I propose taking advantage of the backwards compatibility of the spec, and replacing the TC 5 statement phrase with: The 5.x releases implement the Servlet 2.3 and JSP 1.2 specifications, and will add support for the Servlet 2.4 and JSP 2.0 as soon as they are officially available. That would allow making a timely 5.0 release, rather than expecting stuff for an indefinite amount of time ... If I don't get yelled at too much, I'll call for a vote on this. Comments ? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Schedule change
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, October 01, 2003 12:05 AM Subject: Re: [5.0] Schedule change Bill Barker wrote: By the way, is there any plan to certify Tomcat 5? As everyone knows, Sun controls the RI now. While it's rumored to be based on Tomcat code, that's not the same thing. Also, as everyone knows, Geronimo is planning to test the Sun/Apache agreement by getting the test-suite under the Sun/Apache agreement to certify them as a JSEE container once they've gotten up and running. I really think that Tomcat should request the test-suite for Servlet 2.4/JSP 2.0. At the very least, it might give Remy something to do while waiting for the specs to go final ;-). It sounds like a good idea. Thanks for volunteering ! :-D Great. You give just about the only person on the project that's not in the PMC the job ;-). I'll do my best. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3.2 default HTTP connector ?
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, October 01, 2003 3:13 AM Subject: Re: Tomcat 3.3.2 default HTTP connector ? Henri Gomez wrote: Do you agree to use Coyote2 as the default HTTP connector for Tomcat 3.3.2 ? I think it is a good, idea, but ... What is Coyote1 ? Coyote1 was the Adaptor for Tomcat 3.3 before http11 and jk used a common code base. It's been extinct for a very long time. However, nobody has bothered to change the name back in the modules.xml file, so it's still called Coyote2. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/conf server.xml
- Original Message - From: Henri Gomez [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, October 01, 2003 4:52 AM Subject: Re: cvs commit: jakarta-tomcat-4.0/catalina/src/conf server.xml Remy Maucherat a écrit : Henri Gomez wrote: Remy Maucherat a écrit : Henri Gomez wrote: Urg. Should I back port change to coyote_10 ? I'd prefer using the Coyote HEAD in TC 4.1, I think. I'm sick of all those branches ;-) +1, less branches, less works I'll try to build it, and see if it works. I'll also diff the adapter between the two branches, to see if there aren't any forgotten patches. If it works well, we can try to include that with 4.1.28. I've got a problem to build Tomcat 4.1.27 with an IBM SDK 1.4.1 (so using its own jsse). Missing def com.sun.net.ssl.* ? How could we fix it ? You need the JSSE 1.0.x jar files (the ones for 1.3.x JVMs) to build. Download it and update jsse.home and you should be fine. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3.2 default HTTP connector ?
The only reason I know of not to use the MAIN branch is that it has JMX dependencies. - Original Message - From: Larry Isaacs [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, October 01, 2003 5:08 AM Subject: RE: Tomcat 3.3.2 default HTTP connector ? I have my 3.3.2-dev builds running again. Currently it uses the MAIN branch of JTC to build util and the coyote_10 branch to build coyote/http11. Once upon a time, I thought there was a reason that 3.3.2-dev couldn't use MAIN for coyote. I'm not sure what that reason was or wether it still applies. I'm fine with enabling the HTTP 1.1 connector on 8082. I'll have to think about whether switching 8080 to HTTP 1.1 by default is too big a change for 3.3.2. Cheers, Larry -Original Message- From: Henri Gomez [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 01, 2003 5:53 AM To: Tomcat Developers List Subject: Tomcat 3.3.2 default HTTP connector ? Do you agree to use Coyote2 as the default HTTP connector for Tomcat 3.3.2 ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Schedule change
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, September 30, 2003 11:27 AM Subject: [5.0] Schedule change Hi, The signals I'm getting from Sun about the schedule of the specifications is highly confusing. Since I'm tired of having Tomcat depend on these, I propose taking advantage of the backwards compatibility of the spec, and replacing the TC 5 statement phrase with: The 5.x releases implement the Servlet 2.3 and JSP 1.2 specifications, and will add support for the Servlet 2.4 and JSP 2.0 as soon as they are officially available. That would allow making a timely 5.0 release, rather than expecting stuff for an indefinite amount of time ... If I don't get yelled at too much, I'll call for a vote on this. Comments ? You can be a Servlet 2.3 container, or you can be a Servlet 2.4 container, but not both (see for example, BZ #23525). I agree with Yoav that what people want most from Tomcat 5 is a Servlet 2.4/JSP 2.0 container. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC 3.3.2
- Original Message - From: Henri Gomez [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, September 29, 2003 2:55 AM Subject: TC 3.3.2 Hi to all, I commited the last part of clean imports and started to take a look at bugzilla where many reports seems still open. What's the strategy now ? Should we close those which seems invalid ? Without looking, I believe that most of the open bugs for 3.3 are either for the native connectors (and so are really j-t-c bugs), or for the Http10Interceptor (which we are deprecating/removing). Of course, most of the 91 open Tomcat 3 bugs are for 3.2.x. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Tomcat 4.1 XSS vulnerability
Remy has already patched the HTTP Connector for this one (both Tomcat 45).
I believe that the patch still needs to be ported to the JK2 Connector.
- Original Message -
From: Shapira, Yoav [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Monday, September 29, 2003 11:57 AM
Subject: RE: Jakarta Tomcat 4.1 XSS vulnerability
Howdy,
I'm not a big security buff, but three things come to mind:
- The original post with the exploit is more than a year old, yet we
haven't heard anything about this actually used maliciously -- how come?
- Is it really a vulnerability? What can you get from this exploit?
All I see is tomcat returning a 404 (not found) response with the
javascript specified in the GET request, but javascript is executed on
the client anyhow, so who cares?
- What would the fix be? Not include the requested URL in the default
404 response page?
Yoav Shapira
Millennium ChemInformatics
-Original Message-
From: David Rees [mailto:[EMAIL PROTECTED]
Sent: Monday, September 29, 2003 2:41 PM
To: Tomcat Developers List
Subject: Re: Jakarta Tomcat 4.1 XSS vulnerability
Anyone know how serious this is?
It also appears to affect Tomcat 4.1.27 when using mod_jk as well.
Below
is a sample trace of a HTTP session.
-Dave
telnet localhost 8080
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /666%0a%0ascriptalert(asdf);/script666.jsp HTTP/1.0
Host: localhost
HTTP/1.1 404 /666
scriptalert(asdf);/script666.jsp
Content-Type: text/html;charset=ISO-8859-1
Content-Language: en-US
Date: Mon, 29 Sep 2003 18:39:23 GMT
Server: Apache Coyote/1.0
Connection: close
htmlheadtitleApache Tomcat/4.1.27 - Error
report/titleSTYLE!--H1{font-family : sans-serif,Arial,Tahoma;color
:
white;background-color : #0086b2;} H3{font-family :
sans-serif,Arial,Tahoma;color : white;background-color : #0086b2;}
BODY{font-family : sans-serif,Arial,Tahoma;color :
black;background-color
: white;} B{color : white;background-color : #0086b2;} HR{color :
#0086b2;} --/STYLE /headbodyh1HTTP Status 404 - /666
lt;scriptgt;alert(quot;asdfquot;);lt;/scriptgt;666.jsp/h1HR
size=1 noshadepbtype/b Status report/ppbmessage/b
u/666
lt;scriptgt;alert(quot;asdfquot;);lt;/scriptgt;666.jsp/u/pp
bd
escription/b
uThe requested resource (/666
lt;scriptgt;alert(quot;asdfquot;);lt;/scriptgt;666.jsp) is not
available./u/pHR size=1 noshadeh3Apache
Tomcat/4.1.27/h3/body/htmlConnection closed by foreign host.
On Sun, September 28, 2003 at 3:14 am, Kan Ogawa sent the following
Jakarta Tomcat 4.1 cross-site scripting vulnerability, which was
reported last year, is not yet resolved.
http://www.securityfocus.com/archive/82/288502/2002-08-16/2002-08-22/0
I verified this vulnerability on Tomcat 4.1.27 with Coyote HTTP/1.1
connector.
http://localhost:8080/666%0a%0ascriptalert(asdf);/script666.jsp
On the other hand, on Tomcat 5.0, it was not reproduced.
Do you neglect to resolve it to Tomcat 4.x, Tomcat committers?
Regards,
--
Kan Ogawa
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This e-mail, including any attachments, is a confidential business
communication, and may contain information that is confidential, proprietary
and/or privileged. This e-mail is intended only for the individual(s) to
whom it is addressed, and may not be saved, copied, printed, disclosed or
used by anyone else. If you are not the(an) intended recipient, please
immediately delete this e-mail from your computer system and notify the
sender. Thank you.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message is intended only for the use of the person(s) listed above as the
intended recipient(s), and may contain information that is PRIVILEGED and
CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or
distribute this message or any attachment. If you received this communication in
error, please notify us immediately by e-mail and then delete all copies of this
message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the
Internet is not secure. Do not send confidential or sensitive information, such as
social security numbers, account numbers, personal identification numbers and
passwords, to us via ordinary (unencrypted) e-mail.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Tomcat 4.1 XSS vulnerability
- Original Message - From: David Rees [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, September 29, 2003 12:33 PM Subject: Re: Jakarta Tomcat 4.1 XSS vulnerability On Mon, September 29, 2003 1at 2:32 pm, Bill Barker sent the following Remy has already patched the HTTP Connector for this one (both Tomcat 45). I believe that the patch still needs to be ported to the JK2 Connector. Thanks for the update, Bill. Hope to see Tomcat 4.1.28 out soon, look like we could be seeing it as soon as next week. Ok, that's what I get for working from memory. Actually, Remy's patch is currently only in TC 5. It still needs to be applied to TC 4 (as well as the JK2 Connector for both versions). Thanks, Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Container level authentication
I'm a bit confused by the scope for authentication. For purposes of discussion, assume that there is a sub-section of my web-app that is protected via: security-constraint web-resource-collection web-resource-nameProtected Area/web-resource-name url-pattern/protected/*/url-pattern /web-resource-collection auth-constraint role-namesomerole/role-name /auth-constraint /security-constraint If a user successfully authenticates to access a resource in the 'Protected Area', and then subsequently requests a non-protected page, is the Container required to report (via request.getUserPrincipal/request.getRemoteUser) the authentication information that was used to access the 'Protected Area' for the request to the non-protected page? The remark in section 12.6 that the servlet container is required to track authentication information at the container level (except that this is qualified in the same sentence), and the remark in section 12.10 that a 'null' value for request.getUserPrincipal indicates that a user is logged out, would seem to say that the user needs to be tracked for the entire web-app. However, I'm the first to admit to possibly reading more into this than was intended. I'm asking this, since at the moment Tomcat (and, therefore, presumably the J2EE RI) does not track user authentication for requests to non-authenticated pages. I'm hoping that this issue can be clarified in the final draft of the 2.4 spec. This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk 1.2.5 release : Was: mod_jk does not detect a hung Tomcat
For me, doing a cvs log doesn't mention a 1.2.5 tag. - Original Message - From: Henri Gomez [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, September 25, 2003 12:25 AM Subject: jk 1.2.5 release : Was: mod_jk does not detect a hung Tomcat Did the jk 1.2.5 has been tagged so I could commit my modifications for PING/PONG in jtc ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, September 22, 2003 10:31 PM Subject: Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs Jan Luehe wrote: Currently, any JARs in the classloader delegation chain of a webapp's classloader are scanned for packaged TLDs. This is convenient, as it allows a JAR-packaged taglib to be simply dropped in common/lib and shared by all webapps, rather than requiring each webapp to bundle the taglib in its own WEB-INF/lib. However, scanning all available JARs for TLDs is not very efficient, especially if the names of the JAR-packaged taglibs are known in advance. The proposal is to add a configurable String property (tldJarNames) on Context, which specifies the comma-separated list of JAR file names (without any path info) that must be scanned for TLDs. Catalina will continue to traverse the classloader delegation chain, but only consider those JARs that match the names in the comma-separated list. If a JAR appears more than once in the classloader delegation chain, we will pick its first occurrence. If the tldJarNames property is not set, Catalina will continue to scan all JARs in the classloader delegation chain for TLDs. Comments? Same as Yoav. -0. much pain, no gain. Seeing as how it's already been committed, +0. As Jan has already pointed out, it should improve the startup time for Tomcat 5 (since scanning TLD files is a major hit). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: our attempt to build tomcat 4.1.27 from source on Solaris 2.8
It doesn't look like you got the servletapi-4 project (or it is in the wrong place). Try doing: ant download to make certain that you've got all of the jars you need to build Tomcat. If you are behind a firewall, you'll need to set the values of 'proxy.host' and 'proxy.port' in your build.properties file first. I build Tomcat 4.1.x from source on Solaris pretty regularly, so it definately can be done ;-). Ziying Sherwin [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Dear tomcat Colleagues, We have been trying to build tomcat 4.1.27 from source, which we downloaded from the cvs repository (cvs.apache.org) onto a SPARC computer running Solaris 2.8, using j2sdk 1.4.0. Unfortunately, the installation failed, and we are hoping to find helpful insights to get us back on the road. We have successfully installed the pre-built binary for tomcat, but strongly prefer to build it from source. We posted several messages to the mailing list several weeks ago, asking for help, but received no replies. Here is a detailed summary of what we did, and the outcome. FIrst, we installed the following related packages: ant 1.5.3-1 jaf 1.0.2 Java XML Pack Fall 01 FCS Bundle javamail 1.3 jdbc 2.0 JMX 1.2 JNDI 1.2.1 jsse 1.0.2 jta 1.0.1 xerces 2.4.0 We downloaded the following tomcat modules from the indicated locations: commons-beanutils-1.6.1 (http://www.apache.org/dist/jakarta/commons/beanutils/binaries/commons-beanu tils-1.6.1.tar.gz) commons-collections-2.1 (http://www.apache.org/dist/jakarta/commons/collections/binaries/collections -2.1.tar.gz) commons-digester-1.4.1 (http://www.apache.org/dist/jakarta/commons/digester/binaries/commons-digest er-1.4.1.tar.gz) commons-dbcp-1.0 (http://jakarta.apache.org/builds/jakarta-commons/release/commons-dbcp/v1.0/ commons-dbcp-1.0.zip) commons-fileupload-1.0 (http://www.apache.org/dist/jakarta/commons/fileupload/commons-fileupload-cu rrent.tar.gz) commons-logging-1.0.2 (http://jakarta.apache.org/builds/jakarta-commons/release/commons-logging/v1 .0.2/commons-logging-1.0.2.tar.gz) commons-modeler-1.0 (http://jakarta.apache.org/builds/jakarta-commons/release/commons-modeler/v1 .0/commons-modeler-1.0.tar.gz) commons-pool-1.0.1 (http://jakarta.apache.org/builds/jakarta-commons/release/commons-pool/v1.0. 1/commons-pool-1.0.1.tar.gz) struts (http://jakarta.apache.org/builds/jakarta-struts/release/v1.0.2/jakarta-stru ts-1.0.2.tar.gz) We also obtained the cvs versions of jakarta-tomcat-connectors and jakarta-tomcat-jasper from the jakarta site from which we obtained tomcat. We customized the build properties by editing the file build.properties to reflect the correct paths to all the packages. However, when we started to build the package using command ant dist, we observed the following error messages: build-only: [javac] Compiling 79 source files to /src/tomcat_4.1.27/jasper/build/shared/classes [javac] /src/tomcat_4.1.27/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper /JspC.java:71: package javax.servlet does not exist [javac] import javax.servlet.ServletException; [javac] ^ [javac] /src/tomcat_4.1.27/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper /Options.java:66: package javax.servlet does not exist [javac] import javax.servlet.ServletConfig; [javac] ^ [javac] /src/tomcat_4.1.27/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper /Options.java:67: package javax.servlet does not exist [javac] import javax.servlet.ServletContext; [javac] ^ [javac] /src/tomcat_4.1.27/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper /servlet/JspCServletContext.java:73: package javax.servlet does not exist [javac] import javax.servlet.RequestDispatcher; [javac] ^ [javac] /src/tomcat_4.1.27/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper /servlet/JspCServletContext.java:74: package javax.servlet does not exist [...] /src/tomcat_4.1.27/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper /compiler/JspUtil.java:105: cannot resolve symbol [javac] symbol : class ExpressionEvaluatorImpl [javac] location: class org.apache.jasper.compiler.JspUtil [javac] private static ExpressionEvaluatorImpl expressionEvaluator [javac]^ [javac] /src/tomcat_4.1.27/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper /compiler/JspUtil.java:627: cannot resolve symbol [javac] symbol : class FunctionMapper [javac] location: class org.apache.jasper.compiler.JspUtil [javac]FunctionMapper functionMapper, [javac]^ [javac] Note: Some input files use or override a deprecated API.
Re: [PATCH] Update Tomcat version to 5 in documents
Sorry, they were small, and I missed them. Checked in now. Thanks again! - Original Message - From: Kazuhiro Kazama [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, September 20, 2003 2:47 AM Subject: Re: [PATCH] Update Tomcat version to 5 in documents From: Bill Barker [EMAIL PROTECTED] Subject: Re: [PATCH] Update Tomcat version to 5 in documents Date: Sat, 20 Sep 2003 01:00:59 -0700 Message-ID: [EMAIL PROTECTED] Done. Thanks much! Thanks, Bill! But changes of mbeans-descriptor-howto.xml and realm-howto.xml aren't done. Could you check my changes and apply them to CVS? Kazuhiro Kazama ([EMAIL PROTECTED]) NTT Network Innovation Laboratories - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 12694] - POST requests fail after server failover
I've gone ahead and re-set the previously Resolved bugs back to Resolved. My apologies to the very many people that I've spammed tonight doing this :(. I didn't reset the Assigned field on the grounds that most of the bugs are ancient. - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, September 18, 2003 11:22 PM Subject: Re: DO NOT REPLY [Bug 12694] - POST requests fail after server failover Remy Maucherat wrote: [EMAIL PROTECTED] wrote: 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=12694. 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=12694 POST requests fail after server failover [EMAIL PROTECTED] changed: What|Removed |Added - --- AssignedTo|tomcat- |[EMAIL PROTECTED] |[EMAIL PROTECTED] | Status|RESOLVED|NEW You know, screwing up our bug database is not going to help this project. Please stop this. I blocked the moron by preventing editing of TC 4 bug reports (for now). I assume the loser has a script. That incident, however, makes me think we should at least require registration for doing anything in a bug. (being open, public, and free, is bound to open the door for abuse) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.12 stability rating
- Original Message - From: Hans Bergsten [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, September 17, 2003 8:18 PM Subject: Re: [VOTE] 5.0.12 stability rating Remy Maucherat wrote: ballot [ ] Alpha [x] Beta /ballot I've lost the original message. However, I've finally had time to finish testing, so I'll go for Beta. This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch] wrong rx to invalid url
+1 From me as well.
- Original Message -
From: Keith Wannamaker [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Thursday, September 18, 2003 1:24 PM
Subject: RE: [patch] wrong rx to invalid url
Yes it can be, good catch.
Keith
| -Original Message-
| From: Remy Maucherat [mailto:[EMAIL PROTECTED]
| Sent: Thursday, September 18, 2003 4:07 PM
| To: Tomcat Developers List
| Subject: Re: [patch] wrong rx to invalid url
|
|
| Keith Wannamaker wrote:
|
| I'd like to commit something along these lines to the
| v4 and v5 CoyoteAdaptors:
|
| --- coyote/src/java/org/apache/coyote/tomcat4/CoyoteAdapter.java
16 Mar 2003 01:56:27 - 1.13.2.3
| +++ coyote/src/java/org/apache/coyote/tomcat4/CoyoteAdapter.java
18 Sep 2003 19:45:09 -
| @@ -273,7 +273,13 @@
|
| // URI decoding
| req.decodedURI().duplicate(req.requestURI());
| -req.getURLDecoder().convert(req.decodedURI(), false);
| +try {
| + req.getURLDecoder().convert(req.decodedURI(), false);
| +} catch (IOException ioe) {
| +res.setStatus(400);
| +res.setMessage(Invalid URI);
| +throw new IOException(Invalid URI);
| +}
| req.decodedURI().setEncoding(UTF-8);
|
| // Normalize decoded URI
|
| UDecoder.convert will throw a CharConversionException for
| urls which contain '%' with invalid or no trailing hex digits.
| This exception is ignored and Tomcat is returning a 200 with
| an empty body, which is wrong.
|
| Any suggestions on a better way to correct are welcome.
|
| +1, this seems ok (good thing the request is properly recycled anyway).
| BTW, can't the original ioe be rethrown (this seems simpler) ?
|
| Remy
|
|
|
| -
| To unsubscribe, e-mail: [EMAIL PROTECTED]
| For additional commands, e-mail: [EMAIL PROTECTED]
|
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message is intended only for the use of the person(s) listed above as the
intended recipient(s), and may contain information that is PRIVILEGED and
CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or
distribute this message or any attachment. If you received this communication in
error, please notify us immediately by e-mail and then delete all copies of this
message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the
Internet is not secure. Do not send confidential or sensitive information, such as
social security numbers, account numbers, personal identification numbers and
passwords, to us via ordinary (unencrypted) e-mail.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
- Original Message -
From: Stefan Bodewig [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, September 12, 2003 12:58 AM
Subject: Re: cvs commit:
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net
PoolTcpEndpoint.java
On 12 Sep 2003, [EMAIL PROTECTED] wrote:
+++ PoolTcpEndpoint.java 12 Sep 2003 03:51:36 - 1.16
@@ -389,12 +389,12 @@
if (accepted != null) {
try {
accepted.close();
-accepted = null;
} catch(Exception ex) {
msg = sm.getString(endpoint.err.nonfatal,
accepted, ex);
log.warn(msg, ex);
}
+accepted = null;
}
if( ! running ) return null;
wouldn't it be better to put the accepted = null into a finally
block so you clean up even in the (unlikely but possible) case where
close throws an Error (or Throwable) instead of an Exception?
Wouldn't do anything. The 'accepted' variable is local to the stack-frame,
so it goes away if I throw clear of the method. In this case you just get a
DoS condition where no threads are listening on the ServerSocket. I briefly
thought about changing the catch to 'Throwable', but is it really possible
for Socket.close to throw anything other than an Exception?
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message is intended only for the use of the person(s) listed above as the
intended recipient(s), and may contain information that is PRIVILEGED and
CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or
distribute this message or any attachment. If you received this communication in
error, please notify us immediately by e-mail and then delete all copies of this
message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the
Internet is not secure. Do not send confidential or sensitive information, such as
social security numbers, account numbers, personal identification numbers and
passwords, to us via ordinary (unencrypted) e-mail.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-5 build.properties.default
[EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] remm2003/09/08 02:31:38 Modified:.build.properties.default Log: - New PureTLS version. - I'll be including PureTLS support in 5.0.11+. While I'm +1, this may cause problems since at the moment Tomcat will select PureTLS by default if it is found (on the grounds that you've had to download and install it, so you must want it :). If PureTLS ships with, then there needs to be a big bold instruction in the ssl_howto to select JSSE. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jakarta-tomcat-5.0.9 batch files
Being as lazy as anyone else ;-), we prefer diff files. However, you're script are very nice. I'd prefer that a little more attention was paid to W9x support (since you've got several statements that will bomb on W9x). - Original Message - From: R. W. Stavros, PhD [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 08, 2003 10:35 PM Subject: jakarta-tomcat-5.0.9 batch files Hello, I'm new a tomcat developer and have quite a time trying to get it up and working and to understand what was actually going on in the various batch files that were delivered with jakarta-tomcat-5.0.9. So I have spent some time documenting, formatting, and standardized the batch files. Included are the files that I have done so far. What do I do next?? All errors are marked with a --*** prefix to help differentiate them from other lines. All errors set a return code that is returned upon completion All echo statements start with a -- to help differentiate them from Catalina output All batch files have a Setup, Initialization, Execution, Finalization sections All batch files have a header I've commented each section I've added a help command/action for each file. I've added a verification steps for all env. variables, jars and executables that document what is wrong with error statements and error return codes. R. W. Stavros, Ph.D. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jakarta-tomcat-connectors/util build broke for j2sdk 1.3
It works fine for me. I just did an update on j-t-c, and a clean build of Tomcat 5, and it worked fine (well, up until it got to the docs, but I've still got an old version of xalan in ant :). - Original Message - From: Glenn Nielsen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, September 07, 2003 7:59 PM Subject: jakarta-tomcat-connectors/util build broke for j2sdk 1.3 I can no longer build jakarta-tomcat-connectors/util. It looks like a dependency for java 1.4 has crept in with how jsse is being used. Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Bug 22666
I'd go for 2) personally. If you force the POST parameters to UTF-8 (which I understand is what '3' does), you break almost every web-app out there. Granted, the request line (including the query-string) should be UTF-8, but I haven't tested how many browsers actually enforce this. The POST parameters will generally be in the encoding of the referrer (which usually isn't UTF-8). - Original Message - From: Mark Thomas [EMAIL PROTECTED] To: 'Tomcat Developers List' [EMAIL PROTECTED] Sent: Saturday, September 06, 2003 3:06 PM Subject: RE: [PATCH] Bug 22666 This is obviously a bigger mess than I first thought. As I see it, the following options exist for resolving bug 22666. 1. WONTFIX - On the basis that there is too much uncertainty to do anything sensible and that any changes made might break interoperability as per Remy's point 3 below. 2. FIX - Patch the parameter class (as per Remy's point 2 below) on the grounds that the JSP spec states The World Wide Web Consortium (http://www.w3.org/) is a definitive source of HTTP related information affecting this specification and its implementations. and the w3c view (http://www.w3.org/International/O-URL-code.html) is that URI encoding should always be based on UTF-8. However, this is still likely to break things (back to Remy's point 3). 3. FIX - Add a configuration option that enables w3c compliant URI decoding and patch the parameter and any other relevant classes to support this option. I am not 100% sure where the best place to do this would be. I am leaning towards adding it to the context as an optional parameter with a default state of disabled. There are several bugs in bugzilla that look as if they are on similar lines and on that basis my own view is that option 3 is way to go. Before I start coding, I would be grateful for some feedback/guidance on my planned approach. Thanks in anticipation. Mark On Friday, September 05, 2003 8:13 PM, Remy Maucherat [SMTP:[EMAIL PROTECTED] wrote: Mark Thomas wrote: I was working from http://www.w3.org/International/O-URL-code.html Applying the patch fixed the problem as reported in bug 22666. I am happy to have another look at this. Can you point me in the direction of a better reference? Well, -1 because: 1) Everyone ignores this standard 2) Your encoding will apply to *all* parameters, not just URL parameters; you have to patch the Parameters class for your patch to be correct (I would still vote -1, but at least it wouldn't break the specification) 3) It is extremely likely that people expect all parameters to have the same encoding, regardless of what that w3c spec says; if the servlet spec writes in big bold somewhere that the URL is always UTF8 (which would likely break interoperability with a lot of HTTP clients - possibly all), then it's different Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/etc bootstrap.MF
- Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, September 06, 2003 10:19 AM Subject: cvs commit: jakarta-tomcat-catalina/catalina/etc bootstrap.MF remm2003/09/06 10:19:36 Modified:catalina/etc bootstrap.MF Log: - Modify the bundling of commons-logging to fix (hopefully) the nagging CL issues. - The commons-logging-api JAR will now be put in the system classloader. When using an alternate logging implmentation (ex: log4j) you should put the wrapper implementation in the same classloader or there will likely be trouble. - Ex: When using a Struts 1.1 webapp with log4j, there should be commons-logging.jar (just the log4j logger is fine as well) next to it. - Of course, overriding the log4j API in a webapp is still not possible. It wasn't before as c-logging was treated as a special case by the classloader (like JAXP). - This nasty case now works for me (bug 22701), as well as using log4j with privileged webapps (with or without SSL). I'm -0 on this one. The SSL bugs were due to a non-static c-l logger (since fixed) and/or an undefined state for the Thread ContextClassLoader. I don't see a use case where it is necessary to put c-l in the System Loader. This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native CHANGES.txt
- Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, September 06, 2003 8:49 PM Subject: cvs commit: jakarta-tomcat-connectors/jk/native CHANGES.txt glenn 2003/09/06 20:49:40 Modified:jk/native CHANGES.txt Log: Update changes Revision ChangesPath 1.18 +3 -1 jakarta-tomcat-connectors/jk/native/CHANGES.txt Index: CHANGES.txt === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/CHANGES.txt,v retrieving revision 1.17 retrieving revision 1.18 diff -u -r1.17 -r1.18 --- CHANGES.txt 24 Jul 2003 13:57:53 - 1.17 +++ CHANGES.txt 7 Sep 2003 03:49:40 - 1.18 @@ -2,6 +2,8 @@ Last modified at [$Date$] Changes with JK 1.2.5 +* Fix a thread safe bug when mapping URI's. + [bbarker] I appreciate the cite, but 'bbarker' isn't a working identifier for me ;-). On Apache, I'm billbarker. Change it, don't change it, I really don't care. * Fix a thread safe bug when resolving worker host name when using mod_jk with Apache 2 and the worker MPM. [hgomez] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jakarta-tomcat-connector release cleanup
- Original Message - From: Glenn Nielsen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, September 06, 2003 9:37 PM Subject: jakarta-tomcat-connector release cleanup I have promised to setup the tomcat connector releases so that they can be mirrored when I perform the next mod_jk release. First I have a few questions. Are the coyote beta release/milestone releases in /www/jakarta.apache.org/builds/jakarta-tomcat-connectors/coyote still needed? Will there be separate releases of coyote or will it only be bundled with Tomcat 4/5 releases? Don't forget Tomcat 3.3! The Tomcat 4/5 releases get issued pretty often, and the current Connectors build is broken for 3.3, so +1 to remove the Connectors download. I'll look into transfering the how-to-use instructions to the 3.3 nightly download page. mod_webapp is deprecated so should we continue to have the /www/jakarta.apache.org/builds/jakarta-tomcat-connectors/webapp release directory or should this be moved to archive.apache.org? +1 for moving. The fewer mod_webapp questions I have to field on tomcat-user, the better ;-). Can /www/jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/nightly/ be removed? The last nightly build of this was October of 2002. Can the old mod_jk 1.2 and mod_jk2 releases be moved to archive.apache.org? +1 for moving. Thanks, Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.10] Tag tomorrow
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, September 05, 2003 12:22 AM Subject: Re: [5.0.10] Tag tomorrow Bill Barker wrote: I can post new binaries for procrun tomorrow (PST) to BZ (now that Daemon is in commons-proper, I can't check-in directly :-(). This includes a patch from JFC for W9x (that I missed in the last build), and a patch from Mladin to limit memory usage in the console. Neither is particularly critical, so if you want to tag and leave these for 5.0.11, I've got no objections. Mladen posted a new build not too long ago. Doesn't that include all those patches ? Yes, Mladen's commit should be OK (I follow commons-dev from gmane, which tends to bury commit messages). One less thing for me to do ;-). Somehow the binaries didn't get moved to jakarta-commons/daemon. Can someone put them there (I can get them back from the old CVS otherwise) AFAIK, only you and Yoav (and, well, Costin, but he's AWOL :) have karma for the new repository. ? Thx. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: in_addr_t and Linux 2.2
- Original Message - From: Henri Gomez [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, September 04, 2003 1:51 AM Subject: in_addr_t and Linux 2.2 FYI, in_addr_t is not defined on Redhat 6.2 which use kernel 2.2 and glibc 2.1. And I thought myself a caveman for using RH 7.x ;-). I'd prefer that this is handled by special defines in the autoconf script. Should we also fix this case ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Bug 22715
- Original Message -
From: Mark Thomas [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, September 04, 2003 11:46 AM
Subject: [PATCH] Bug 22715
Resending. I seem to be having e-mail problems...
The patches below (TC5 and TC4) fix bug 22715 in that they ensure that xml
entities are correctly written back out to the password field of
tomcat-users.xml
I did consider a more general patch to allow xml entities in user names,
group
names and role names but wasn't sure of the potential side effects. I also
think that users are far more likely to want to use these characters in
passwords than in user names, group names or role names. Thoughts? If the
general consensus is that a more general patch is required, I am happy to
produce one.
Depending on how/if UDBR wants to support CLIENT-CERT auth, you'll likely
need to escape the user name as well (the full X509 Subject may contain
embedded quot; characters in it).
Mark
Index: catalina/src/share/org/apache/catalina/users/MemoryUser.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catali
na/users/MemoryUser.java,v
retrieving revision 1.2
diff -u -r1.2 MemoryUser.java
--- catalina/src/share/org/apache/catalina/users/MemoryUser.java 2 Sep
2003
21:22:03 - 1.2
+++ catalina/src/share/org/apache/catalina/users/MemoryUser.java 3 Sep
2003
23:01:54 -
@@ -70,6 +70,7 @@
import org.apache.catalina.Group;
import org.apache.catalina.Role;
import org.apache.catalina.UserDatabase;
+import org.apache.catalina.util.RequestUtil;
/**
@@ -296,7 +297,7 @@
StringBuffer sb = new StringBuffer(user username=\);
sb.append(username);
sb.append(\ password=\);
-sb.append(password);
+sb.append(RequestUtil.filter(password));
sb.append(\);
if (fullName != null) {
sb.append( fullName=\);
Index: catalina/src/share/org/apache/catalina/users/MemoryUser.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/us
ers/MemoryUser.java,v
retrieving revision 1.5
diff -u -r1.5 MemoryUser.java
--- catalina/src/share/org/apache/catalina/users/MemoryUser.java 10 Feb
2002
08:06:20 - 1.5
+++ catalina/src/share/org/apache/catalina/users/MemoryUser.java 3 Sep
2003
22:45:49 -
@@ -68,8 +68,8 @@
import java.util.Iterator;
import org.apache.catalina.Group;
import org.apache.catalina.Role;
-import org.apache.catalina.User;
import org.apache.catalina.UserDatabase;
+import org.apache.catalina.util.RequestUtil;
/**
@@ -296,7 +296,7 @@
StringBuffer sb = new StringBuffer(user username=\);
sb.append(username);
sb.append(\ password=\);
-sb.append(password);
+sb.append(RequestUtil.filter(password));
sb.append(\);
if (fullName != null) {
sb.append( fullName=\);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message is intended only for the use of the person(s) listed above as the
intended recipient(s), and may contain information that is PRIVILEGED and
CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or
distribute this message or any attachment. If you received this communication in
error, please notify us immediately by e-mail and then delete all copies of this
message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the
Internet is not secure. Do not send confidential or sensitive information, such as
social security numbers, account numbers, personal identification numbers and
passwords, to us via ordinary (unencrypted) e-mail.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.10] Tag tomorrow
I can post new binaries for procrun tomorrow (PST) to BZ (now that Daemon is in commons-proper, I can't check-in directly :-(). This includes a patch from JFC for W9x (that I missed in the last build), and a patch from Mladin to limit memory usage in the console. Neither is particularly critical, so if you want to tag and leave these for 5.0.11, I've got no objections. Remy Maucherat [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I'll tag and release a new build tomorrow. So far, I think this is going to be a high quality build. Any objections ? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Bug 22905 - set secure option in cookie for JSESSIONID when communicating via SSL
I know that patches are always welcome, but a variant of this has been in
3.3.2-dev (aka nightly) for a very long time.
- Original Message -
From: Kubo Hiroshi [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, September 03, 2003 12:13 AM
Subject: [PATCH] Bug 22905 - set secure option in cookie for JSESSIONID when
communicating via SSL
This patch adds secureCookie option to SessionId Intercepter.
For example,
SessionId cookiesFirst=true noCookies=false secureCookie=true /
If secureCookie is set to be true, cookie for JSESSIONID sent via SSL
connection
will have Secure option.
The patch below is for Tomcat-3.3.1a.
Hiroshi
===
--- src/share/org/apache/tomcat/modules/session/SessionId.java.orig Wed
Sep 3 15:34:11 2003
+++ src/share/org/apache/tomcat/modules/session/SessionId.java Wed Sep 3
15:04:22 2003
@@ -96,6 +96,7 @@
boolean noCookies=false;
boolean cookiesFirst=true;
boolean checkSSLSessionId=false;
+boolean secureCookie=false;
public SessionId() {
}
@@ -112,6 +113,10 @@
this.checkSSLSessionId = checkSSLSessionId;
}
+public void setSecureCookie(boolean secureCookie) {
+this.secureCookie = secureCookie;
+}
+
/** Extract the session id from the request.
* SessionInterceptor will have to be called _before_ mapper,
@@ -341,6 +346,9 @@
StringBuffer buf = new StringBuffer();
buf.append( JSESSIONID= ).append( reqSessionId );
buf.append( ;Path= ).append( sessionPath );
+ if ( secureCookie rrequest.isSecure() ) {
+buf.append( ;Secure );
+}
response.addHeader( Set-Cookie,
buf.toString());
if( debug0) log( Setting cookie + buf );
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message is intended only for the use of the person(s) listed above as the
intended recipient(s), and may contain information that is PRIVILEGED and
CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or
distribute this message or any attachment. If you received this communication in
error, please notify us immediately by e-mail and then delete all copies of this
message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the
Internet is not secure. Do not send confidential or sensitive information, such as
social security numbers, account numbers, personal identification numbers and
passwords, to us via ordinary (unencrypted) e-mail.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.10] New build ?
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, September 01, 2003 5:58 AM Subject: [5.0.10] New build ? I think releasing a new build at the end of this week would be a good idea, given that most issues with 5.0.9 have been resolved. The remaining issues I can think of: * commons-daemon: Needs a 1.0 release (any volunteers ?); needs polish (display of log items in the console could probably be nicer, bug 18220). Sort of running before you can walk here ;-). Daemon needs to graduate from the sandbox before it can have a release. The console does need work. At the moment it appears to be (trying to :) assume that you are using log4j with a format something like %r [%t]: %c %p %m%n. In general, it's a hard problem, since all that it is doing is grabbing stdout/stderr and attempting to display it in the GUI. The other problem with the console is that it never rolls-off (so the more you log, the more memory the process consumes). Bug #18220 is simply not implemented for the new ListView control. It's not hard to do however. As much as I hate Windows GUI programming, If I get some free time at work I can probably look into implementing it. * Schema validation issues: I still have issues validating jsp-examples, even with Xerces 2.1; anyone else experiencing this ? (Jean-François cannot reproduce this) By release time, we'd want to ship a newer Xerces, so the underlying issue would need to be fixed if possible. * Classloader leaks in some situations after a reload (ex: reload the admin webapp, tested on Windows / JDK 1.4.2). There doesn't seem to be any reference leak, and yet the classloader is not getting GCed, so I'm puzzled. Anyone can help me debug this ? * More bugfixes :) * Anything else ? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Prevent NPE if CLIENT-CERT auth fails
Patch committed. Thanks much!
Mark Thomas [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Sorry. Only just noticed the attachment was removed somewhere along the
way.
Contents of patch below.
Index: http11/src/java/org/apache/coyote/http11/Http11Processor.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/
http11/Http11Processor.java,v
retrieving revision 1.75
diff -u -r1.75 Http11Processor.java
--- http11/src/java/org/apache/coyote/http11/Http11Processor.java 19 Aug
2003
16:15:21 - 1.75
+++ http11/src/java/org/apache/coyote/http11/Http11Processor.java 20 Aug
2003
19:44:56 -
@@ -845,17 +845,17 @@
}
} else if (actionCode == ActionCode.ACTION_REQ_SSL_CERTIFICATE) {
-
-try {
-Object sslO = sslSupport.getPeerCertificateChain(true);
-if( sslO != null) {
-request.setAttribute
-(SSLSupport.CERTIFICATE_KEY, sslO);
+if (sslSupport != null) {
+try {
+Object sslO =
sslSupport.getPeerCertificateChain(true);
+if( sslO != null) {
+request.setAttribute
+(SSLSupport.CERTIFICATE_KEY, sslO);
+}
+} catch (Exception e) {
+log.warn(Exception getting SSL Cert,e);
}
-} catch (Exception e) {
-log.warn(Exception getting SSL Cert,e);
}
-
}
}
On Wednesday, August 20, 2003 9:05 PM, Mark Thomas
[SMTP:[EMAIL PROTECTED] wrote:
A small patch.
If auth fails, SSL session is terminated. Subsequent call to
sslSupport.getPeerCertifcate() generates a NPE as sslSupport is null in
this
case.
File: ATT0.txt
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [j-t-c] Thread problem in jk_uri_worker_map.c
I'll put this one in in the interest of time, but Marc should be given karma (like any other Tomcat committer) to j-t-c, if he doesn't have it already. Marc Saegesser [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] G, the attachment got stripped from my last message. Here's the diff inline: Index: jk_connect.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_connect.c,v retrieving revision 1.12 diff -u -r1.12 jk_connect.c --- jk_connect.c 29 Aug 2003 13:07:52 - 1.12 +++ jk_connect.c 29 Aug 2003 21:37:12 - @@ -101,6 +101,9 @@ #include apr_general.h #endif +#if defined(WIN32) +typedef u_long in_addr_t; +#endif /** resolve the host IP */ int jk_resolve(char *host, -- Marc -Original Message- From: Marc Saegesser [mailto:[EMAIL PROTECTED] Sent: Friday, August 29, 2003 4:41 PM To: Tomcat Developers List Subject: RE: [j-t-c] Thread problem in jk_uri_worker_map.c The file common/jk_connect.c no longer compiles on Win32 because the in_addr_t type is not defined on that platform. The attached patch fixes the build problem, but there is probably a better way. -- Marc -Original Message- From: Glenn Nielsen [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 27, 2003 8:55 AM To: Tomcat Developers List Subject: Re: [j-t-c] Thread problem in jk_uri_worker_map.c Henri Gomez wrote: Marc Saegesser a écrit : That makes sense. The manipulations that map_uri_to_worker() does always make the string shorter so there is no need to worry about the modifiable string passed in being too short and needing reallocated. Trying to fix this in the jk/common code is, I think, a waste of effort. -- Marc A good reason to have delayed jk 1.2.5 ;) Ok, I have seen Henri's commit for the in_addr build fix. And I have seen Bill's patches for the uri mapping thread safe bug. If I don't hear about any more open items/bugs for mod_jk 1.2.5 in the next few days I will generate another test release distribution over the weekend. Regards, Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/admin/connector connector.jsp
- Original Message - From: Amy Roh [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, August 29, 2003 8:36 AM Subject: Re: cvs commit: jakarta-tomcat-catalina/webapps/admin/connector connector.jsp The AJP connector still lies, Can you tell me what the discrepancy is in AJP connector? I just followed the doc. AJP has a separate config method (the $CATALINA_HOME/jk2.properties file) that will override server.xml. However, the Protocol won't report the correct values (due to Costin's design considerations). It's not an admin problem, it's a problem with the AJP Protocol. The patch belongs in the AJP Protocol, so I'll do this one (since Costin is currently AWOL ;-). Looking at the latest, you (or I, if I get the time) can remove the scheme, secure and Enable DNS Lookups rows for the AJP connector. They are all handled by the Apache configuration, and Tomcat ignores them (or, rather, trusts the values that it gets from Apache). It would be good for a future product to allow you to configure an AJP connector from the admin without requiring that you also configure jk2.properties. However, I can wait on this. All of my Connectors (http, https, ajp) show blanks for the Processors section (even for those that I've explicitly configured in 'server.xml'). What do you mean? There is no longer Processors section. I got rid of maxProcessor and minProcessor from the page since they're deprecated. Instead, admin now shows maxSpareThreads, maxThreads, and minSpareThreads. Thanks for the comments. :-) It seems that I co'ed too early. You are correct, and the http(s) Connector values all look good. Amy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_uri_worker_map.h jk_uri_worker_map.c
- Original Message - From: Mladen Turk [EMAIL PROTECTED] To: 'Tomcat Developers List' [EMAIL PROTECTED] Sent: Saturday, August 30, 2003 2:46 AM Subject: RE: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_uri_worker_map.h jk_uri_worker_map.c -Original Message- From: [EMAIL PROTECTED] Log: iSeries C compiler didn't like cast between const and non const. IMO the function prototype should stay const char* or modified to char** if the pointer needs to be changed, but since it isn't it should stay const char *. The problem is later in the code where the function param is assigned with local char * (uri = clean_uri;), and that is what should be changed, not the function call itself. Further more all the functions protos should be changed to const char *, that are now char *. This one is a special case, due to the fact that in mod_jk, the jk_pools aren't thread-safe. Adding a sync to the jk_pool just for this function doesn't make a lot of sense, so (as discussed on the list) it was decided to change this function from const char * to char *, and handle the duplicating logic in the server-specific code. Henri was just cleaning up a file I forgot to change. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/webapps/admin/connector connector.jsp
- Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, August 28, 2003 7:40 PM Subject: cvs commit: jakarta-tomcat-catalina/webapps/admin/connector connector.jsp amyroh 2003/08/28 19:40:52 Modified:webapps/admin/WEB-INF/classes/org/apache/webapp/admin ApplicationResources_en.properties webapps/admin/WEB-INF/classes/org/apache/webapp/admin/connector AddConnectorAction.java ConnectorForm.java EditConnectorAction.java SaveConnectorAction.java webapps/admin/connector connector.jsp Log: Update Admin with new connector properties including thread pool configuration. Definately an improvement. The AJP connector still lies, but that is because I need to make some changes to the Protocol to get it to return the correct values (Costin didn't design this with the admin in mind ;-). All of my Connectors (http, https, ajp) show blanks for the Processors section (even for those that I've explicitly configured in 'server.xml'). I've been out of touch with admin for a while, but is it looking for the wrong attributes (I haven't had a chance to look myself yet). This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [VOTE] 5.0.9 stability rating]
- Original Message - From: Amy Roh [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, August 26, 2003 5:15 PM Subject: [Fwd: Re: [VOTE] 5.0.9 stability rating] resend again. my email's been getting lost for some reason. Well, at least SOBIG is only around for another two weeks :). Original Message Subject: Re: [VOTE] 5.0.9 stability rating Date: Tue, 26 Aug 2003 16:11:35 -0700 From: Amy Roh [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] btw, why does Http11Protocol.getAttribute always return null? Is it on purpose or just not implement yet since no usage? I believe that it is simply not implemented yet. Amy Roh wrote: Resend. It's been almost 3 hours since I sent the original email. wonder if it's my mail server or apache... Amy Roh wrote: Remy Maucherat wrote: Amy Roh wrote: Remy Maucherat wrote: Amy Roh wrote: I'll update the mbean-descriptor.xml and admin page for Connector soon. Thanks. Sorry for the trouble. No Problem. I just committed the updates. Let me know if there is additional updates or if I missed/overlooked anything. The changes are a bit more complex than what you did. The new syntax is: HTTP/1.1: Connector port=8080 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=2 disableUploadTimeout=true / (the thread pool configuration changed, basically) AJP/1.3: Connector port=8009 enableLookups=false redirectPort=8443 debug=0 protocol=AJP/1.3 / (ie, no thread pool configuration here) Please don't add get/set on the CoyoteConnector class itself (we're trying to avoid that, as it's protocol dependent; you can look at Bill's patch - which I reverted for performance reasons, but which did the right thing on principle). IMO, you should add those to the ConnectorMBean, and use get/setProperty. What do you think ? I thought we're moving away from using *MBean classes and instead using the actual class for management implementation. But I see that why we want to avoid the getters and setters from the class due to protocol dependency. We can definitely move the getters/setters into a ConnectorMBean as long as modeler keeps supporting extending class mbean. I can either update o.a.c.mbeans.ConnectorMBean and use it or put the ConnectorMBean in the coyote directory with the mbean-descriptor and the Connector class. I'll need to update admin to represent thread pool configuration changes. Amy Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.9 stability rating
- Original Message - From: Amy Roh [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, August 26, 2003 12:11 PM Subject: Re: [VOTE] 5.0.9 stability rating Remy Maucherat wrote: Amy Roh wrote: Remy Maucherat wrote: Amy Roh wrote: I'll update the mbean-descriptor.xml and admin page for Connector soon. Thanks. Sorry for the trouble. No Problem. I just committed the updates. Let me know if there is additional updates or if I missed/overlooked anything. The changes are a bit more complex than what you did. The new syntax is: HTTP/1.1: Connector port=8080 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=2 disableUploadTimeout=true / (the thread pool configuration changed, basically) AJP/1.3: Connector port=8009 enableLookups=false redirectPort=8443 debug=0 protocol=AJP/1.3 / (ie, no thread pool configuration here) Please don't add get/set on the CoyoteConnector class itself (we're trying to avoid that, as it's protocol dependent; you can look at Bill's patch - which I reverted for performance reasons, but which did the right thing on principle). IMO, you should add those to the ConnectorMBean, and use get/setProperty. What do you think ? I thought we're moving away from using *MBean classes and instead using the actual class for management implementation. But I see that why we want to avoid the getters and setters from the class due to protocol dependency. We can definitely move the getters/setters into a ConnectorMBean as long as modeler keeps supporting extending class mbean. I can either update o.a.c.mbeans.ConnectorMBean and use it or put the ConnectorMBean in the coyote directory with the mbean-descriptor and the Connector class. I'll need to update admin to represent thread pool configuration changes. Amy Yeah, I know that this is a six-hour-stale message ;-). The Connector has become somewhat of a special case, so it probably merits getting it's own intelligent MBean. There are properties that make sense on one Connector (e.g. maxKeepAliveRequest on HTTP/1.1, but not on AJP), and default values that are wildly different (e.g. connectionTimeout, which should be enabled to a short value on HTTP/1.1, and disabled on AJP). I attempted to implement this in the Connector class, but as Remy pointed out, it's not practical given the need to access attributes in the critical path. So, the Connectors need a custom MBean to allow JMX to be able to configure them correctly. If you need help in implementation, I'm more than happy to lend a hand ;-). Point of fact was that I was assuming that I would be making the changes you've made myself. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.9 stability rating
Jean-Francois Arcand [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Bill Barker wrote: - Original Message - From: Jean-Francois Arcand [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, August 25, 2003 6:20 AM Subject: Re: [VOTE] 5.0.9 stability rating Bill Barker wrote: - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, August 25, 2003 12:32 AM Subject: Re: [VOTE] 5.0.9 stability rating Bill Barker wrote: Tim Funk wrote: Installed 5.0.9 from exe (win2k) 1) startup.bat worked fine, but the icon which calls tomcatw.exe //GT//Tomcat5 fails will some Current Thread not owner error 2) Race conditions and connection handling in JDBCRealm - plus a whole host of other JDBCRealm bugs in Bugzilla applicable to 4 and 5. I hope early next week to have a patch which will close many of the JDBCRealm bugs. 3) Need to reinvestigate the JNDIRealm bug reopened. For the first error - I am sure I just need to look through bugzilla, or the archives and just need to add something to the README. (User error) This works for me, Bill, and presumably others. There are reports on tomcatw in BZ, so it must be at least an uncommon error (given the code have stayed stable for a few releases). Even if the bug is mildly common, the old shell scripts are still there. I can put a note stating that they can be used in case the new .exe wrapper somehow fails. I'm staying by my beta rating. Again, we cannot continue releasing alphas just because there could be some non obvious bugs in the build. In the current system, the period before the vote is meant to check if there are no showstoppers. If the build is mostly clean, it must be a beta, otherwise, it merely delays wider testing and finding bugs, which is *bad*. Ok. I'm willing to vote for a (weak) Beta in exchange for a release-note that Tomcat doesn't implement the current-draft's Authentication requirements. What is your plan, BTW ? Wait a bit more for the deadline to see what the final specification will say ? (IMO, the old auth matching rules were not very good) I was hoping for a pfd4, but it doesn't look like it's coming out anytime soon :-(. It's a pretty big change to conform to pfd3 (which is a completely nonsensical requirement :), so I was playing the wait-and-see game. Of course, I'm more than happy to do the grunt work to bring Tomcat into compliance with pfd3. However, if the spec changes to something sensible, then that means two big (e.g. changing interfaces in o.a.c) API changes. The spec should'nt change now. I don't really understand why you think we aren't complinat right nowI tough your last change was to bring back compatibility with PFD 3. Do you have an example I can use to demonstrate the problem? Thanks, The following doesn't work correctly according to pfd3: security-constraint web-resource-collection url-pattern/*/url-pattern /web-resource-collection auth-constraint role-name*/role-name /auth-constraint /security-constraint security-constraint web-resource-collection url-pattern/product1/*/url-pattern /web-resource-collection auth-constraint role-nameproduct1/role-name /auth-constraint /security-constraint security-constraint web-resource-collection url-pattern/product2/*/url-pattern /web-resource-collection auth-constraint role-nameproduct2/role-name /auth-constraint /security-constraint With Tomcat, you need role 'product1' to access /myapp/product1, role 'product2' to access /myapp/product2, and must be authenticated to access anything else. The correct behavior is that any authenticated user can access anything. My understanding of the spec is that is the proper behaviour (just discussed the issue with the spec lead). Having role-name equals to * doesn't means you have access to /product1/* etc. The spec will be clarified (but the required behaviour will stay the same) +1 for clarification (although somewhat meaningless, since I'm not a servlet-api committer :). It currently reads too much like it was modeled after 'grant'. I guess that gets rid of my excuses to not re-visit the code and see if I can't get rid of some of the garbage. -- Jeanfrancois -- Jeanfrancois Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may
Re: [VOTE] 5.0.9 stability rating
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Sunday, August 24, 2003 11:25 AM Subject: Re: [VOTE] 5.0.9 stability rating Tim Funk wrote: Installed 5.0.9 from exe (win2k) 1) startup.bat worked fine, but the icon which calls tomcatw.exe //GT//Tomcat5 fails will some Current Thread not owner error 2) Race conditions and connection handling in JDBCRealm - plus a whole host of other JDBCRealm bugs in Bugzilla applicable to 4 and 5. I hope early next week to have a patch which will close many of the JDBCRealm bugs. 3) Need to reinvestigate the JNDIRealm bug reopened. For the first error - I am sure I just need to look through bugzilla, or the archives and just need to add something to the README. (User error) This works for me, Bill, and presumably others. There are reports on tomcatw in BZ, so it must be at least an uncommon error (given the code have stayed stable for a few releases). Even if the bug is mildly common, the old shell scripts are still there. I can put a note stating that they can be used in case the new .exe wrapper somehow fails. I'm staying by my beta rating. Again, we cannot continue releasing alphas just because there could be some non obvious bugs in the build. In the current system, the period before the vote is meant to check if there are no showstoppers. If the build is mostly clean, it must be a beta, otherwise, it merely delays wider testing and finding bugs, which is *bad*. Ok. I'm willing to vote for a (weak) Beta in exchange for a release-note that Tomcat doesn't implement the current-draft's Authentication requirements. For the last 2 errors - tomcat can be considered beta or stable with the buggy JNDIRealm and JDBCRealms since the tomcat4.1 version of the same code was part of a stable release. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.9 stability rating
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, August 25, 2003 12:32 AM Subject: Re: [VOTE] 5.0.9 stability rating Bill Barker wrote: Tim Funk wrote: Installed 5.0.9 from exe (win2k) 1) startup.bat worked fine, but the icon which calls tomcatw.exe //GT//Tomcat5 fails will some Current Thread not owner error 2) Race conditions and connection handling in JDBCRealm - plus a whole host of other JDBCRealm bugs in Bugzilla applicable to 4 and 5. I hope early next week to have a patch which will close many of the JDBCRealm bugs. 3) Need to reinvestigate the JNDIRealm bug reopened. For the first error - I am sure I just need to look through bugzilla, or the archives and just need to add something to the README. (User error) This works for me, Bill, and presumably others. There are reports on tomcatw in BZ, so it must be at least an uncommon error (given the code have stayed stable for a few releases). Even if the bug is mildly common, the old shell scripts are still there. I can put a note stating that they can be used in case the new .exe wrapper somehow fails. I'm staying by my beta rating. Again, we cannot continue releasing alphas just because there could be some non obvious bugs in the build. In the current system, the period before the vote is meant to check if there are no showstoppers. If the build is mostly clean, it must be a beta, otherwise, it merely delays wider testing and finding bugs, which is *bad*. Ok. I'm willing to vote for a (weak) Beta in exchange for a release-note that Tomcat doesn't implement the current-draft's Authentication requirements. What is your plan, BTW ? Wait a bit more for the deadline to see what the final specification will say ? (IMO, the old auth matching rules were not very good) I was hoping for a pfd4, but it doesn't look like it's coming out anytime soon :-(. It's a pretty big change to conform to pfd3 (which is a completely nonsensical requirement :), so I was playing the wait-and-see game. Of course, I'm more than happy to do the grunt work to bring Tomcat into compliance with pfd3. However, if the spec changes to something sensible, then that means two big (e.g. changing interfaces in o.a.c) API changes. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.9 stability rating
- Original Message - From: Jean-Francois Arcand [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, August 25, 2003 6:20 AM Subject: Re: [VOTE] 5.0.9 stability rating Bill Barker wrote: - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, August 25, 2003 12:32 AM Subject: Re: [VOTE] 5.0.9 stability rating Bill Barker wrote: Tim Funk wrote: Installed 5.0.9 from exe (win2k) 1) startup.bat worked fine, but the icon which calls tomcatw.exe //GT//Tomcat5 fails will some Current Thread not owner error 2) Race conditions and connection handling in JDBCRealm - plus a whole host of other JDBCRealm bugs in Bugzilla applicable to 4 and 5. I hope early next week to have a patch which will close many of the JDBCRealm bugs. 3) Need to reinvestigate the JNDIRealm bug reopened. For the first error - I am sure I just need to look through bugzilla, or the archives and just need to add something to the README. (User error) This works for me, Bill, and presumably others. There are reports on tomcatw in BZ, so it must be at least an uncommon error (given the code have stayed stable for a few releases). Even if the bug is mildly common, the old shell scripts are still there. I can put a note stating that they can be used in case the new .exe wrapper somehow fails. I'm staying by my beta rating. Again, we cannot continue releasing alphas just because there could be some non obvious bugs in the build. In the current system, the period before the vote is meant to check if there are no showstoppers. If the build is mostly clean, it must be a beta, otherwise, it merely delays wider testing and finding bugs, which is *bad*. Ok. I'm willing to vote for a (weak) Beta in exchange for a release-note that Tomcat doesn't implement the current-draft's Authentication requirements. What is your plan, BTW ? Wait a bit more for the deadline to see what the final specification will say ? (IMO, the old auth matching rules were not very good) I was hoping for a pfd4, but it doesn't look like it's coming out anytime soon :-(. It's a pretty big change to conform to pfd3 (which is a completely nonsensical requirement :), so I was playing the wait-and-see game. Of course, I'm more than happy to do the grunt work to bring Tomcat into compliance with pfd3. However, if the spec changes to something sensible, then that means two big (e.g. changing interfaces in o.a.c) API changes. The spec should'nt change now. I don't really understand why you think we aren't complinat right nowI tough your last change was to bring back compatibility with PFD 3. Do you have an example I can use to demonstrate the problem? Thanks, The following doesn't work correctly according to pfd3: security-constraint web-resource-collection url-pattern/*/url-pattern /web-resource-collection auth-constraint role-name*/role-name /auth-constraint /security-constraint security-constraint web-resource-collection url-pattern/product1/*/url-pattern /web-resource-collection auth-constraint role-nameproduct1/role-name /auth-constraint /security-constraint security-constraint web-resource-collection url-pattern/product2/*/url-pattern /web-resource-collection auth-constraint role-nameproduct2/role-name /auth-constraint /security-constraint With Tomcat, you need role 'product1' to access /myapp/product1, role 'product2' to access /myapp/product2, and must be authenticated to access anything else. The correct behavior is that any authenticated user can access anything. -- Jeanfrancois Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL
Re: [VOTE] 5.0.9 stability rating
- Original Message - From: Tim Funk [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Saturday, August 23, 2003 7:50 AM Subject: Re: [VOTE] 5.0.9 stability rating Installed 5.0.9 from exe (win2k) 1) startup.bat worked fine, but the icon which calls tomcatw.exe //GT//Tomcat5 fails will some Current Thread not owner error This is weird, since the Installer configures tomcatw to use the fork option. Tomcat gets run as java -classpath %CATALINA_HOME%\bin\bootstrap.jar -Xrs org.apache.catalina.startup.Bootstrap start 2) Race conditions and connection handling in JDBCRealm - plus a whole host of other JDBCRealm bugs in Bugzilla applicable to 4 and 5. I hope early next week to have a patch which will close many of the JDBCRealm bugs. 3) Need to reinvestigate the JNDIRealm bug reopened. For the first error - I am sure I just need to look through bugzilla, or the archives and just need to add something to the README. (User error) For the last 2 errors - tomcat can be considered beta or stable with the buggy JNDIRealm and JDBCRealms since the tomcat4.1 version of the same code was part of a stable release. -Tim Remy Maucherat wrote: ballot [X] Alpha [ ] Beta /ballot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.9 stability rating
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, August 22, 2003 10:20 AM Subject: [VOTE] 5.0.9 stability rating ballot [ ] Alpha [X] Beta /ballot 1) The admin webapp lies about Connector properties. 2) Authorization isn't spec-compliant (I mis-read the spec when I did it). However, I heard a rumor that the spec may move closer to what Tomcat is currently doing (what's in pfd3 is pretty nonsensical :), so I haven't been in a rush to fix this. This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [j-t-c] Thread problem in jk_uri_worker_map.c
The easiest solution would be to change the map_uri_to_worker contract to be that the uri parameter is modifiable. Then Apache can dup it using the request's pool, it looks like IIS is doing this most of the time anyway, and Netscape isn't using map_uri_to_worker at all. That leave Domino, which I don't really know. - Original Message - From: Marc Saegesser [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, August 15, 2003 3:11 PM Subject: [j-t-c] Thread problem in jk_uri_worker_map.c I've run into a threading problem in /j-t-c/native/jk/common/jk_uri_worker_map.c. The problem has been around for a long time, but I believe the changes checked in for version 1.15 on June, 27, 2003 made the problem worse. I have only been able to reproduce the problem on multi-processor machines running under a fairly heavy load. Unfortunately, I don't have a good solution, yet. The worker map contains a temp pool (jk_uri_worker_map.tp) that is used in the map_uri_to_worker() function. The temp pool is used to store a copy of the incoming URI so that it can be altered to remove any jsessionid and to remove multiple adjacent / characters. The problem is that this single pool is shared by all the worker threads so if multiple threads are executing map_uri_to_worker() simultaneously there is a chance that the pool will get corrupted. This can happen in two ways. The jk_pool code is not thread safe so the internal state of the pool may be corrupted. Second, the map_uri_to_worker() function always calls jk_pool_reset() after mapping the URI. This means that if multiple URIs did get allocated into the pool without corruption, when the first thread finishes it will reset the pool. This may not create a noticeable problem because the memory in the pools isn't overwritten by a reset. If the other threads finish before another thread enters map_uri_to_worker() then nothing will fail. However, if another thread does enter map_uri_to_worker() then its call to jk_pool_strdup() will overwrite some of the previous contents of the pool and really bad things may happen. As I said, I don't have a solution, yet. Any solution would have to be platform independent and also work with all the Web servers that use the JK plugin (e.g. Apache 1.3, Apache 2.0, ISAPI, Netscape, ...). Suggestions? -- Marc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JkCoyoteHandler with SSL
Client-certs don't work with JkCoyote on 4.1.24. You need to use 4.1.27 (or, at least the tomcat-jk2.jar). - Original Message - From: Ben Sifuentes [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, August 15, 2003 5:45 PM Subject: JkCoyoteHandler with SSL While using Apache2.0.47 and Tomcat 4.1.24 integrated with JBOSS 3.2.1 on a Win2000 box. I get the following exception from the Tomcat JkCoyoteHandler when making a https call If I hit the ok button several times when it pops up the Select your Certificate box in windows it processes the request as you can see by the output I'm able to correctly process the SSL information being sent across the wire. The Certificate is a pk7 which was built from x509 Any help with this issue would be greatly appreciated. I've struggled long and hard with the SSL communication between Apache and Tomcat and it looks like I'm very close to having it. Except for the following error. One last thing: mod_sll.so (came with the Apache2.0 distribution) mod_jdk_2.0.46.dll 19:43:29,503 INFO [Server] JBoss (MX MicroKernel) [3.2.1 (build: CVSTag=JBoss_3 _2_1 date=200305041533)] Started in 1m:39s:313ms 19:44:49,248 ERROR [JkCoyoteHandler] Certificate convertion failed java.security.cert.CertificateException: Unable to initialize, java.io.IOExcepti on: DerInputStream.getLength(): lengthTag=127, too big. at sun.security.x509.X509CertImpl.init(X509CertImpl.java:289) at sun.security.provider.X509Factory.engineGenerateCertificate(X509Facto ry.java:94) at java.security.cert.CertificateFactory.generateCertificate(Certificate Factory.java:389) at org.apache.jk.server.JkCoyoteHandler.action(JkCoyoteHandler.java:395) at org.apache.coyote.Response.action(Response.java:222) at org.apache.coyote.tomcat4.CoyoteAdapter.postParseRequest(CoyoteAdapte r.java:310) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:22 1) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:261) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:360) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:604) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.ja va:562) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:679) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP ool.java:619) at java.lang.Thread.run(Thread.java:536) Caused by: java.io.IOException: DerInputStream.getLength(): lengthTag=127, too b ig. at sun.security.util.DerInputStream.getLength(DerInputStream.java:502) at sun.security.util.DerInputStream.getLength(DerInputStream.java:476) at sun.security.util.DerValue.init(DerValue.java:233) at sun.security.util.DerInputStream.getDerValue(DerInputStream.java:358) at sun.security.x509.X509CertImpl.parse(X509CertImpl.java:1608) at sun.security.x509.X509CertImpl.init(X509CertImpl.java:286) ... 13 more . . 19:45:12,001 INFO [Engine] CoyoteAdapter Requested cookie session id is 01BD9D C9B2EF687EE90F8FAD8147B49F 19:45:12,001 ERROR [JkCoyoteHandler] Certificate convertion failed java.security.cert.CertificateException: Unable to initialize, java.io.IOExcepti on: DerInputStream.getLength(): lengthTag=102, too big. at sun.security.x509.X509CertImpl.init(X509CertImpl.java:289) at sun.security.provider.X509Factory.engineGenerateCertificate(X509Facto ry.java:94) at java.security.cert.CertificateFactory.generateCertificate(Certificate Factory.java:389) at org.apache.jk.server.JkCoyoteHandler.action(JkCoyoteHandler.java:395) at org.apache.coyote.Response.action(Response.java:222) at org.apache.coyote.tomcat4.CoyoteAdapter.postParseRequest(CoyoteAdapte r.java:310) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:22 1) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:261) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:360) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:604) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.ja va:562) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:679) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP ool.java:619) at java.lang.Thread.run(Thread.java:536) Caused by: java.io.IOException: DerInputStream.getLength(): lengthTag=102, too b ig. at sun.security.util.DerInputStream.getLength(DerInputStream.java:502) at sun.security.util.DerInputStream.getLength(DerInputStream.java:476) at sun.security.util.DerValue.init(DerValue.java:233) at sun.security.util.DerInputStream.getDerValue(DerInputStream.java:358) at
Re: [5.0.7] New build by Sunday
Remy Maucherat [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi, I plan to make a new build available by Sunday. Comments ? Any issues which would need to be resolved by then ? A number of issues have been filed about commons-daemon and the new Windows .exe wrapper. Is anyone working on resolving them ? (Mladen, JF ?) I could have helped on that, but the requirement for Visual C++ prevents me from doing so. Is there any way around ? Clicking through to the TC 5 bugzilla link, I don't see anything for commons-daemon on Unix. Could you provide bug #s? (and, yes, I'm very interested). For procrun, I pretty much understand the bugs now, but won't be able to meet a Sunday deadline (basically, I have MSVC on my work computer (but not my home), but the firewall there prevents me from having CVS access). If you are going to stick to a Sunday deadline, then the procrun bugs will be fixed in 5.0.8. You should also indicate if you need the the binaries (@see previous paragraph). If you do, my build-platform will be XP, but they should still work with W2K. Thanks, Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: which method gets called first listener.sessionDestroyed() or session.invalidate()
If you want to re-post your question on tomcat-user, I'd be more than happy to answer your question. However, it is off-topic on this list. - Original Message - From: [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Saturday, August 09, 2003 3:45 AM Subject: which method gets called first listener.sessionDestroyed() or session.invalidate() Hi All, I have written a Http Session Listener for logging session termination event. In my listener I am trying to get user related data by calling getSession() then getAttribute() method. Here I am always getting an exception saying IllegalStateException : Session is already invalidated. Could you please tell me why session is getting invalidated before calling listener.sessionDestroyed(..) method. Thanks, Kaushik Dutta - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Q] Different handling tagfiles and normal tags classes
- Original Message - From: Torsten Fohrer [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, August 13, 2003 9:32 PM Subject: Re: [Q] Different handling tagfiles and normal tags classes What about a seperate TAGFILE_SCOPE? Not something that is under Tomcat's control. You'd need to suggest it to [EMAIL PROTECTED] Best greeting Torsten Fohrer On Wednesday 13 August 2003 22:02, you wrote: Torsten, see JSP.8.3 (Semantics of Tag Files), 3rd bullet: For each invocation to the tag, the JSP Context Wrapper must present a clean page scope containing no initial elements. All scopes other than the page scope must be identical to those in the Invoking JSP Context and must be modified accordingly when updates are made to those scopes in the JSP Context Wrapper. Any modifications to the page scope, however, must not affect the Invoking JSP Context. Hope this helps. Jan Torsten Fohrer wrote: Tagfiles and tags get a jspcontext from the container at runtime. Tags get directly a normal pagecontext reference from the current jsp page. TagFiles instead get a wrapper around the pagecontext that wraps all set/get/findAttribute for the page scope to a local set of stored attributes. When i declare an attribute in jsp with page scope, i never see it in a tag file, but i see it in a 'normal' tag. Interesting files: org.apache.jasper.runtime.JspContextWrapper - see getAttribute(String)/getAttribute(String/int) org.apache.jasper.compiler.Generator - search for setJspContext Is there a reason why, i don't know? Best greeting Torsten Fohrer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Add keystoreAlias property to CoyoteConnector
Just make certain to close bug #19610 after the commit. - Original Message - From: Jan Luehe [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Saturday, August 09, 2003 10:38 AM Subject: [PROPOSAL] Add keystoreAlias property to CoyoteConnector I would like to add support for specifying a keystore alias property on CoyoteConnector. This will allow control over which (of possible many) keypair and supporting cert chain the connector is going to select to authenticate itself to the client during the SSL handshake, when client auth is turned on. If this attribute is specified on the connector, the underlying JSSE socket factory will initialize the SSL context with a KeyManager implementation whose methods delegate to the default key manager, with the exception of the chooseServerAlias method, which will return the specified alias name. Let me know if you have any issues with this proposal. Thanks, Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Apache Tomcat 4.1.27 Stable released
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, August 07, 2003 11:03 AM Subject: Re: [ANN] Apache Tomcat 4.1.27 Stable released NAIK,ROSHAN (HP-Cupertino,ex1) wrote: Hi Remy, Are these security bugs existing in all versions of Tomcat 4 prior to 4.1.27 ? Or was there a version of Tomcat where these were introduced ? I couldnt find the reference to these security issues on the tomcat web site section mentioning the 4.1.27 release. This information will be very much useful since we may need to redeploy our free HPUX Tomcat distribution to customers. Ok, cool. The Tomcat Team announces the immediate availability of Apache Tomcat 4.1.27 Stable. Among other bugfixes and improvements, Tomcat 4.1.27 includes security fixes for: - Improper recycling of SSL client certificates with Coyote JK 2 That could have been introduced in a previous release. Bill or Costin could probably give a straight answer. This was introduced in 4.1.18, along with another bug that caused client certificates to not work at all (and which masked this bug). - Improper handling of invalid content lengths in requests, causing HTTP processors to be left in an invalid state in Coyote HTTP/1.1, causing a DoS condition That always existed in Coyote HTTP/1.1 shipped with Tomcat 4.1.x. - URI normalization bug in Coyote Idem. - Improper handling of certain URLs in Coyote JK 2, causing a DoS condition I believe this always existed in Coyote JK 2, but Bill or Costin have more knowledge of the issue. Without checking the CVS logs, I believe that this has always existed in 4.1. It's certainly been there since the first stable release of 4.1.x. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5] Jasper currently requires a 1.4 JVM
- Original Message - From: Costin Manolache [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, August 13, 2003 10:49 PM Subject: Re: [5] Jasper currently requires a 1.4 JVM Remy Maucherat wrote: Bill Barker wrote: o.a.j.compiler.JspUtil.makeJavaPackage currently is calling String.split. This means that you currently can't use Jasper (at least for compiling) with a 1.3.x JVM. Since Tomcat isn't a J2EE 1.4 container I can't see any justification in the spec for not supporting 1.3.x JVMs. However, since I don't spend a lot of my time with Jasper, I'd thought that I should get the opinions of people that do before hacking away ;-). The two ways I can see to go are: 1) Introduce a JdkCompat (similar to o.a.t.u.compat, but in Jasper since I can't see making Jasper depend on j-t-c). Pluses: People using 1.4 JVMs get all the benefits of String.split. Minuses: Requires a new package with two new classes. 2) Simply re-code makeJavaPackage to only use APIs from 1.3.x and higher. Basically switch Pluses and Minuses above. Of course, I'm willing to do the grunt-work to implement this. My personal preference is for 1), but if anyone has a better idea I'm open to that as well. Comments/Opinions/Flames? I would do 2. Since it doesn't affect functionality, and I think this was a mistake when makeJavaPackage was coded. The gain is not worth maintaining two versions IMO. +1 on 2 - same reasons as Remy. Remy's suggestion has already been committed. I would be +1 on (1) if the new methods would be added to o.a.t.u.compat, not in a jasper package. Jasper depending on j-t-c (or at least the utils ) would be a good thing IMO. ( I know some people disagree on this, no need to flame :-) I also added the 'split' method to o.a.t.u.compat (although it isn't currently used). Depending on usage (if any) we may need to have regexp support for util to have it really work cross JVMs. I'm being an optimist and assuming that there won't be a need for regexp splits ;-). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[5] Jasper currently requires a 1.4 JVM
o.a.j.compiler.JspUtil.makeJavaPackage currently is calling String.split. This means that you currently can't use Jasper (at least for compiling) with a 1.3.x JVM. Since Tomcat isn't a J2EE 1.4 container I can't see any justification in the spec for not supporting 1.3.x JVMs. However, since I don't spend a lot of my time with Jasper, I'd thought that I should get the opinions of people that do before hacking away ;-). The two ways I can see to go are: 1) Introduce a JdkCompat (similar to o.a.t.u.compat, but in Jasper since I can't see making Jasper depend on j-t-c). Pluses: People using 1.4 JVMs get all the benefits of String.split. Minuses: Requires a new package with two new classes. 2) Simply re-code makeJavaPackage to only use APIs from 1.3.x and higher. Basically switch Pluses and Minuses above. Of course, I'm willing to do the grunt-work to implement this. My personal preference is for 1), but if anyone has a better idea I'm open to that as well. Comments/Opinions/Flames? This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteResponse.java
- Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, August 12, 2003 5:13 PM Subject: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteResponse.java luehe 2003/08/12 17:13:43 Modified:catalina/src/share/org/apache/coyote/tomcat5 CoyoteResponse.java Log: Optimizations: - Bugtraq 4730584 (HttpResponseBase should create date format only when needed) - Bugtraq 4701695 (avoid reformatting constant Expires header on every request) The CoyoteResponse is a pretty long-living object. I wouldn't expect that this will speed Tomcat up at all once it has been running for a while. This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug 19867
- Original Message - From: Mark Thomas [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, August 11, 2003 3:23 PM Subject: RE: Bug 19867 I have been looking into http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19867 and have a couple of questions. The error seen in this report is a result of specifying CLIENT-CERT authentication without specifying a user-data-constraint. This causes a NPE because the sslSupport attribute of the http11Processor object is null. I have looked at the servlet spec (2.3 and the draft of 2.4) and, based on the 2.4 draft, the user-data-constraint is not mandatory (end of SRV.12.8) and the use of CLIENT-CERT requires SSL (SRV.12.5.4). With this in mind, my first question is: 1. If a user wants to use CLIENT-CERT should they have to specify a user-data-constraint or should tomcat automatically apply SSL to the resources in the web resource collection specified in the security constraint when the auth constraint is CLIENT-CERT? Having read the spec, I can't figure out what should happen. Having CLIENT-CERT imply a transport-guarantee sounds like a nice idea. However, it would violate section 12.8 of the current draft of the 2.4 spec. If the spec changes, then we could add it as a feature. If you feel strongly about this, then [EMAIL PROTECTED] is the place to write. Regardless of the answer to the above, if CLIENT-CERT is specified, user-data-constraint is set to CONFIDENTIAL and there are no valid certs on the client a number of exceptions get thrown by tomcat. This brings me to my remaining question: 2. Not having a matching certificate is equivalent to getting the password wrong. Therefore, shouldn't tomcat behave in a similar way (no exceptions, return a 403 to the client) rather than throwing the exceptions? SSL doesn't work that way. If the client's cert can't be validated, then the connection is just dropped, so there is no way to send anything back to the client. If the certificate is valid, but not a known user, then Tomcat treats it the same way that it would Basic or Form. This isn't that big of an issue, for the simple reason that browsers generally don't give you the option to re-select a cert once you've chosen one. You're stuck having to close the browser and start all over again. With some guidance on the above, assuming that some code changes will be required, I'll set about writing a patch. Note: Although the bug is reported against 4.1.24, the same behaviour is seen with the latest 4.x.x and 5.x.x Regards, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Embedded tomcat with HTTPS
I'm going to assume that you're using 4.1.x. In this case, you are using the wrong Factory. You want something like: Connector httpsConnector = embeddedTomcat.createConnector(null, configuration.getHttpsPort(), true); CoyoteServerSocketFactory serverSocketFactory = (CoyoteServerSocketFactory)httpsConnector.getFactory(); serverSocketFactory.setKeystoreFile(configuration.getKeystoreFile()); serverSocketFactory.setKeystorePass(antares); - Original Message - From: Wesley Hall [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, August 10, 2003 1:23 PM Subject: Embedded tomcat with HTTPS Hello, Myself and a collegue are currently working on an open source application, part of which involves embedding a servlet engine. I have read through some tutorials and the API docs for tomcat and began development of a class structure to provide this. I have, however come across a problem with my https connector. I currently have code that looks like this.. Connector httpsConnector = embeddedTomcat.createConnector(null, configuration.getHttpsPort(), true); httpsConnector.setScheme(https); SSLServerSocketFactory serverSocketFactory = new SSLServerSocketFactory(); serverSocketFactory.setKeystoreFile(configuration.getKeystoreFile()); serverSocketFactory.setKeystorePass(antares); httpsConnector.setFactory(serverSocketFactory); embeddedTomcat.addConnector(httpsConnector); connectors.add(httpsConnector); configuration is a instance of a simple bean, getHttpsPort() returns 443, getKeystoreFile() returns the path to the keystore (generated as per the SSL-Howto doc). The location of the keystore is validated elsewhere in the code using a File object and a call to .isFile() and .canRead(), both of which return true when running this code. However... i am finding that although http://localhost:443 works perfectly, https://localhost leaves the browser (MSIE) whirring away for 30 seconds or so before displaying 'cannot find server'. With the former i get plenty of information in the logs but the latter adds nothing at all to the logs, making this problem very difficult to debug. I can change the keystore pass to any value and there is no appreciable difference. Im happy to provide any more information as required... Would a kind sameritan type point me in the write direction as to what may be causing this issue? Regards Wesley I. Hall. P.S. I thought long and hard on whether this belonged on dev or user, but since we are discussing actually class structure i finally decided that dev would probably be more appropriate. If i was wrong on that descision, you have my sincere apologies. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.7] New build by Sunday
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Saturday, August 09, 2003 2:00 AM Subject: Re: [5.0.7] New build by Sunday Bill Barker wrote: All the bugs so far are with the (brand new) procrun for NT. Bugs 18220, 21279 (IMO, to make things more reliable and keep it simple, procrun should wait for the child VM to die before stopping everything, rather than simply waiting until the stop method returns), 22174. 5.0.8 is good enough :) It turns out that I had a bit of spare time this afternoon to look at this. I can give you a tomcat(w) that fixes 21279 and 22174. The binaries will be Great :) for my code, since I don't have CVS access here, and don't feel like doing the merge with JFC's commit manually. I'm confused. I saw your commits and new binaries. What's missing ? JFC made commits in the morning (for better cygwin support). However, looking at his, they only affect the debug build, not the release build that I checked in. Thanks, Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
