mod_jk change lb behavior for local_workers
Hi,
i had a problem setting up mod_jk to load-balance my local_workers
properly. Here is my environment:
2 Apaches 2.0.48 + mod_jk 1.2.5
4 Workers behind them.
all on linux rh8
the workers.properties for apache-A look like this:
worker.list=loadbal
worker.devprocA1.type=ajp13
worker.devprocA1.host=w1.my.net
worker.devprocA1.port=10011
worker.devprocA1.lbfactor=1
worker.devprocA1.local_worker=1
worker.devprocA2.type=ajp13
worker.devprocA2.host=w2.my.net
worker.devprocA2.port=10012
worker.devprocA2.lbfactor=1
worker.devprocA2.local_worker=1
worker.devprocB1.type=ajp13
worker.devprocB1.host=w3.my.net
worker.devprocB1.port=10021
worker.devprocB1.lbfactor=1
worker.devprocB1.local_worker=0
worker.devprocB2.type=ajp13
worker.devprocB2.host=w4.my.net
worker.devprocB2.port=10022
worker.devprocB2.lbfactor=1
worker.devprocB2.local_worker=0
worker.loadbal.type=lb
worker.loadbal.balanced_workers= devprocA1, devprocA2, devprocB1, devprocB2
worker.loadbal.local_worker_only=0
worker.loadbal.sticky_session=1
the workers.properties for apache-B looks the same, except for the
worker.devproc*.local_worker setting, which is inverted.
My goal was to balance devprocA1,devprocA2 by Apache-A and
devprocB1,devprocB2 by Apache-B + If Apache-A local workers fail it
should failover to the B-Workers and vice-versa for Apache-B
Everything worked fine except the balancing of the local_workers.
Apache-A balanced every request to devprocA1 and Apache-B balanced every
request to devprocB1. The balancing with a sticky session sill worked fine.
Maybe i misunderstood the meaning of local_worker but in my opinion it
should first try to balance the local_workers (equally) and if all
local_worker fail it should try to balance the other workers (equally).
I had a look at the mod_jk code and after applying the patch below it
worked as expected.
- cut here -
diff -ruN
jakarta-tomcat-connectors-jk-1.2.5-src/jk/native/common/jk_lb_worker.c
jakarta-tomcat-connectors-jk-1.2.5-src_patch/jk/native/common/jk_lb_worker.c
---
jakarta-tomcat-connectors-jk-1.2.5-src/jk/native/common/jk_lb_worker.c
2003-07-15 14:15:42.0 +0200
+++
jakarta-tomcat-connectors-jk-1.2.5-src_patch/jk/native/common/jk_lb_worker.c
2004-01-23 09:15:55.0 +0100
@@ -291,16 +291,17 @@
}
}
} else {
-if(p-lb_workers[i].lb_value lb_min || !rc) {
+if(!rc ||
+ (!rc-is_local_worker
p-lb_workers[i].is_local_worker) ||
+ ((rc-is_local_worker ==
p-lb_workers[i].is_local_worker) (p-lb_workers[i].lb_value
lb_min))) {
lb_min = p-lb_workers[i].lb_value;
rc = (p-lb_workers[i]);
-if (rc-is_local_worker) break;
}
}
}
}
-if(rc !rc-is_local_worker) {
+if(rc) {
rc-lb_value += rc-lb_factor;
}
- cut here -
any comments?
if the code and lb change is ok, please feel free to commit the patch to
the cvs.
thanks
Andre
--
Software-Entwicklung
Tipp24 AG
Kleine Johannisstrasse 2-4
20457 Hamburg | Germany
phone +49 (0)40 32 55 33-37
fax +49 (0)40 32 55 33-99
http://www.Tipp24.de
Tipp24.de - Einfach mal im Lotto gewinnen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Spec folks comments on bug 26341
This conflicts with when the sessionDestroyed notification is called, is it normal, or is it that the Javadocs were not properly updated ? Thanks, Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26372] New: - java.lang.ThreadDeath when trwaing to reload an application
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=26372. 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=26372 java.lang.ThreadDeath when trwaing to reload an application Summary: java.lang.ThreadDeath when trwaing to reload an application Product: Tomcat 5 Version: 5.0.16 Platform: PC OS/Version: Linux Status: NEW Severity: Major Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Many times I've got a java.lang.ThreadDeath exception when trying to reload a webapp using the ant task. The call stack of the last time is: 2004-01-23 12:25:37 StandardContext[/manager]Manager: init: Associated with Deployer 'localhost' 2004-01-23 12:25:37 StandardContext[/manager]Manager: init: Global resources are available 2004-01-23 12:25:37 StandardContext[/manager]Manager: restart: Reloading web application at '/jn' 2004-01-23 12:25:38 StandardContext[/manager]Manager: ManagerServlet.reload[/jn] java.lang.ThreadDeath at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1253) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1213) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315) at org.apache.log4j.HTMLLayout.format(HTMLLayout.java:129) at org.apache.log4j.net.SMTPAppender.sendBuffer(Unknown Source) at org.apache.log4j.net.SMTPAppender.append(Unknown Source) at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:221) at org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:57) at org.apache.log4j.Category.callAppenders(Category.java:187) at org.apache.log4j.Category.forcedLog(Category.java:372) at org.apache.log4j.Category.log(Category.java:864) at org.apache.commons.logging.impl.Log4JLogger.error(Log4JLogger.java:192) at org.apache.catalina.session.StandardManager.start(StandardManager.java:692) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4216) at org.apache.catalina.core.StandardContext.reload(StandardContext.java:2992) at org.apache.catalina.manager.ManagerServlet.reload(ManagerServlet.java:1019) at org.apache.catalina.manager.ManagerServlet.doGet(ManagerServlet.java:377) at javax.servlet.http.HttpServlet.service(HttpServlet.java:743) at javax.servlet.http.HttpServlet.service(HttpServlet.java:856) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:284) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:204) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:564) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:245) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:199) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:594) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:564) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:195) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:164) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:564) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:156) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:564) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:972) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:211) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:805) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:696)
DO NOT REPLY [Bug 26372] - java.lang.ThreadDeath when trwaing to reload an application
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=26372. 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=26372 java.lang.ThreadDeath when trwaing to reload an application [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2004-01-23 11:54 --- This is the old issue of log4j trying to use the previous classloader (reloading will create a new classloader to load class definitions; see bug 3888). Maybe it would be good to leave this bug open so that people can complain using it, rather than file duplicates. However, I'd like everyone to know that the bug will never be fixed. You can probably fix the problem by putting log4 JARs (and the necessary commons-logging wrapper classes) inside the webapp repository. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26373] New: - getServletContext().getRequestDispatcher() fails
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=26373. 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=26373 getServletContext().getRequestDispatcher() fails Summary: getServletContext().getRequestDispatcher() fails Product: Tomcat 5 Version: 5.0.16 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] In the init() method of a servlet, I've got the followin code: rd_ = getServletContext().getRequestDispatcher(/internal/router.do); with Tomcat 5.0.16, I become null!!! In Tomcat 4.1.29, this works correctly. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26373] - getServletContext().getRequestDispatcher() fails
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=26373. 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=26373 getServletContext().getRequestDispatcher() fails [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Blocker - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26373] - getServletContext().getRequestDispatcher() fails
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=26373. 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=26373 getServletContext().getRequestDispatcher() fails [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-01-23 12:00 --- I believe this works correctly (many test cases are based on this). Please submit a ready to use test case (packaged as a minimal .war) if you want to reopen this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
webdav over tomcat connector on windows problem
from an older post of you on http://archives.real-time.com/pipermail/tomcat-devel/2001-December/ 025155.html i have found a solution for the webdav over tomcat connector on windows problem ;) if you make a connection from an os x or linux box on a tomcat webdav w/ webapp connector for example on http://localhost/webdav/;, the webdav client sends a request for http://localhost/webdav/; so it works without a problem. If you make a connection from a windows webdav client on http://localhost/webdav/; it sends only a request for http://localhost/webdav; --- WITHOUT A SLASH!! but tomcat needs a slash at the end...! thats the problem! all you must do now is forward all requests for http://localhost/webdav; to http://localhost/webdav/; within your apache config file. greets livio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26375] New: - Determining whether a package is sealed fails with partially-sealed jars
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=26375.
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=26375
Determining whether a package is sealed fails with partially-sealed jars
Summary: Determining whether a package is sealed fails with
partially-sealed jars
Product: Tomcat 4
Version: 4.1.29
Platform: All
OS/Version: Linux
Status: NEW
Severity: Major
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
For jars where only some of the packages are sealed, the code to extract the
Attributes from the Manifest for that package is incorrect.
One result of this is that if the JAR as a whole is sealed but a particular
package in that JAR is not, the unsealed package throws a sealing violation.
The fault is in the
org.apache.cataline.loader.WebappClassLoader.isPackageSealed method. The
name attribute passed is in the format org.blah.blah, whereas the
attributes in the Manifest are stored against the key org/blah/blah/.
This is easy to fix. Replace the first few lines of the method with:
protected boolean isPackageSealed(String name, Manifest man)
{
* StringBuffer buf = new StringBuffer(name);
* for (int i=0;ibuf.length();i++) {
* if (buf.charAt(i)=='.') buf.setCharAt(i,'/');
* }
* buf.append('/');
* Attributes attr = man.getAttributes(buf.toString());
String sealed = null;
... and so on.
This is tested with 4.1.29 and works fine.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: configuring tomcat for encoding types.
guys ,got a filter which can do the request part. u can refer the link below. http://lists.jforge.org/pipermail/jlcp-dev/2004-January/000274.html Rgds, Deepak. -Original Message- From: Deepak Sharma [mailto:[EMAIL PROTECTED] Sent: Friday, January 23, 2004 11:54 AM To: [EMAIL PROTECTED] Subject: configuring tomcat for encoding types. Hi , is there neway i can avoid writing these two statements in all my jsp's. response.setContentType(text/html;charset=UTF-8); request.setCharacterEncoding(UTF-8); I want that somehow i can configure these two setting for the server so that i dont have to modify all my jsp's. i m using version 4.1 Regards, Deepak Sharma --- NOTICE This email and any files transmitted with it are confidential and are solely for the use of the individual or entity to which it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of NIIT shall be understood to be neither given nor endorsed by NIIT. Any information contained in this email, when addressed to NIIT Clients is subject to the terms and conditions in governing client contract. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- NOTICE This email and any files transmitted with it are confidential and are solely for the use of the individual or entity to which it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you receive this transmission in error, please notify the sender by reply email and then destroy the message. Opinions, conclusions and other information in this message that do not relate to official business of NIIT shall be understood to be neither given nor endorsed by NIIT. Any information contained in this email, when addressed to NIIT Clients is subject to the terms and conditions in governing client contract. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Good reason to make database.save() in MemoryUserDatabaseFactory.getObjectInstance ?
Hi, Looking for a simpler solution for bug 25822 (tomcat shouldn't write tomcat-users.xml at startup), I would like to know if there is a good raison to call database.save() just after a database.open() since not update could have take place. The only justification would be to raise an error when the associated file is read-only. Extrat from MemoryUserDatabaseFactory.getObjectInstance : // Return the configured database instance database.open(); database.save(); return (database); I tested removing database.save() : tomcat starts without problem, errors are only occuring when really trying to change thinngs from admin interface. Could this change be accepted to close bug 25822 ? Thanks. Xavier Poinsard. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Three proposals
Remy Maucherat wrote: Here are some new proposals. 2) Bug 26010. Doh, '_' is a useful character in URIs. Big mistake from me :-( I plan to use the '#' character instead, which is not useable in a URI. 3) New connector shutdown. There is a problem with the current Tomcat shutdown order. It works like this: - shutdown the connector - shutdown the webapps (which includes waiting for servlet exec to end, which doesn't make much sense since the connector and its sockets are all gone) This causes trouble in clustering scenarios, where requests which are currently being process will fail in a non predictible fashion. Shutting down in reverse order will not fix problems, as the connector will continue accepting requests (this would help a little, however). So I propose using the following shutdown routine: - notify the connector to stop accepting new requests (we can call this pausing the connector) - shutdown the webapps - shutdown the connector This will give requests which were being processed time to complete, and new requests will no longer be accepted. In addition, capability to pause / resume the connector will be added (new JMX operations), which will be useful for cluster node maintenance. For example, to cleanly take down a node: pause the connector, wait for the requests to complete (and session data to replicate), then do the needed maintenance, and finally either unpause the connector or restart the server. I will proceed with the implementation of 2 and 3. For 3, it is likely that I will add pause and resume methods on the Connector and ProtocolHandler. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATHCH] ./jk/native2/server/apache2/jk_service_apache2.c
Hi Bill,
Checking the CVS logs, It was fixed on 12/2/03, so 4.1.30 will be the
first
4.1.x version with the fix. Prior to then, yes it did use the value from
Apache for getServerPort.
- Original Message -
From: Kyle VanderBeek [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Thursday, January 22, 2004 1:22 PM
Subject: Re: [PATHCH] ./jk/native2/server/apache2/jk_service_apache2.c
On Thu, Jan 22, 2004 at 01:16:45PM -0800, Bill Barker wrote:
However, it is the correct value to pass to Tomcat. Tomcat correctly
uses
this value for getLocalPort. The value of getServerPort (which is the
one
used for redirection) is taken from the Host header (as required by the
2.4
servlet spec).
so does this mean that the problem was in Tomcat and not in mod_jk2;
and that the bugzilla
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16901
should be closed with 'wrong approach - fixed in Tomcat' ??
if so then remains the question if the patch below is the correct replacement for
apr_sockaddr_port_get():
# patch for APR 1.0 compatiblity
#
--- jk_service_apache2.c.orig Tue Sep 30 18:16:14 2003
+++ jk_service_apache2.cWed Jan 21 17:43:14 2004
@@ -343,7 +343,6 @@
static int JK_METHOD jk2_init_ws_service(jk_env_t *env, jk_ws_service_t *s,
jk_worker_t *worker, void *serverObj)
{
-apr_port_t port;
char *ssl_temp = NULL;
jk_workerEnv_t *workerEnv;
request_rec *r=serverObj;
@@ -377,8 +376,7 @@
r-server-server_hostname);
/* get the real port (otherwise redirect failed) */
-apr_sockaddr_port_get(port,r-connection-local_addr);
-s-server_port = port;
+s-server_port = r-connection-local_addr-port;
s-server_software = (char *)ap_get_server_version();
votes?
Guenter.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26022] - background compile thread compiles pages with errors on every run
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=26022. 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=26022 background compile thread compiles pages with errors on every run [EMAIL PROTECTED] changed: What|Removed |Added Component|Jasper 2|Jasper Product|Tomcat 4|Tomcat 5 Version|4.1.29 |5.0.18 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26022] - background compile thread compiles pages with errors on every run
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=26022. 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=26022 background compile thread compiles pages with errors on every run --- Additional Comments From [EMAIL PROTECTED] 2004-01-23 16:04 --- Way too much complexity IMO. Precompilation (now that it really does work) is clearly the way to go in production. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26022] - background compile thread compiles pages with errors on every run
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=26022. 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=26022 background compile thread compiles pages with errors on every run --- Additional Comments From [EMAIL PROTECTED] 2004-01-23 16:08 --- Depending on the ClasLoader you don't need to compile such a dummy-class for each JSP-page that fails. It can be done by copying a class-file that already exists. you want me to precompile the JSP-pages? Did you ever thought of the case, that people might use Dreamweaver or whatever to edit the JSP-pages? You cannot teach those people how to use ant and Tomcat to precompile JSP-pages. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25596] - Application briefly unavailable when using manager to reload
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=25596. 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=25596 Application briefly unavailable when using manager to reload --- Additional Comments From [EMAIL PROTECTED] 2004-01-23 17:29 --- For anyone following this bug, but not following the dev list, it looks like Remy may attempt to fix this issue by implementing pause/resume commands in the Connector/ProtocolHandler. http://marc.theaimsgroup.com/?l=tomcat-devm=107487246528039w=2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25596] - Application briefly unavailable when using manager to reload
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=25596. 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=25596 Application briefly unavailable when using manager to reload --- Additional Comments From [EMAIL PROTECTED] 2004-01-23 17:36 --- No, this is not related (this is global to the Tomcat instance). The change is meant to enable doing updates on a cluster node in a clean way. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25596] - Application briefly unavailable when using manager to reload
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=25596. 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=25596 Application briefly unavailable when using manager to reload --- Additional Comments From [EMAIL PROTECTED] 2004-01-23 17:41 --- Thanks for the input, Remy. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26022] - background compile thread compiles pages with errors on every run
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=26022. 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=26022 background compile thread compiles pages with errors on every run [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2004-01-23 18:17 --- You are right in that this is a RFE instead of bug. Whether jasper skips recompiling erroneous JSP pages or not is just an optimization, and it is the page author's responsibility to deploy JSP pages that are error free. Imagine anyone accessing the page and getting a compilation error. Don't you think that's stupid also? This won't be fixed because it adds complixity without any real benefit. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26341] - It's possible to call getAttribute() while session is invalidated without IAE
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=26341.
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=26341
It's possible to call getAttribute() while session is invalidated without IAE
--- Additional Comments From [EMAIL PROTECTED] 2004-01-23 18:56 ---
How about setting expiring to FALSE *before* removing any attributes,
and adding a backdoor into removeAttribute() that by-passes the validity
check, as follows:
Index: StandardSession.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StandardSession.java,v
retrieving revision 1.29
diff -u -r1.29 StandardSession.java
--- StandardSession.java19 Jan 2004 23:39:05 - 1.29
+++ StandardSession.java22 Jan 2004 22:44:30 -
@@ -706,19 +706,24 @@
if (manager != null)
manager.remove(this);
+/*
+ * Mark session as expired *before* removing its attributes, so
+ * that its HttpSessionBindingListener objects will get an
+ * IllegalStateException when accessing the session attributes
+ * from within their valueUnbound() method
+ */
+expiring = false;
+
// Unbind any objects associated with this session
String keys[] = keys();
for (int i = 0; i keys.length; i++)
-removeAttribute(keys[i], notify);
+removeAttribute(keys[i], notify, false);
// Notify interested session event listeners
if (notify) {
fireSessionEvent(Session.SESSION_DESTROYED_EVENT, null);
}
-// We have completed expire of this session
-expiring = false;
-
}
}
@@ -1133,7 +1138,7 @@
*/
public void removeAttribute(String name) {
-removeAttribute(name, true);
+removeAttribute(name, true, true);
}
@@ -1150,14 +1155,17 @@
* @param name Name of the object to remove from this session.
* @param notify Should we notify interested listeners that this
* attribute is being removed?
+ * @param checkValid Indicates whether IllegalStateException must be
+ * thrown if session has already been invalidated
*
* @exception IllegalStateException if this method is called on an
* invalidated session
*/
-public void removeAttribute(String name, boolean notify) {
+public void removeAttribute(String name, boolean notify,
+boolean checkValid) {
// Validate our current state
-if (!isValid())
+if (checkValid !isValid())
throw new IllegalStateException
(sm.getString(standardSession.removeAttribute.ise));
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13446] - Invalide error page with request attribute.
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=13446. 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=13446 Invalide error page with request attribute. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2004-01-23 19:22 --- This now works for me with the latest version of TC4 from CVS. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JSSE 1.4: 'Want' vs. 'Need' Client Certificate Authentication
Bill,
I'm not sure what the best way to submit these are, but here is a first
stab at an implementation of this. I was able to successfully test and
run this under Tomcat 4.1.29 using the Jakarta-tomcat-connectors source
package distributed with 5.0.18 (should be the latest from my
understanding).
Attached are the patch files for:
org.apache.coyote.tomcat4.CoyoteServerSocketFactory
org.apache.coyote.tomcat4.CoyoteConnector
org.apache.tomcat.util.net.jsse.JSSESocketFactory
org.apache.tomcat.util.net.jsse.JSSE13SocketFactory
org.apache.tomcat.util.net.jsse.JSSE14SocketFactory
Let me know if I'm on the right track... (I haven't done a diff in
years, I'm not sure if I did it backwards or not, but I did 'diff
new_file original_version').
Thanks,
Mike
-Original Message-
From: Bill Barker [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 22, 2004 2:53 PM
To: Tomcat Developers List
Subject: Re: JSSE 1.4: 'Want' vs. 'Need' Client Certificate
Authentication
This has been on my list for awhile (just not very high :). I am
leaning in
the direction of 1): change the clientAuth parameter to be a String of
the
form: 'true', 'false', or 'want'. It's the simplest, and cleanest.
Getting the PureTLS implementation caught up with the JSSE
implementation is
another item on my list :).
- Original Message -
From: Becker, Michael [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, January 22, 2004 10:38 AM
Subject: JSSE 1.4: 'Want' vs. 'Need' Client Certificate Authentication
One of the additional features that has been introduced in JSSE 1.4 is
the ability to 'want' client certificates instead of 'require'ing them
(http://java.sun.com/j2se/1.4.2/docs/guide/security/jsse/JSSERefGuide.ht
ml#NewMethods). It also appears that this functionality is not
available in the PureTLS implementation of the SSL protocol (at least
that I could find). This feature could be useful in scenarios where
some users have client side certificates and some do not. This would
still allow both sets of users to connect to the same host, but using
different modes of authentication. Another nice thing that this feature
would give us is the ability to provide a friendly You don't have a
client certificate and contact this help desk to get your client
certificate instead of not allowing any requests to get into the
container.
Considering the fact that this is only applicable to a JDK 1.4.x VM, is
this something that could be built into the current distribution? Here
are some options that I came up with to get this functionality in
Tomcat.
1. Provide an additional argument to the
org.apache.coyote.tomcat4.CoyoteServerSocketFactory in server.xml to
'want' certificate authentication. If the underlying SSL implementation
does not support that feature, log an error/warning and revert to 'need'
certificate authentication.
2. For the org.apache.tomcat.util.net.jsse.JSSE14* classes, change the
functionality to 'want' certificates instead of 'need' them. This gives
the application and container the ability to give the user an error if
they do not have a certificate instead of closing the socket and making
the browser show the 'Page can not be displayed' error. This would
change existing behavior and thus could be a really bad thing to do.
3. Make my own modifications and don't incorporate into the default
distribution.
Regards,
Mike Becker
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
108a109
protected boolean clientAuth = false;
151c152
configureClientAuth(asock);
---
asock.setNeedClientAuth(clientAuth);
365,380d365
* Configure Client authentication for this version of JSSE. The
* JSSE included in Java 1.4 supports the 'want' value. Prior
* versions of JSSE will treat 'want' as 'false'.
* @param socket the SSLServerSocket
*/
abstract protected void configureClientAuth(SSLServerSocket socket);
/**
* Configure Client authentication for this version of JSSE. The
* JSSE included in Java 1.4 supports the 'want' value. Prior
* versions of JSSE will treat 'want' as 'false'.
* @param ssocket the SSLSocket
*/
abstract protected void configureClientAuth(SSLSocket socket);
/**
398c383
configureClientAuth(socket);
---
socket.setNeedClientAuth(clientAuth);
1203,1204c1203,1206
IntrospectionUtils.setProperty(protocolHandler, clientauth,
+ ssf.getClientAuth());
---
if (ssf.getClientAuth()) {
IntrospectionUtils.setProperty(protocolHandler, clientauth,
+ ssf.getClientAuth());
}
76,79c76
* set to codetrue/code. Want client authentication if set to
* codewant/code. (Note: Only supported in the JSSE included with
*
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4 CoyoteConnector.java
markt 2004/01/23 12:47:13
Modified:coyote/src/java/org/apache/coyote/tomcat4
CoyoteConnector.java
Log:
- Fixing what looks like a cut and paste error to resolve a compilation error.
Revision ChangesPath
1.32 +5 -5
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteConnector.java
Index: CoyoteConnector.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteConnector.java,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -r1.31 -r1.32
--- CoyoteConnector.java 22 Jan 2004 03:03:35 - 1.31
+++ CoyoteConnector.java 23 Jan 2004 20:47:13 - 1.32
@@ -782,7 +782,7 @@
*
* @param maxSpareProcessors The new maximum of spare processors
*/
-public void setMaxProcessors(int maxSpareProcessors) {
+public void setMaxSpareProcessors(int maxSpareProcessors) {
this.maxSpareProcessors = maxSpareProcessors;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26341] - It's possible to call getAttribute() while session is invalidated without IAE
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=26341. 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=26341 It's possible to call getAttribute() while session is invalidated without IAE --- Additional Comments From [EMAIL PROTECTED] 2004-01-23 20:59 --- Yes, I know how to fix this. Howerver, this is weird when compared to how sessionDestroyed is handled, so I was wondering if it was valid. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26022] - background compile thread compiles pages with errors on every run
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=26022. 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=26022 background compile thread compiles pages with errors on every run --- Additional Comments From [EMAIL PROTECTED] 2004-01-23 20:59 --- again i have to disagree: In the case where i noticed it, it was the case that it was an unused JSP-page that contained an error. You may say that one should only upload correct JSP-pages, but it a really arrogant position. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26341] - It's possible to call getAttribute() while session is invalidated without IAE
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=26341. 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=26341 It's possible to call getAttribute() while session is invalidated without IAE --- Additional Comments From [EMAIL PROTECTED] 2004-01-23 21:05 --- Just a comment: I have a hard need to be able to getAttribute() from within an HttpSessionListener's sessionDestroyed() method. I believe I should be able to access any/all attributes for the duration of this call, i.e. that attribute removal and/or invalid-state settings should be after sessionDestroyed() calls. [The reason I need the attributes is that HttpSessionListener knows/receives *nothing* apart from the HttpSession. Oddly enough my listener needs to know *something* else.] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26341] - It's possible to call getAttribute() while session is invalidated without IAE
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=26341. 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=26341 It's possible to call getAttribute() while session is invalidated without IAE --- Additional Comments From [EMAIL PROTECTED] 2004-01-23 21:06 --- To finish my last vague comment: I put the something else my listener needs to know into the session via a filter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Add ability for Realm authentication to tell the user the reason for auth failure
Hi all, First of all: My name is Carlos and I'm new here. (I have entered the list a few days ago) And I'm still trying to understand the tomcat source code... oh... and I'm not from USA...my english is not perfect, but I hope I can be usefull anyway ;) I was looking for something to work on, and I found this in BugZilla: http:// issues.apache.org/bugzilla/show_bug.cgi?id=25953 I know this is a minor enhancement but I think It's a good place for me to start. Before start coding (or even thinking about it) I would like to know if anyone already did it! Thinking about the issue, I couldn't figure out how to do it without changing the signature of the authenticate() method (which is the worst choice, I think) or creating a new method that can throw some kind of exception to be catched by the user application (maybe deprecating the authenticate() ??). Do you have any ideas? Thanks in advance for your help . -- Carlos H. ([EMAIL PROTECTED]) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session StandardSession.java
remm2004/01/23 14:29:32
Modified:catalina/src/share/org/apache/catalina/session
StandardSession.java
Log:
- Bug 26341: When calling the removeAttributes during session expiration,
notified attributes should see the session as invalid.
Revision ChangesPath
1.32 +76 -56
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StandardSession.java
Index: StandardSession.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StandardSession.java,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -r1.31 -r1.32
--- StandardSession.java 22 Jan 2004 18:21:21 - 1.31
+++ StandardSession.java 23 Jan 2004 22:29:32 - 1.32
@@ -732,11 +732,6 @@
if (manager != null)
manager.remove(this);
-// Unbind any objects associated with this session
-String keys[] = keys();
-for (int i = 0; i keys.length; i++)
-removeAttribute(keys[i], notify);
-
// Notify interested session event listeners
if (notify) {
fireSessionEvent(Session.SESSION_DESTROYED_EVENT, null);
@@ -745,6 +740,11 @@
// We have completed expire of this session
expiring = false;
+// Unbind any objects associated with this session
+String keys[] = keys();
+for (int i = 0; i keys.length; i++)
+removeAttributeInternal(keys[i], notify);
+
}
}
@@ -1182,53 +1182,7 @@
throw new IllegalStateException
(sm.getString(standardSession.removeAttribute.ise));
-// Remove this attribute from our collection
-Object value = attributes.remove(name);
-
-// Do we need to do valueUnbound() and attributeRemoved() notification?
-if (!notify || (value == null)) {
-return;
-}
-
-// Call the valueUnbound() method if necessary
-HttpSessionBindingEvent event = null;
-if (value instanceof HttpSessionBindingListener) {
-event = new HttpSessionBindingEvent(this, name, value);
-((HttpSessionBindingListener) value).valueUnbound(event);
-}
-
-// Notify interested application event listeners
-Context context = (Context) manager.getContainer();
-Object listeners[] = context.getApplicationEventListeners();
-if (listeners == null)
-return;
-for (int i = 0; i listeners.length; i++) {
-if (!(listeners[i] instanceof HttpSessionAttributeListener))
-continue;
-HttpSessionAttributeListener listener =
-(HttpSessionAttributeListener) listeners[i];
-try {
-fireContainerEvent(context,
- beforeSessionAttributeRemoved,
- listener);
-if (event == null) {
-event = new HttpSessionBindingEvent(this, name, value);
-}
-listener.attributeRemoved(event);
-fireContainerEvent(context,
- afterSessionAttributeRemoved,
- listener);
-} catch (Throwable t) {
-try {
-fireContainerEvent(context,
- afterSessionAttributeRemoved,
- listener);
-} catch (Exception e) {
-;
-}
-log(sm.getString(standardSession.attributeEvent), t);
-}
-}
+removeAttributeInternal(name, notify);
}
@@ -1589,6 +1543,72 @@
protected Object getAttributeInternal(String name) {
return (attributes.get(name));
+
+}
+
+
+/**
+ * Remove the object bound with the specified name from this session. If
+ * the session does not have an object bound with this name, this method
+ * does nothing.
+ * p
+ * After this method executes, and if the object implements
+ * codeHttpSessionBindingListener/code, the container calls
+ * codevalueUnbound()/code on the object.
+ *
+ * @param name Name of the object to remove from this session.
+ * @param notify Should we notify interested listeners that this
+ * attribute is being removed?
+ */
+protected void removeAttributeInternal(String name, boolean notify) {
+
+// Remove this attribute from our collection
+Object value = attributes.remove(name);
+
+// Do
DO NOT REPLY [Bug 26341] - It's possible to call getAttribute() while session is invalidated without IAE
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=26341. 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=26341 It's possible to call getAttribute() while session is invalidated without IAE [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-01-23 22:29 --- Yes, inside sessionDestroyed, you should still have all access to the session. This is new in Servlet 2.4, AFAIK. This should stay in, and I think this is a problem with Jan's patch. I simply intend to move the remove attribute call after the expiring = false (and add a protected removeAttributeInternal method, of course). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/manager/WEB-INF/classes/org/apache/catalina/manager ManagerServlet.java
remm2004/01/23 14:39:01
Modified:webapps/manager/WEB-INF/classes/org/apache/catalina/manager
ManagerServlet.java
Log:
- Bug 26010: '_' was an inappropriate character to replace the path separator,
since it's a common character in HTTP. Experiment with using '#' instead,
which is client side only.
Revision ChangesPath
1.15 +5 -5
jakarta-tomcat-catalina/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/ManagerServlet.java
Index: ManagerServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/ManagerServlet.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- ManagerServlet.java 8 Jan 2004 11:09:03 - 1.14
+++ ManagerServlet.java 23 Jan 2004 22:39:01 - 1.15
@@ -1486,7 +1486,7 @@
if (path.equals()) {
basename = ROOT;
} else {
-basename = path.substring(1).replace('/', '_');
+basename = path.substring(1).replace('/', '#');
}
return (basename);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26010] - context path in server.xml doesn't like _ (underscore) character.
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=26010. 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=26010 context path in server.xml doesn't like _ (underscore) character. [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|LATER | --- Additional Comments From [EMAIL PROTECTED] 2004-01-23 22:39 --- . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26010] - context path in server.xml doesn't like _ (underscore) character.
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=26010. 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=26010 context path in server.xml doesn't like _ (underscore) character. --- Additional Comments From [EMAIL PROTECTED] 2004-01-23 22:42 --- I have experimented with using '#' as a replacement character. If this doesn't work well, I will revert the changes and set the bug back to LATER. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26010] - context path in server.xml doesn't like _ (underscore) character.
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=26010. 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=26010 context path in server.xml doesn't like _ (underscore) character. [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-01-23 22:49 --- My fix seems to be working. '#' should never end up being the first character, so it should work in all cases. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Add ability for Realm authentication to tell the user the reason for auth failure
[Carlos H.] wrote: Hi all, First of all: My name is Carlos and I'm new here. (I have entered the list a few days ago) And I'm still trying to understand the tomcat source code... oh... and I'm not from USA...my english is not perfect, but I hope I can be usefull anyway ;) I was looking for something to work on, and I found this in BugZilla: http:// issues.apache.org/bugzilla/show_bug.cgi?id=25953 I know this is a minor enhancement but I think It's a good place for me to start. Before start coding (or even thinking about it) I would like to know if anyone already did it! Thinking about the issue, I couldn't figure out how to do it without changing the signature of the authenticate() method (which is the worst choice, I think) or creating a new method that can throw some kind of exception to be catched by the user application (maybe deprecating the authenticate() ??). Do you have any ideas? Not really ;) This may not be the best bug to start with, although it does sound simple. The problems are: - likely there will be an API change needed - not all realms may support every error messages, and all will need different impls - if most realms don't support it, then the feature is useless, so isn't worth the pain of the API change mentioned above So to sumarize, I think you should pick another bug :) So ideas: - lurk in the TC 4 bugs like Mark is doing to see if anything still applies to TC 5 - work on the admin webapp (some patches pending - testing needed ! - and a few bugs open) - 26236 about the JAAS realm: it would be a very useful fix, and shouldn't be too complex Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup HostConfig.java
remm2004/01/23 15:04:09
Modified:catalina/src/share/org/apache/catalina/core
StandardContext.java
catalina/src/share/org/apache/catalina/startup
HostConfig.java
Log:
- Bug 26010: '_' was an inappropriate character to replace the path separator,
since it's a common character in HTTP. Experiment with using '#' instead,
which is client side only.
Revision ChangesPath
1.110 +2 -2
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java
Index: StandardContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
retrieving revision 1.109
retrieving revision 1.110
diff -u -r1.109 -r1.110
--- StandardContext.java 20 Jan 2004 23:07:36 - 1.109
+++ StandardContext.java 23 Jan 2004 23:04:09 - 1.110
@@ -4797,7 +4797,7 @@
if (path.equals()) {
basename = ROOT;
} else {
-basename = path.substring(1).replace('/', '_');
+basename = path.substring(1).replace('/', '#');
}
return (basename + .xml);
}
1.28 +5 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/HostConfig.java
Index: HostConfig.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/HostConfig.java,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- HostConfig.java 13 Jan 2004 16:57:16 - 1.27
+++ HostConfig.java 23 Jan 2004 23:04:09 - 1.28
@@ -502,7 +502,7 @@
// Calculate the context path and make sure it is unique
String file = files[i].substring(0, files[i].length() - 4);
-String contextPath = / + file.replace('_', '/');
+String contextPath = / + file.replace('#', '/');
if (file.equals(ROOT)) {
contextPath = ;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs/config http.xml
remm2004/01/23 15:32:34 Modified:webapps/docs/config http.xml Log: - Document new field. Revision ChangesPath 1.7 +6 -0 jakarta-tomcat-catalina/webapps/docs/config/http.xml Index: http.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/config/http.xml,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- http.xml 13 Jan 2004 18:34:20 - 1.6 +++ http.xml 23 Jan 2004 23:32:34 - 1.7 @@ -194,6 +194,12 @@ this attribute is set to false./p /attribute +attribute name=maxHttpHeaderSize required=false + pThe maximum size of the request and response HTTP header, specified + in bytes. + If not specified, this attribute is set to 4096 (4 KB)./p +/attribute + attribute name=maxKeepAliveRequests required=false pThe maximum number of HTTP requests which can be pipelined until the connection is closed by the server. Setting this attribute to 1 will - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse JSSE13SocketFactory.java JSSE14SocketFactory.java JSSESocketFactory.java
billbarker2004/01/23 20:56:32
Modified:util/java/org/apache/tomcat/util/net/jsse
JSSE13SocketFactory.java JSSE14SocketFactory.java
JSSESocketFactory.java
Log:
Allow the option to only want client authentication.
Submitted By: Michael Becker [EMAIL PROTECTED] (with some cosmetic changes).
Revision ChangesPath
1.7 +21 -2
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse/JSSE13SocketFactory.java
Index: JSSE13SocketFactory.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse/JSSE13SocketFactory.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- JSSE13SocketFactory.java 11 Oct 2003 04:24:30 - 1.6
+++ JSSE13SocketFactory.java 24 Jan 2004 04:56:32 - 1.7
@@ -64,6 +64,7 @@
import java.security.Security;
import javax.net.ssl.SSLServerSocket;
+import javax.net.ssl.SSLSocket;
/*
1. Make the JSSE's jars available, either as an installed
@@ -85,6 +86,11 @@
*/
public class JSSE13SocketFactory extends JSSESocketFactory
{
+/**
+ * Flag for client authentication
+ */
+protected boolean clientAuth = false;
+
public JSSE13SocketFactory () {
super();
}
@@ -106,8 +112,10 @@
Security.addProvider (new com.sun.net.ssl.internal.ssl.Provider());
String clientAuthStr = (String)attributes.get(clientauth);
-if (clientAuthStr != null){
-clientAuth = Boolean.valueOf(clientAuthStr).booleanValue();
+if(true.equalsIgnoreCase(clientAuthStr) ||
+ yes.equalsIgnoreCase(clientAuthStr) ||
+ want.equalsIgnoreCase(clientAuthStr)) {
+clientAuth = true;
}
// SSL protocol variant (e.g., TLS, SSL v3, etc.)
@@ -171,6 +179,17 @@
}
protected void setEnabledProtocols(SSLServerSocket socket,
String [] protocols){
+}
+
+protected void configureClientAuth(SSLServerSocket socket){
+socket.setNeedClientAuth(clientAuth);
+}
+
+protected void configureClientAuth(SSLSocket socket){
+// In JSSE 1.0.2 docs it does not explicitly
+// state whether SSLSockets returned from
+// SSLServerSocket.accept() inherit this setting.
+socket.setNeedClientAuth(clientAuth);
}
}
1.21 +30 -2
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse/JSSE14SocketFactory.java
Index: JSSE14SocketFactory.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse/JSSE14SocketFactory.java,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- JSSE14SocketFactory.java 19 Nov 2003 18:02:53 - 1.20
+++ JSSE14SocketFactory.java 24 Jan 2004 04:56:32 - 1.21
@@ -68,6 +68,7 @@
import javax.net.ssl.KeyManagerFactory;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLServerSocket;
+import javax.net.ssl.SSLSocket;
import javax.net.ssl.TrustManager;
import javax.net.ssl.TrustManagerFactory;
import javax.net.ssl.X509KeyManager;
@@ -97,6 +98,16 @@
private static StringManager sm =
StringManager.getManager(org.apache.tomcat.util.net.jsse.res);
+/**
+ * Flag to state that we require client authentication.
+ */
+protected boolean requireClientAuth = false;
+
+/**
+ * Flag to state that we would like client authentication.
+ */
+protected boolean wantClientAuth= false;
+
public JSSE14SocketFactory () {
super();
}
@@ -108,8 +119,11 @@
try {
String clientAuthStr = (String) attributes.get(clientauth);
-if (clientAuthStr != null){
-clientAuth = Boolean.valueOf(clientAuthStr).booleanValue();
+if(true.equalsIgnoreCase(clientAuthStr) ||
+ yes.equalsIgnoreCase(clientAuthStr)) {
+requireClientAuth = true;
+} else if(want.equalsIgnoreCase(clientAuthStr)) {
+wantClientAuth = true;
}
// SSL protocol variant (e.g., TLS, SSL v3, etc.)
@@ -281,4 +295,18 @@
return enabledProtocols;
}
+
+protected void configureClientAuth(SSLServerSocket socket){
+if (wantClientAuth){
+socket.setWantClientAuth(wantClientAuth);
+} else {
+socket.setNeedClientAuth(requireClientAuth);
+}
+}
+
+protected void configureClientAuth(SSLSocket
DO NOT REPLY [Bug 26393] New: - req.getParamameter don't respect req.setCharacterEncoding
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=26393. 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=26393 req.getParamameter don't respect req.setCharacterEncoding Summary: req.getParamameter don't respect req.setCharacterEncoding Product: Tomcat 5 Version: 5.0.18 Platform: PC OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When I called req.setCharacterEncoding(EUC_KR), getParameter returned a right value in POST but wrong in GET. Req.getParameter ignores req.setCharacterEncoding and uses ISO8859_1 in GET method. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/connector EditConnectorAction.java SaveConnectorAction.java
billbarker2004/01/23 21:59:47 Modified:webapps/admin/WEB-INF/classes/org/apache/webapp/admin/connector EditConnectorAction.java SaveConnectorAction.java Log: Updating the admin webapp for the change in type of clientAuth. I could use some help in where to look to get the admin webapp to actually support the choices true/false/want. Revision ChangesPath 1.5 +5 -5 jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/connector/EditConnectorAction.java Index: EditConnectorAction.java === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/connector/EditConnectorAction.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- EditConnectorAction.java 22 Jan 2004 02:05:05 - 1.4 +++ EditConnectorAction.java 24 Jan 2004 05:59:47 - 1.5 @@ -291,7 +291,7 @@ ((String) mBServer.getAttribute(cname, attribute)); attribute = clientAuth; connectorFm.setClientAuthentication -(((Boolean) mBServer.getAttribute(cname, attribute)).toString()); +(((String) mBServer.getAttribute(cname, attribute))); attribute = ciphers; connectorFm.setCiphers ((String) mBServer.getAttribute(cname, attribute)); 1.12 +6 -6 jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/connector/SaveConnectorAction.java Index: SaveConnectorAction.java === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/connector/SaveConnectorAction.java,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- SaveConnectorAction.java 22 Jan 2004 02:05:05 - 1.11 +++ SaveConnectorAction.java 24 Jan 2004 05:59:47 - 1.12 @@ -471,8 +471,8 @@ attribute = clientAuth; mBServer.setAttribute(coname, - new Attribute(clientAuth, new Boolean( - cform.getClientAuthentication(; + new Attribute(clientAuth, + cform.getClientAuthentication())); attribute = ciphers; String ciphers = cform.getCiphers(); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSSE 1.4: 'Want' vs. 'Need' Client Certificate Authentication
I've updated TC 5 to support want. Until I figure out how to get the 'admin' webapp to work with the changes, I'm holding off committing the Connector changes for TC 4.1.x (since we are just before a release, and I'd like the release to go GA :). However, the patch is sitting on my hard-drive already to be committed. Becker, Michael [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Bill, I'm not sure what the best way to submit these are, but here is a first stab at an implementation of this. I was able to successfully test and run this under Tomcat 4.1.29 using the Jakarta-tomcat-connectors source package distributed with 5.0.18 (should be the latest from my understanding). Attached are the patch files for: org.apache.coyote.tomcat4.CoyoteServerSocketFactory org.apache.coyote.tomcat4.CoyoteConnector org.apache.tomcat.util.net.jsse.JSSESocketFactory org.apache.tomcat.util.net.jsse.JSSE13SocketFactory org.apache.tomcat.util.net.jsse.JSSE14SocketFactory Let me know if I'm on the right track... (I haven't done a diff in years, I'm not sure if I did it backwards or not, but I did 'diff new_file original_version'). Thanks, Mike -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED] Sent: Thursday, January 22, 2004 2:53 PM To: Tomcat Developers List Subject: Re: JSSE 1.4: 'Want' vs. 'Need' Client Certificate Authentication This has been on my list for awhile (just not very high :). I am leaning in the direction of 1): change the clientAuth parameter to be a String of the form: 'true', 'false', or 'want'. It's the simplest, and cleanest. Getting the PureTLS implementation caught up with the JSSE implementation is another item on my list :). - Original Message - From: Becker, Michael [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 22, 2004 10:38 AM Subject: JSSE 1.4: 'Want' vs. 'Need' Client Certificate Authentication One of the additional features that has been introduced in JSSE 1.4 is the ability to 'want' client certificates instead of 'require'ing them (http://java.sun.com/j2se/1.4.2/docs/guide/security/jsse/JSSERefGuide.ht ml#NewMethods). It also appears that this functionality is not available in the PureTLS implementation of the SSL protocol (at least that I could find). This feature could be useful in scenarios where some users have client side certificates and some do not. This would still allow both sets of users to connect to the same host, but using different modes of authentication. Another nice thing that this feature would give us is the ability to provide a friendly You don't have a client certificate and contact this help desk to get your client certificate instead of not allowing any requests to get into the container. Considering the fact that this is only applicable to a JDK 1.4.x VM, is this something that could be built into the current distribution? Here are some options that I came up with to get this functionality in Tomcat. 1. Provide an additional argument to the org.apache.coyote.tomcat4.CoyoteServerSocketFactory in server.xml to 'want' certificate authentication. If the underlying SSL implementation does not support that feature, log an error/warning and revert to 'need' certificate authentication. 2. For the org.apache.tomcat.util.net.jsse.JSSE14* classes, change the functionality to 'want' certificates instead of 'need' them. This gives the application and container the ability to give the user an error if they do not have a certificate instead of closing the socket and making the browser show the 'Page can not be displayed' error. This would change existing behavior and thus could be a really bad thing to do. 3. Make my own modifications and don't incorporate into the default distribution. Regards, Mike Becker - 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]
