Re: Tomcat authorization handling seems not to function according to Servlet 2.4 Spec
At 10:03 PM 12/8/2003 -0800, you wrote: The decision on whether to change the Realm interface, or move the header processing to AuthenticatorBase is still open. So soon after such a major release it seems foolhardy to bring this up, but Phillipe's post seems to have opened a can of worms Are there any plans to do anything about JSR-115? As it's part of the J2EE 1.4 spec, I would think that for a compliant appserver to embed Tomcat (any others besides JBoss??), Tomcat would need to comply. I bring this up because if there is consideration of API changes to deal w/ the Servlet 2.4 authorization handling, it might be a good time to look into it. I'd be happy to help in such an effort if there is any interest. Brian Stansberry WAN Concepts, Inc. www.wanconcepts.com Tel:(510) 894-0114 x 116 Fax:(510) 797-3005 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25354] New: - Problem with servlet 2.3, filters servlet or jsp !
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=25354. 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=25354 Problem with servlet 2.3, filters servlet or jsp ! Summary: Problem with servlet 2.3, filters servlet or jsp ! Product: Tomcat 4 Version: 4.1.24 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have written a filter to get original response and change the response contnents using tomcat4.1.24, it works for static content(html page), when I access a servlet or jsp page, i can't get the original response. if i change servlet doGet method, replace response.getOutputStream() with response.getWriter (), i can get original response again. I try other tomcat version, my program works below version 4.1.12, but error highter than 4.1.24. maybe it is a bug? if u need my source code, pls give me email, i send u. thx! danielqian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21561] - jk_uriEnv.c version 1.49 does not handle uri's with asterix
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=21561. 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=21561 jk_uriEnv.c version 1.49 does not handle uri's with asterix --- Additional Comments From [EMAIL PROTECTED] 2003-12-09 09:15 --- Stefan's fix is the same as the one done in version 1.51 on Oct 30, 2003 by mturk. So this bug's resolution can be changed to 'FIXED'. - 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
[EMAIL PROTECTED] wrote: amyroh 2003/12/08 16:50:58 Modified:catalina/src/share/org/apache/catalina/realm RealmBase.java Log: Strip out uri parameters (;*) during filter mappings or security constraints matching - bugtraq 4903209. -1 for all these patches. I'd like an explanation of what the problem actually is (all URI parameters are stripped early on before going in the Catalina pipeline). Rémy - 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
[EMAIL PROTECTED] wrote: amyroh 2003/12/08 17:54:33 Modified:catalina/src/share/org/apache/catalina/core ApplicationFilterFactory.java catalina/src/share/org/apache/catalina/realm RealmBase.java Log: Revert the patch. Seems like this case is already handled in the Mapper in TC5. M, forget my -1 (I should read *all* my email before replying) :-D Note that there's an open bug about this: bug 25015 (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25015). Could you get some spec related folk to comment on it ? The ex was: http://localhost/appname/servlet-name/extra;path/info;here/hi.jsp Looking at the URI RFC, I think this should be changed to: http://localhost/appname/servlet-name/extra/info/hi.jsp Rémy - 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
Bill Barker wrote: 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. I don't care much about this problem. Constraint composition is too complex for the real world, and generally container provided auth is just bad to use in real websites. This plus the fact that those changes are brand new (and apparently not tested by Sun's compatibility kit, or Jean François would have done something about it). So this should not impact many people. I'm ok to change the Realm interface, as there's a RealmBase abstract class. I would believe most realms extend it, so there shouldn't be too much trouble. We should take ample time to fix this, to make sure this is correct when done :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25263] - Incorrect SMAP generated for JSP
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=25263. 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=25263 Incorrect SMAP generated for JSP --- Additional Comments From [EMAIL PROTECTED] 2003-12-09 10:03 --- I don't agree with merging the debug parameters, as they impact different things. For instance, to use mappedfile, you had to remove the old generated JSPs. The development flag OTOH will be used right away. For production, the only real setting is to precompile the JSPs. Everything else is not relevant and you can use the defaults (avoid enabling the background compilation thread, of course ;-) ). I think the defaults should be tweaked a bit: - mappedfile should be true by default in the normal Jasper (as development is true) - mappedfile should be false by default when precompiling Other defaults could be adjusted like this, with the general intent being what you want (but without a super dev flag). - 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
Brian Stansberry wrote: At 10:03 PM 12/8/2003 -0800, you wrote: The decision on whether to change the Realm interface, or move the header processing to AuthenticatorBase is still open. So soon after such a major release it seems foolhardy to bring this up, but Phillipe's post seems to have opened a can of worms Are there any plans to do anything about JSR-115? As it's part of the J2EE 1.4 spec, I would think that for a compliant appserver to embed Tomcat (any others besides JBoss??), Tomcat would need to comply. I bring this up because if there is consideration of API changes to deal w/ the Servlet 2.4 authorization handling, it might be a good time to look into it. I'd be happy to help in such an effort if there is any interest. I'll be looking into this. I don't know yet if the web related parts belong more to the appserver (JBoss), or more to the servlet container. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25360] New: - request.setCharacterEncoding(String enc) does not work.
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=25360.
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=25360
request.setCharacterEncoding(String enc) does not work.
Summary: request.setCharacterEncoding(String enc) does not work.
Product: Tomcat 5
Version: 5.0.16
Platform: All
OS/Version: All
Status: NEW
Severity: Normal
Priority: Other
Component: Connector:Coyote
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Maybe it is a bug in class CoyoteRequest, my solution is here:
diff -u CoyoteRequest.java.old CoyoteRequest.java.new
--- CoyoteRequest.java.old 2003-12-09 21:51:57.0 +0800
+++ CoyoteRequest.java.new 2003-12-09 21:52:23.0 +0800
@@ -2325,9 +2325,9 @@
String enc = coyoteRequest.getCharacterEncoding();
if (enc != null) {
-parameters.setEncoding(enc);
+parameters.setQueryStringEncoding(enc);
} else {
-parameters.setEncoding
+parameters.setQueryStringEncoding
(org.apache.coyote.Constants.DEFAULT_CHARACTER_ENCODING);
}
-
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
How do I join as Developer... Basu. - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, December 09, 2003 3:12 PM Subject: Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm RealmBase.java [EMAIL PROTECTED] wrote: amyroh 2003/12/08 17:54:33 Modified:catalina/src/share/org/apache/catalina/core ApplicationFilterFactory.java catalina/src/share/org/apache/catalina/realm RealmBase.java Log: Revert the patch. Seems like this case is already handled in the Mapper in TC5. M, forget my -1 (I should read *all* my email before replying) :-D Note that there's an open bug about this: bug 25015 (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25015). Could you get some spec related folk to comment on it ? The ex was: http://localhost/appname/servlet-name/extra;path/info;here/hi.jsp Looking at the URI RFC, I think this should be changed to: http://localhost/appname/servlet-name/extra/info/hi.jsp Rémy - 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]
DO NOT REPLY [Bug 25263] - Incorrect SMAP generated for JSP
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=25263. 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=25263 Incorrect SMAP generated for JSP --- Additional Comments From [EMAIL PROTECTED] 2003-12-09 15:08 --- That sounds reasonable. Just getting mappedfile to default true, since debugging is on anyway would be great. I agree that the additional flexibility of the current model certainly has its place. Nice compromise. +1 (as if I get to vote here ;-) - 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
Brian Stansberry wrote: At 10:03 PM 12/8/2003 -0800, you wrote: The decision on whether to change the Realm interface, or move the header processing to AuthenticatorBase is still open. So soon after such a major release it seems foolhardy to bring this up, but Phillipe's post seems to have opened a can of worms Are there any plans to do anything about JSR-115? As it's part of the J2EE 1.4 spec, I would think that for a compliant appserver to embed Tomcat (any others besides JBoss??), Tomcat would need to comply. I bring this up because if there is consideration of API changes to deal w/ the Servlet 2.4 authorization handling, it might be a good time to look into it. I'd be happy to help in such an effort if there is any interest. All you have to do to comply with jsr115 is to extends RealmBase and override: - hasUserDataPermission - hasRole - hasResourcePermission - findSecurityConstraint A couple of months ago (search the tomcat-dev list) we have discussed the possibility of implementing jsr115 directly into Tomcat. Still on my plate (don't know when) J2EE 1.4 RI contains Tomcat 5 powered by jsr 115. The problem with jsr115 is you have to run under a Security Manager, and this is for sure slower than the current native implementation. -- Jeanfrancois Brian Stansberry WAN Concepts, Inc. www.wanconcepts.com Tel:(510) 894-0114 x 116 Fax:(510) 797-3005 - 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]
DO NOT REPLY [Bug 25360] - request.setCharacterEncoding(String enc) does not work.
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=25360. 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=25360 request.setCharacterEncoding(String enc) does not work. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-12-09 16:10 --- Thanks, we were not aware of that bug ;-) IMO, you should look into tomcat-dev's archives for the full details. BTW, in your patch, you should leave the setEncoding method call, also (it's useful for the POST body, if any). I sort of changed my mind on the subject, and I could be talked into adding a compatibility boolean flag to the connector, if the default stays to using a separate encoding for the URI parameters. - 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
Jeanfrancois Arcand wrote: Brian Stansberry wrote: At 10:03 PM 12/8/2003 -0800, you wrote: The decision on whether to change the Realm interface, or move the header processing to AuthenticatorBase is still open. So soon after such a major release it seems foolhardy to bring this up, but Phillipe's post seems to have opened a can of worms Are there any plans to do anything about JSR-115? As it's part of the J2EE 1.4 spec, I would think that for a compliant appserver to embed Tomcat (any others besides JBoss??), Tomcat would need to comply. I bring this up because if there is consideration of API changes to deal w/ the Servlet 2.4 authorization handling, it might be a good time to look into it. I'd be happy to help in such an effort if there is any interest. All you have to do to comply with jsr115 is to extends RealmBase and override: - hasUserDataPermission - hasRole - hasResourcePermission - findSecurityConstraint A couple of months ago (search the tomcat-dev list) we have discussed the possibility of implementing jsr115 directly into Tomcat. Still on my plate (don't know when) J2EE 1.4 RI contains Tomcat 5 powered by jsr 115. The problem with jsr115 is you have to run under a Security Manager, and this is for sure slower than the current native implementation. I think you'll have an opportunity to make your changes if you want to, since we'll have some refactoring to do on the realm before the next stable 5.0.x release occurs. Did you do benches ? Comparing (4.1.x) vs (5.0.x) vs (5.0.x + sec manager), for example. I wouldn't be surprised if the last one benches as well as the first one (which would be really cool). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25263] - Incorrect SMAP generated for JSP
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=25263. 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=25263 Incorrect SMAP generated for JSP --- Additional Comments From [EMAIL PROTECTED] 2003-12-09 16:23 --- Just from looking at the code for the fix, I think it will still give the wrong SMAP for TemplateText nodes longer than JspUtil.CHUNKSIZE. Generator.java advances the output line when JspUtil.CHUNKSIZE is exceeded, so the SMAPping code should too. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25363] New: - request.getAttributeNames() not working properly
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=25363.
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=25363
request.getAttributeNames() not working properly
Summary: request.getAttributeNames() not working properly
Product: Tomcat 5
Version: 5.0.16
Platform: All
OS/Version: All
Status: NEW
Severity: Normal
Priority: Other
Component: Connector:JK 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
When request attributes are sent by mod_jk from Apache to Tomcat5.0.16's Coyote
AJP/1.3 handler, these attributes are not listed by request.getAttributeNames().
They are accesible when specificaly asked for them using request.getAttribute(),
but even after this they are not listed by request.getAttributeNames().
Steps to reproduce:
1) set up Apache with SSL support and mod_jk (or mod_jk2)
2) enable sending SSL attributes in httpd.conf using
LoadModule jk_module libexec/mod_jk1.2.5.so
JkWorkersFile /etc/httpd/workers.properties
JkLogFile /var/log/httpd/mod_jk.log
JkLogLevel info
JkOptions +ForwardKeySize +ForwardURIEscaped -ForwardDirectories
JkExtractSSL On
JkEnvVar SSL_PROTOCOL default
JkEnvVar SSL_VERSION_INTERFACE default
JkMount /mywebapp/* myworker
Location /mywebapp/*
SSLOptions +ExportCertData +StdEnvVars
/Location
3) in Tomcat, in webapplication mywebapp create a JSP page with following code:
bEnumerated request attributes:/bbr
%java.util.Enumeration en1=request.getAttributeNames();
while(en1.hasMoreElements()) {
String name = (String)en1.nextElement();
out.println(name+=+request.getAttribute(name)+br);
}%
bAsked request attributes:/bbr
javax.servlet.request.cipher_suite=%=request.getAttribute(javax.servlet.request.cipher_suite)
%br
javax.servlet.request.key_size=%=request.getAttribute(javax.servlet.request.key_size)
%br
javax.servlet.request.X509Certificate=%=request.getAttribute(javax.servlet.request.X509Certificate)
%br
javax.servlet.request.ssl_session=%=request.getAttribute(javax.servlet.request.ssl_session)
%br
SSL_PROTOCOL=%=request.getAttribute(SSL_PROTOCOL) %br
SSL_VERSION_INTERFACE=${SSL_VERSION_INTERFACE}br
bAgain enumerated request attributes:/bbr
%java.util.Enumeration en2=request.getAttributeNames();
while(en2.hasMoreElements()) {
String name = (String)en2.nextElement();
out.println(name+=+request.getAttribute(name)+br);
}%
4) access the page from a webbrowser. The page will display:
Enumerated request attributes:
Asked request attributes:
javax.servlet.request.cipher_suite=RC4-MD5
javax.servlet.request.key_size=128
javax.servlet.request.X509Certificate=[Ljava.security.cert.X509Certificate;@199197b
javax.servlet.request.ssl_session=78DE7EA098961A94E2C37B410FEFCAEA4B2ACD8D8A15199AF52CED901083D870
SSL_PROTOCOL=TLSv1
SSL_VERSION_INTERFACE=mod_ssl/2.8.15
Again enumerated request attributes:
javax.servlet.request.cipher_suite=RC4-MD5
javax.servlet.request.key_size=128
javax.servlet.request.X509Certificate=[Ljava.security.cert.X509Certificate;@199197b
It means, that some request attribute names are listed after they were
specificaly asked, but not before, and not all of them.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25364] New: - mod_jk2 cannot send additional request attributes
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=25364. 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=25364 mod_jk2 cannot send additional request attributes Summary: mod_jk2 cannot send additional request attributes Product: Tomcat 5 Version: 5.0.16 Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Native:JK AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] In mod_jk1, it is possible to send additional request attributes using directive JkEnvVar CGI_variable default_value This is useful for passing information produced by other Apache modules, typically some authentication modules. But in mod_jk2 there is no setting for this. I found that in file jk/native2/include/jk_workerEnv.h there are defined members envvars_in_use and envvars in struct jk_workerEnv to enable this feature and name CGI variables to pass, and even in file jk/native2/server/apache13/jk_service_apache13.c there is code which sends values of CGI variables stored in workerEnv-envvar, but there is no way how to set envvar from workers2.properties - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25363] - request.getAttributeNames() not working properly
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=25363. 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=25363 request.getAttributeNames() not working properly [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Minor --- Additional Comments From [EMAIL PROTECTED] 2003-12-09 17:37 --- Voting for a bug is stupid ;-) If you care, submit a patch (although I'd say it may not be accepted, the issue is complex). I think this issue may be partially addressed (the parameter will show up in the list), as I see something odd in the getParameter from TC 5 in the adaptor code. For the rest, this may not be fixed; we'll see. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25364] - mod_jk2 cannot send additional request attributes
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=25364. 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=25364 mod_jk2 cannot send additional request attributes [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2003-12-09 17:38 --- I suggest you use mod_jk1, as mod_jk2 will need a significant amount of additional dev. So enh won't be accepted unless you post a patch. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jakarta-servletapi-4
Does anyone object to me tagging head of this module with TOMCAT_4_1_29 ? Keith - 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
Remy Maucherat wrote: Jeanfrancois Arcand wrote: Brian Stansberry wrote: At 10:03 PM 12/8/2003 -0800, you wrote: The decision on whether to change the Realm interface, or move the header processing to AuthenticatorBase is still open. So soon after such a major release it seems foolhardy to bring this up, but Phillipe's post seems to have opened a can of worms Are there any plans to do anything about JSR-115? As it's part of the J2EE 1.4 spec, I would think that for a compliant appserver to embed Tomcat (any others besides JBoss??), Tomcat would need to comply. I bring this up because if there is consideration of API changes to deal w/ the Servlet 2.4 authorization handling, it might be a good time to look into it. I'd be happy to help in such an effort if there is any interest. All you have to do to comply with jsr115 is to extends RealmBase and override: - hasUserDataPermission - hasRole - hasResourcePermission - findSecurityConstraint A couple of months ago (search the tomcat-dev list) we have discussed the possibility of implementing jsr115 directly into Tomcat. Still on my plate (don't know when) J2EE 1.4 RI contains Tomcat 5 powered by jsr 115. The problem with jsr115 is you have to run under a Security Manager, and this is for sure slower than the current native implementation. I think you'll have an opportunity to make your changes if you want to, since we'll have some refactoring to do on the realm before the next stable 5.0.x release occurs. That's a pretty good opportunityFor reference, here is the link to my original proposal http://www.mail-archive.com/[EMAIL PROTECTED]/msg39894.html My original idea was to remove the current Authenticator - Realm dependency. Currently, the Realm is doing Authorization and Authentication, which I think should be splitted. Did you do benches ? Comparing (4.1.x) vs (5.0.x) vs (5.0.x + sec manager), for example. I wouldn't be surprised if the last one benches as well as the first one (which would be really cool). Not yet, but it is one of the thing I want to do when I've found spare time. For sure (5.0.x + sec manager) is faster than (5.0.x + sec manager + jsr115) since with 115, the policy provider is called everytime hasUser/ResourcePermission are called, and this approach cannot beat the current way of doing. On the original topic, I think I've missed the spec change from pfd3 and fcs. I was under the wrong impression that Bill's last changes on the RealmAdapter was related to that changes (I was completely wrong). I will try to find the reason whythe change was make... Now the only problem I'm seeing with Phillipe's work is Strings are used everywhere and that may have a performance impact. It may be time to start using MessageByte. -- Jeanfrancois Rémy - 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: Tomcat authorization handling seems not to function according to Servlet 2.4 Spec
Jeanfrancois Arcand wrote: Remy Maucherat wrote: Jeanfrancois Arcand wrote: Brian Stansberry wrote: At 10:03 PM 12/8/2003 -0800, you wrote: The decision on whether to change the Realm interface, or move the header processing to AuthenticatorBase is still open. So soon after such a major release it seems foolhardy to bring this up, but Phillipe's post seems to have opened a can of worms Are there any plans to do anything about JSR-115? As it's part of the J2EE 1.4 spec, I would think that for a compliant appserver to embed Tomcat (any others besides JBoss??), Tomcat would need to comply. I bring this up because if there is consideration of API changes to deal w/ the Servlet 2.4 authorization handling, it might be a good time to look into it. I'd be happy to help in such an effort if there is any interest. All you have to do to comply with jsr115 is to extends RealmBase and override: - hasUserDataPermission - hasRole - hasResourcePermission - findSecurityConstraint A couple of months ago (search the tomcat-dev list) we have discussed the possibility of implementing jsr115 directly into Tomcat. Still on my plate (don't know when) J2EE 1.4 RI contains Tomcat 5 powered by jsr 115. The problem with jsr115 is you have to run under a Security Manager, and this is for sure slower than the current native implementation. I think you'll have an opportunity to make your changes if you want to, since we'll have some refactoring to do on the realm before the next stable 5.0.x release occurs. That's a pretty good opportunityFor reference, here is the link to my original proposal http://www.mail-archive.com/[EMAIL PROTECTED]/msg39894.html My original idea was to remove the current Authenticator - Realm dependency. Currently, the Realm is doing Authorization and Authentication, which I think should be splitted. Did you do benches ? Comparing (4.1.x) vs (5.0.x) vs (5.0.x + sec manager), for example. I wouldn't be surprised if the last one benches as well as the first one (which would be really cool). Not yet, but it is one of the thing I want to do when I've found spare time. For sure (5.0.x + sec manager) is faster than (5.0.x + sec manager + jsr115) since with 115, the policy provider is called everytime hasUser/ResourcePermission are called, and this approach cannot beat the current way of doing. On the original topic, I think I've missed the spec change from pfd3 and fcs. I was under the wrong impression that Bill's last changes on the RealmAdapter was related to that changes (I was completely wrong). I will try to find the reason whythe change was make... Now the only problem I'm seeing with Phillipe's work is Strings are used everywhere and that may have a performance impact. It may be time to start using MessageByte. That's the idea. If you're inside the container and you consider it a critical section for whatever reason, then strings are really evil, and you should use MessageBytes instead (or even ByteChunks if manipulating header values) ;-) I see supporing JSR 115 would be good, but making it disabled by default when there's a security manager would be the most reasonable. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25367] New: - SECURITY requests for jsp pages bypass apache AuthUserFile directive
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=25367. 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=25367 SECURITY requests for jsp pages bypass apache AuthUserFile directive Summary: SECURITY requests for jsp pages bypass apache AuthUserFile directive Product: Tomcat 4 Version: 4.1.18 Platform: PC OS/Version: Linux Status: NEW Severity: Major Priority: Other Component: Connector:JK/AJP (deprecated) AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have this in my apache config: Directory /local/webapps/wa AuthType Basic AuthName wa AuthUserFile /usr/local/apache2/passwd/wa require user admins /Directory This will block requests for html files, even /server-status, but not jsps. I'm using jk connector 1.2.5 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jakarta-servletapi-4
If you can wait a day or so I have some fixes to the javadoc comments to commit. Only affects javadoc warnings during build so no problem if you need to go ahead without them. I need to figure out how to use my newly acquired commit privs before I can make the changes ;) Mark On Tuesday, December 09, 2003 5:56 PM, Keith Wannamaker [SMTP:[EMAIL PROTECTED] wrote: Does anyone object to me tagging head of this module with TOMCAT_4_1_29 ? Keith - 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: becoming a devloper/contributor
On Tue, Dec 09, 2003 at 06:10:18PM +0530, Basavaraju P. Banakar wrote: How do I join as Developer... First, form questions as questions. Second, don't hijack random threads with unrelated subject lines. Third, you already are a developer. Just report bugs and propose patches for open bugs. Fourth, read up on the Get Involved pages: http://jakarta.apache.org/site/getinvolved.html Eventually, having proven your worth, you may get voted into having CVS commit access. -- [EMAIL PROTECTED] Some people have a way with words, while others... erm... thingy. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jakarta-servletapi-4
Works for me -- no rush. How about just tag it once you've checked those doc warning fixes in? :-) Keith | -Original Message- | From: Mark Thomas [mailto:[EMAIL PROTECTED] | Sent: Tuesday, December 09, 2003 2:03 PM | To: 'Tomcat Developers List' | Subject: RE: jakarta-servletapi-4 | | | If you can wait a day or so I have some fixes to the javadoc comments to | commit. Only affects javadoc warnings during build so no problem if you need to | go ahead without them. I need to figure out how to use my newly acquired commit | privs before I can make the changes ;) | | Mark | | On Tuesday, December 09, 2003 5:56 PM, Keith Wannamaker | [SMTP:[EMAIL PROTECTED] wrote: | Does anyone object to me tagging head of this module with TOMCAT_4_1_29 ? | | Keith | | | - | 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]
DO NOT REPLY [Bug 25369] New: - mod_jk source package omits example configuration files
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=25369. 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=25369 mod_jk source package omits example configuration files Summary: mod_jk source package omits example configuration files Product: Tomcat 4 Version: 4.1.29 Platform: All OS/Version: All Status: NEW Severity: Minor Priority: Other Component: Connector:JK/AJP (deprecated) AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The jakarta-tomcat-connectors-jk-1.2.5-src distribution tarball has no files in jk/conf, where one would expect to find the example configuration files for mod_jk. They appear to be present in CVS. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25371] New: - tomcat.exe does nothing on XP
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=25371. 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=25371 tomcat.exe does nothing on XP Summary: tomcat.exe does nothing on XP Product: Tomcat 5 Version: 5.0.16 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Native:Integration AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] On Windows XP, the bundled tomcat.exe did nothing. I've seen this on my box and a friend's machine as well. I downloaded the latest JavaService from http://www.alexandriasc.com/software/JavaService/index.html and all went as advertised. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25371] - tomcat.exe does nothing on XP
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=25371. 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=25371 tomcat.exe does nothing on XP [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-12-09 20:37 --- JavaService does have its own problems, including the fact that it is no longer supported. I recommend you try the wrapper project which is in SF.net. As for the included .exe wrapper, it should work ok as long as Java is installed correctly, and you use the installer to set it up. - 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
Remy Maucherat wrote: [EMAIL PROTECTED] wrote: amyroh 2003/12/08 17:54:33 Modified:catalina/src/share/org/apache/catalina/core ApplicationFilterFactory.java catalina/src/share/org/apache/catalina/realm RealmBase.java Log: Revert the patch. Seems like this case is already handled in the Mapper in TC5. M, forget my -1 (I should read *all* my email before replying) :-D Note that there's an open bug about this: bug 25015 (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25015). Could you get some spec related folk to comment on it ? Servlet spec folks talked about this (parameters in path and whether getpathinfo should return them or not), and they couldn't get the consensus. Most people seem to like that getPathInfo should NOT include the parameters, but we haven't had a thorough discussion and that's listed as an item for the next version of the spec. So, for now, it's container-specific but the servlet spec lead recommends to remove them. Amy The ex was: http://localhost/appname/servlet-name/extra;path/info;here/hi.jsp Looking at the URI RFC, I think this should be changed to: http://localhost/appname/servlet-name/extra/info/hi.jsp Rémy - 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]
DO NOT REPLY [Bug 25373] New: - Timestamp on generated .java and .class should match the one on .jsp
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=25373. 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=25373 Timestamp on generated .java and .class should match the one on .jsp Summary: Timestamp on generated .java and .class should match the one on .jsp Product: Tomcat 4 Version: 4.0.4 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The timestamp on generated .java and .class files is the time when they are generated and this can cause problems. The timestamp on these files should be exactly the same timestamp as the one on the corresponding .jsp file. Here is an example: - revision 6 of a file called index.jsp is timestamped at May 10, 10:00 am - this revision 6 is labeled and branched for a production rollout - the main branch gets a new revision, not meant for rollout yet: revision 7 at May 11, 9:00 am - the production is finally rolled out on May 12 and the page gets compiled upon the first hit at May 12, 3:00 pm - the index.java and index.class files are stamped with May 12, 3:00 pm - in a month a new production rollout, now revision 7 of index.jsp makes it to the production server - the timestamps are as follows at this point (on the production server): - index.jsp: May 11, 9:00 am (revision 7) - index.java and index.class: May 12, 3:00 pm (based on revision 6) - hits on index.jsp will not trigger a recompile even though they should - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25374] New: - SEVERE: Exception in acceptSocket
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=25374. 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=25374 SEVERE: Exception in acceptSocket Summary: SEVERE: Exception in acceptSocket Product: Tomcat 4 Version: 4.1.27 Platform: PC OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Per bug 18182 this was fixed in version 4.1.24 but, as you will see, the problem still occurs in 4.1.27. Here is the significant lines taken from the catalina.out file: (I will attach the stack trace after this is saved) (I will add a comment detailing my system info then too) Dec 9, 2003 11:22:15 AM org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler processConnection SEVERE: Error reading request, ignored java.lang.OutOfMemoryError ActionServlet.service() reporting error for classname = ActionServlet.service() reporting error for classname = Dec 9, 2003 11:22:51 AM org.apache.tomcat.util.net.TcpWorkerThread runIt SEVERE: Exception in acceptSocket java.lang.OutOfMemoryError Dec 9, 2003 11:22:51 AM org.apache.tomcat.util.threads.ThreadPool$ControlRunnable run SEVERE: Caught exception executing [EMAIL PROTECTED], terminating thread java.lang.IllegalStateException: Terminating thread at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:532) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619) at java.lang.Thread.run(Thread.java:536) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25374] - SEVERE: Exception in acceptSocket
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=25374. 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=25374 SEVERE: Exception in acceptSocket --- Additional Comments From [EMAIL PROTECTED] 2003-12-09 22:24 --- Created an attachment (id=9472) stack trace - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25374] - SEVERE: Exception in acceptSocket
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=25374. 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=25374 SEVERE: Exception in acceptSocket --- Additional Comments From [EMAIL PROTECTED] 2003-12-09 22:30 --- System Info: SuSE Linux 8.1 Sun Java 1.4.1_01-b01 Tomcat 4.1.27 (using both SSL and Non-SSL connectors on 8XXX ports) SAPDB 7.3.0.34 Struts 1.0 (I think...maybe 1.1) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25374] - SEVERE: Exception in acceptSocket
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=25374. 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=25374 SEVERE: Exception in acceptSocket --- Additional Comments From [EMAIL PROTECTED] 2003-12-09 22:35 --- I did notice on bug 22701 that there was a patch issued for 4.1.27 and that subsequent versions (.28 and .29) are supposed to have the fix built-in but that is for a commons-logging/log4j problem. If mine and it are one in the same then please forgive me and feel free to close this bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25374] - SEVERE: Exception in acceptSocket
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=25374. 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=25374 SEVERE: Exception in acceptSocket [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-12-09 22:40 --- I think you should post on tomcat-user. This needs debugging, as the issue is not reproduceable by itself. I recommend trying a newer Tomcat release if you can, such as 5.0.16 (just to make sure this wasn't caused by a bug which was fixed since - I don't think so, but who knows). Similarly, you should upgrade to Sun 1.4.2 if you can (it's faster), and verify (and post) your VM settings, in particular the memory related ones. Reopen the report if you can isolate the problem more. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25374] - SEVERE: Exception in acceptSocket
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=25374. 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=25374 SEVERE: Exception in acceptSocket --- Additional Comments From [EMAIL PROTECTED] 2003-12-09 22:43 --- The commons-logging issue should not related, but is an important fix. The problem was that the context classloader was not properly reset at the end of the request processing, which worked relatively well until the introduction of commons-logging in the connector. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[wiki] wiki.apache.org migration
I would be interested in a Wiki for Tomcat. It has been somewhat helpful as a complement to the Tomcat FAQ. AFAICT, there is not a lot of Tomcat content on the Wiki, so moving over the relevant information should be easy. [cc'd the tomcat-dev list to determine other's interest in this] -Tim Leo Simons wrote: Hi all! Over the past few weeks we've been busy getting a wiki set up at http://wiki.apache.org/ It is our intention to migrate the UseMod materials on Nagoya to this MoinMoin-based variant. All ASF projects that use a wiki or are interested in doing so are encouraged to read http://wiki.apache.org/general/UseModMigration and contact infrastructure at apache dotorg so that we can help migrate your data. - 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/session StandardManager.java
[EMAIL PROTECTED] wrote:
remm2003/12/05 01:28:55
Modified:catalina/src/share/org/apache/catalina/session
StandardManager.java
Log:
- isValid already expires sessions, so backgroundProcess shouldn't call
expire again.
isValid doesn't *always* expire session.
StandardSession.isValid() -
public boolean isValid() {
if (this.expiring){
return true;
}
if (!this.isValid ) {
*** return false;
}
if (maxInactiveInterval = 0) {
long timeNow = System.currentTimeMillis();
int timeIdle = (int) ((timeNow - lastAccessedTime) / 1000L);
if (timeIdle = maxInactiveInterval) {
*** expire(true);
}
}
return (this.isValid);
}
If StandardSession.isValid is false, then we want to expire the session.
However, isValid() call doesn't get to expire(true) and just return
false. So removing session.expire() from
StandardManager.processExpires() won't work all the time. Am I missing
something?
Thanks,
Amy
- Bug 25234, submitted by Paul Harvey.
Revision ChangesPath
1.16 +5 -11 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StandardManager.java
Index: StandardManager.java
===
RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StandardManager.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- StandardManager.java 29 Nov 2003 18:06:35 - 1.15
+++ StandardManager.java 5 Dec 2003 09:28:55 - 1.16
@@ -813,13 +813,7 @@
for (int i = 0; i sessions.length; i++) {
StandardSession session = (StandardSession) sessions[i];
if (!session.isValid()) {
-try {
-expiredSessions++;
-session.expire();
-} catch (Throwable t) {
-log.error(sm.getString
- (standardManager.expireException), t);
-}
+expiredSessions++;
}
}
long timeEnd = System.currentTimeMillis();
-
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]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties
kinman 2003/12/09 16:24:23
Modified:jasper2/src/share/org/apache/jasper/compiler
TagFileProcessor.java
jasper2/src/share/org/apache/jasper/resources
messages.properties
Log:
- The spec allows an attribute to be specified in multple tag directives,
if they have the same value. It is an error if not.
Revision ChangesPath
1.55 +27 -8
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagFileProcessor.java
Index: TagFileProcessor.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagFileProcessor.java,v
retrieving revision 1.54
retrieving revision 1.55
diff -u -r1.54 -r1.55
--- TagFileProcessor.java 5 Dec 2003 18:33:19 - 1.54
+++ TagFileProcessor.java 10 Dec 2003 00:24:23 - 1.55
@@ -142,6 +142,7 @@
private String smallIcon = null;
private String largeIcon = null;
private String dynamicAttrsMapName;
+private String example = null;
private Vector attributeVector;
private Vector variableVector;
@@ -176,7 +177,7 @@
JspUtil.checkAttributes(Tag directive, n, tagDirectiveAttrs,
err);
-bodycontent = n.getAttributeValue(body-content);
+bodycontent = checkConflict(n, bodycontent, body-content);
if (bodycontent != null
!bodycontent.equalsIgnoreCase(TagInfo.BODY_CONTENT_EMPTY)
!bodycontent.equalsIgnoreCase(TagInfo.BODY_CONTENT_TAG_DEPENDENT)
@@ -184,15 +185,33 @@
err.jspError(n, jsp.error.tagdirective.badbodycontent,
bodycontent);
}
-dynamicAttrsMapName = n.getAttributeValue(dynamic-attributes);
+dynamicAttrsMapName = checkConflict(n, dynamicAttrsMapName,
+dynamic-attributes);
if (dynamicAttrsMapName != null) {
checkUniqueName(dynamicAttrsMapName, TAG_DYNAMIC, n);
}
-smallIcon = n.getAttributeValue(small-icon);
-largeIcon = n.getAttributeValue(large-icon);
-description = n.getAttributeValue(description);
-displayName = n.getAttributeValue(display-name);
+smallIcon = checkConflict(n, smallIcon, small-icon);
+largeIcon = checkConflict(n, largeIcon, large-icon);
+description = checkConflict(n, description, description);
+displayName = checkConflict(n, displayName, display-name);
+example = checkConflict(n, example, example);
}
+
+private String checkConflict(Node n, String oldAttrValue, String attr)
+throws JasperException {
+
+String result = oldAttrValue;
+String attrValue = n.getAttributeValue(attr);
+if (attrValue != null) {
+if (oldAttrValue != null !oldAttrValue.equals(attrValue)) {
+err.jspError(n, jsp.error.tag.conflict.attr, attr,
+ oldAttrValue, attrValue);
+}
+result = attrValue;
+}
+return result;
+}
+
public void visit(Node.AttributeDirective n) throws JasperException {
1.136 +2 -1
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties
Index: messages.properties
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties,v
retrieving revision 1.135
retrieving revision 1.136
diff -u -r1.135 -r1.136
--- messages.properties 4 Dec 2003 19:37:58 - 1.135
+++ messages.properties 10 Dec 2003 00:24:23 - 1.136
@@ -67,6 +67,7 @@
jsp.error.page.invalid.iselignored=Page directive: invalid value for isELIgnored
jsp.error.tag.invalid.iselignored=Tag directive: invalid value for isELIgnored
jsp.error.page.multi.pageencoding=Page directive must not have multiple occurrences
of pageencoding
+jsp.error.tag.conflict.attr=Tag directive: illegal to have multiple occurrences of
the attribute \{0}\ with different values (old: {1}, new: {2})
jsp.error.tag.multi.pageencoding=Tag directive must not have multiple occurrences
of pageencoding
jsp.error.page.bad_b_and_a_combo=Page directive: Illegal combination of
buffer=\none\ autoFlush=\false\
jsp.error.not.impl.taglib=Internal error: Tag extensions not implemented
-
To unsubscribe, e-mail:
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session StandardManager.java
Amy Roh wrote:
[EMAIL PROTECTED] wrote:
remm2003/12/05 01:28:55
Modified:catalina/src/share/org/apache/catalina/session
StandardManager.java
Log:
- isValid already expires sessions, so backgroundProcess shouldn't call
expire again.
isValid doesn't *always* expire session.
StandardSession.isValid() -
public boolean isValid() {
if (this.expiring){
return true;
}
if (!this.isValid ) {
*** return false;
}
if (maxInactiveInterval = 0) {
long timeNow = System.currentTimeMillis();
int timeIdle = (int) ((timeNow - lastAccessedTime) / 1000L);
if (timeIdle = maxInactiveInterval) {
*** expire(true);
}
}
return (this.isValid);
}
If StandardSession.isValid is false, then we want to expire the session.
However, isValid() call doesn't get to expire(true) and just return
false. So removing session.expire() from
StandardManager.processExpires() won't work all the time. Am I missing
something?
There doesn't seem many methods changing isValid to false. invalidate is
another one, and it calls expire. As long as all the methods which
invalidate the session right away expire them, it should be ok I think.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25360] - request.setCharacterEncoding(String enc) does not work.
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=25360. 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=25360 request.setCharacterEncoding(String enc) does not work. --- Additional Comments From [EMAIL PROTECTED] 2003-12-10 02:55 --- Thanks for your reminding. I have reviewed the code. The parameters.setQueryStringEncoding method and the parameters.handleQueryParameters method handle the parameters in the encoded uri at both get and post method. Specially if the contentType equals application/x-www-form-urlencoded (the default encoding for all forms), it should deal with the parameters in the post body. The setEncoding method must be called before calling parameters.processParameters(formData, 0, len) method, otherwise you can call parameters.processParameters(formData, 0, len, enc) directly. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25360] - request.setCharacterEncoding(String enc) does not work.
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=25360. 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=25360 request.setCharacterEncoding(String enc) does not work. --- Additional Comments From [EMAIL PROTECTED] 2003-12-10 03:54 --- Created an attachment (id=9480) diff -u - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Memory Utilisation By TOMCAT JAVA Process.
Hi All I will highly appreciate if any one from this group would help to resolve the following issue. Problem Details:- We have one Apache (Ver 1.3.2.0) web server running on Red Hat 7.2 (Kernel version 2.4.7-10SMP). We have also included tomcat module in httpd.conf file. We are running JSPs on this server using Tomcat. Jakarta-Tomcat version is 3.2.3 and JDK version is 1.3.1. We are facing one peculiar issue the memory utilized by java process is huge so the server runs out of memory. We are doing very frequent reboots to resolve this issue as of now and not able to find the permanent solution to said problem. I am attaching the output of top command ps -eo pid,%mem,%cpu,cmd command out for more information on this issue. The number of JAVA process are over 50 at all times irrespective of active users. The apache-tomcat server also talks to oracle server in the backup end. We have confirmed that there is no problem with Database server connectivity. The apache tomcat configuration files are changed for any parameter as I am not sure about the impact on the server performance. Request all of you to contribute if any one has face and resolve such issue. Output of TOP command:- 10:11am up 4 days, 8:47, 2 users, load average: 0.38, 0.20, 0.07 187 processes: 185 sleeping, 1 running, 1 zombie, 0 stopped CPU0 states: 1.0% user, 12.0% system, 0.0% nice, 85.1% idle CPU1 states: 0.1% user, 5.0% system, 0.0% nice, 94.0% idle Mem: 2059536K av, 2052488K used,7048K free, 48K shrd, 120172K buff Swap: 1052216K av, 0K used, 1052216K free 1698648K cached PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 7679 m2i 18 0 1144 1144 856 R14.9 0.0 0:01 top 2807 m2i9 0 55828 54M 7200 S 1.6 2.7 0:09 java 31745 m2i 10 0 55828 54M 7200 S 0.8 2.7 1:01 java 1242 m2i9 0 1372 1372 1008 S 0.0 0.0 0:00 bash 2305 m2i8 0 1376 1376 1008 S 0.0 0.0 0:00 bash 7606 m2i9 0 1372 1372 1008 S 0.0 0.0 0:00 bash 31717 m2i9 0 55828 54M 7200 S 0.0 2.7 0:00 java 31744 m2i9 0 55828 54M 7200 S 0.0 2.7 0:00 java 31746 m2i9 0 55828 54M 7200 S 0.0 2.7 0:00 java 31747 m2i9 0 55828 54M 7200 S 0.0 2.7 0:01 java 31748 m2i9 0 55828 54M 7200 S 0.0 2.7 0:00 java 31749 m2i9 0 55828 54M 7200 S 0.0 2.7 0:00 java 31750 m2i9 0 55828 54M 7200 S 0.0 2.7 0:00 java 31751 m2i9 0 55828 54M 7200 S 0.0 2.7 0:01 java 31752 m2i9 0 55828 54M 7200 S 0.0 2.7 0:00 java 31753 m2i9 0 55828 54M 7200 S 0.0 2.7 0:00 java 31754 m2i9 0 55828 54M 7200 S 0.0 2.7 0:00 java 31755 m2i9 0 55828 54M 7200 S 0.0 2.7 0:00 java 31756 m2i9 0 55828 54M 7200 S 0.0 2.7 0:00 java 31757 m2i9 0 55828 54M 7200 S 0.0 2.7 0:04 java 31758 m2i9 0 55828 54M 7200 S 0.0 2.7 0:05 java 31759 m2i9 0 55828 54M 7200 S 0.0 2.7 0:01 java 31760 m2i9 0 55828 54M 7200 S 0.0 2.7 0:10 java 31761 m2i9 0 55828 54M 7200 S 0.0 2.7 0:10 java 31762 m2i9 0 55828 54M 7200 S 0.0 2.7 0:15 java 31763 m2i9 0 55828 54M 7200 S 0.0 2.7 0:08 java Out Put of ps -eo command:- [EMAIL PROTECTED] m2i]$ ps -eo pid,%mem,%cpu,cmd | grep jdk | more 31717 2.7 0.0 /home/m2i/jdk1.3.1/bin/i386/native_threads/java -Dtomcat.home=/h 31744 2.7 0.0 /home/m2i/jdk1.3.1/bin/i386/native_threads/java -Dtomcat.home=/h 31745 2.7 0.1 /home/m2i/jdk1.3.1/bin/i386/native_threads/java -Dtomcat.home=/h 31746 2.7 0.0 /home/m2i/jdk1.3.1/bin/i386/native_threads/java -Dtomcat.home=/h 31747 2.7 0.0 /home/m2i/jdk1.3.1/bin/i386/native_threads/java -Dtomcat.home=/h 31748 2.7 0.0 /home/m2i/jdk1.3.1/bin/i386/native_threads/java -Dtomcat.home=/h 31749 2.7 0.0 /home/m2i/jdk1.3.1/bin/i386/native_threads/java -Dtomcat.home=/h 31750 2.7 0.0 /home/m2i/jdk1.3.1/bin/i386/native_threads/java -Dtomcat.home=/h 31751 2.7 0.0 /home/m2i/jdk1.3.1/bin/i386/native_threads/java -Dtomcat.home=/h 31752 2.7 0.0 /home/m2i/jdk1.3.1/bin/i386/native_threads/java -Dtomcat.home=/h 31753 2.7 0.0 /home/m2i/jdk1.3.1/bin/i386/native_threads/java -Dtomcat.home=/h 31754 2.7 0.0 /home/m2i/jdk1.3.1/bin/i386/native_threads/java -Dtomcat.home=/h 31755 2.7 0.0 /home/m2i/jdk1.3.1/bin/i386/native_threads/java -Dtomcat.home=/h 31756 2.7 0.0 /home/m2i/jdk1.3.1/bin/i386/native_threads/java -Dtomcat.home=/h 31757 2.7 0.0 /home/m2i/jdk1.3.1/bin/i386/native_threads/java -Dtomcat.home=/h 31758 2.7 0.0 /home/m2i/jdk1.3.1/bin/i386/native_threads/java -Dtomcat.home=/h 31759 2.7 0.0 /home/m2i/jdk1.3.1/bin/i386/native_threads/java -Dtomcat.home=/h 31760 2.7 0.0 /home/m2i/jdk1.3.1/bin/i386/native_threads/java -Dtomcat.home=/h 31761 2.7 0.0 /home/m2i/jdk1.3.1/bin/i386/native_threads/java
