How to set the user created tld in web.xml??
Hi All, I am facing a problem in setting the user created tld file in web.xml If I don't specify anything in web.xml I am getting below error Exception Handler Description: An unhandled exception occurred during the execution of the web application. Please review the following stack trace for more information regarding the error. Exception Details: org.apache.jasper.JasperException This absolute uri (http://www.jiyaJobs.com/) cannot be resolved in either web.xml or the jar files deployed with this application Possible Source of Error: Class Name: org.apache.jasper.compiler.DefaultErrorHandler File Name: DefaultErrorHandler.java Method Name: jspError Line Number: 105 Source not available. Information regarding the location of the exception can be identified using the exception stack trace below. Stack Trace: org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:105) org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:430) org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:154) org.apache.jasper.compiler.TagLibraryInfoImpl.(TagLibraryInfoImpl.java:159) org.apache.jasper.compiler.JspDocumentParser.addCustomTagLibraries(JspDocumentParser.java:459) org.apache.jasper.compiler.JspDocumentParser.startElement(JspDocumentParser.java:189) org.apache.xerces.parsers.AbstractSAXParser.startElement( Unknown Source ) org.apache.xerces.impl.dtd.XMLDTDValidator.startElement( Unknown Source ) org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement( Unknown Source ) org.apache.xerces.impl.XMLDocumentScannerImpl$ContentDispatcher.scanRootElementHook( Unknown Source ) org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch( Unknown Source ) org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument( Unknown Source ) org.apache.xerces.parsers.XML11Configuration.parse( Unknown Source ) org.apache.xerces.parsers.XML11Configuration.parse( Unknown Source ) org.apache.xerces.parsers.XMLParser.parse( Unknown Source ) org.apache.xerces.parsers.AbstractSAXParser.parse( Unknown Source ) javax.xml.parsers.SAXParser.parse(SAXParser.java:345) org.apache.jasper.compiler.JspDocumentParser.parse(JspDocumentParser.java:156) org.apache.jasper.compiler.ParserController.parse(ParserController.java:193) org.apache.jasper.compiler.ParserController.parse(ParserController.java:153) org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:227) org.apache.jasper.compiler.Compiler.compile(Compiler.java:369) org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:473) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:190) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241) javax.servlet.http.HttpServlet.service(HttpServlet.java:853) org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:684) org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:432) org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:356) com.sun.faces.context.ExternalContextImpl.dispatch(ExternalContextImpl.java:322) com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:130) com.sun.jsfcl.app.ViewHandlerImpl.renderView(ViewHandlerImpl.java:181) com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:87) com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:221) com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:117) javax.faces.webapp.FacesServlet.service(FacesServlet.java:198) org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256) org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2422) org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171)
Re: [VOTE] SOC temporary committer Anders Nyman
Tim Funk wrote: As part of the Google SOC. Google accepted the tomcat-reverse-proxy project to be executed by Anders Nyman ( anders.nyman at gmail d ot com ) The scope of the project is to let Tomcat act a reverse proxy by extending the balancer webapp. To make it easier to get the job done this summer while not relying on an intermediate committer, I propose granting commit access for only the following module: jakarta-tomcat-catalina/webapps/balancer/ The apache id granted would be prefixed with soc and be temporary. A CLA has already been signed and submitted. The vote is for commit access only for the module listed above. Voting rights will not be granted. [ ] Sounds good to me [ ] I'm indifferent [ ] I don't like it. Here's why Probably the best is to create a sourceforge project and when the code is mature enough incubate it. -Tim - 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: [VOTE] SOC temporary committer Anders Nyman
At 01:25 PM 7/11/2005, you wrote: William A. Rowe, Jr. wrote: It's important for students involved with SoC to learn to use the tools of our organization; I don't agree with you. The Tomcat is not place for some 'sandbox' projects. If the ASF have some agreement with Google then it should have created a 'SoC Google sandbox' not trying to force every project to create a 'Google sandbox'. The ASF didn't agree with Google that 'we need more code' (many projects seem overwhelmed at times by the amount of code they manage already, no slight intended...) The ASF agreed that Open Source needs to continue to grow in contributors. The only way to grow more contributors is to have them learn in-place. The mentor's job is to help them set up, avoid the usual foibles, help them participate in the community, and do a bit of steering of the project. Because the entire pace is 'accelerated' it is humanistically challenging, but far from impossible to bring an individual up to speed over a month or few. So it's unusual, and we aren't handing away keys to the entire kingdom. But setting up a sandbox (not your problem, it's the mentors) and watching the progress (if it scratches your itch) is not an imposition on the individual project communities. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] SOC temporary committer Anders Nyman
William A. Rowe, Jr. wrote: At 01:25 PM 7/11/2005, you wrote: If the ASF have some agreement with Google then it should have created a 'SoC Google sandbox' not trying to force every project to create a 'Google sandbox'. So it's unusual, and we aren't handing away keys to the entire kingdom. But setting up a sandbox (not your problem, it's the mentors) and watching the progress (if it scratches your itch) is not an imposition on the individual project communities. Well if Tim wants to mentor that project, then fine with me. I'm sure he will ensure the integrity of the Tomcat source outside that 'sandbox' repository. If the project will have access and modify the files outside that repository, I'll be strongly against that. I'm sure the Tim will find a solution for a files that needs to be changed and that are are of the core, by simply mirroring them to the sandbox repository or something similar. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] SOC temporary committer Anders Nyman
William A. Rowe, Jr. wrote: At 01:25 PM 7/11/2005, you wrote: William A. Rowe, Jr. wrote: It's important for students involved with SoC to learn to use the tools of our organization; I don't agree with you. The Tomcat is not place for some 'sandbox' projects. If the ASF have some agreement with Google then it should have created a 'SoC Google sandbox' not trying to force every project to create a 'Google sandbox'. The ASF didn't agree with Google that 'we need more code' (many projects seem overwhelmed at times by the amount of code they manage already, no slight intended...) The ASF agreed that Open Source needs to continue to grow in contributors. The only way to grow more contributors is to have them learn in-place. The mentor's job is to help them set up, avoid the usual foibles, help them participate in the community, and do a bit of steering of the project. Because the entire pace is 'accelerated' it is humanistically challenging, but far from impossible to bring an individual up to speed over a month or few. So it's unusual, and we aren't handing away keys to the entire kingdom. But setting up a sandbox (not your problem, it's the mentors) and watching the progress (if it scratches your itch) is not an imposition on the individual project communities. Ok, so if we say it's the mentor's responsability, then it should be fine. I'll let the persons I'm mentoring know about the infrstructure we chose, then. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35698] New: - [363 javajni.c] [error] Unsuported JNI version 65537
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35698. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35698 Summary: [363 javajni.c] [error] Unsuported JNI version 65537 Product: Tomcat 5 Version: 5.5.9 Platform: Other OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Unknown AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Hi, i want to use tomcat but after installation the service does not start. my components: apache 2.0.54 Java 1.3.1_14 JAVA webStart 1.2 PHP 5.0.4 what shall i do ? and plz write it simple, im from germany, thx :) the error: [2005-07-12 10:52:38] [info] Running Service... [2005-07-12 10:52:38] [info] Starting service... [2005-07-12 10:52:38] [363 javajni.c] [error] Unsuported JNI version 65537 [2005-07-12 10:52:38] [903 prunsrv.c] [error] Failed initializing java C:\WebServer\Tomcat 5.5\bin\bootstrap.jar [2005-07-12 10:52:38] [1131 prunsrv.c] [error] ServiceStart returned 2 [2005-07-12 10:52:38] [info] Run service finished. [2005-07-12 10:52:38] [info] Procrun finished. many thanks in advance! Kay -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35698] - [363 javajni.c] [error] Unsuported JNI version 65537
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35698. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35698 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2005-07-12 11:58 --- *** This bug has been marked as a duplicate of 28988 *** -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28988] - windows nt service fails to start: [2004-05-14 12:45:19] [364 javajni.c] [error] Unsuported JNI version 65537
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28988. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28988 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2005-07-12 11:58 --- *** Bug 35698 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jni/native/src sslinfo.c
mturk 2005/07/12 06:28:57
Modified:jni/native/src sslinfo.c
Log:
Socket used is abstract socket not the SSL opaque.
Revision ChangesPath
1.7 +11 -4 jakarta-tomcat-connectors/jni/native/src/sslinfo.c
Index: sslinfo.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jni/native/src/sslinfo.c,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- sslinfo.c 8 Jul 2005 07:49:56 - 1.6
+++ sslinfo.c 12 Jul 2005 13:28:57 - 1.7
@@ -203,13 +203,15 @@
TCN_IMPLEMENT_CALL(jobject, SSLSocket, getInfoB)(TCN_STDARGS, jlong sock,
jint what)
{
-tcn_ssl_conn_t *s = J2P(sock, tcn_ssl_conn_t *);
+tcn_socket_t *a = J2P(sock, tcn_socket_t *);
+tcn_ssl_conn_t *s;
jbyteArray array = NULL;
apr_status_t rv = APR_SUCCESS;
UNREFERENCED(o);
TCN_ASSERT(sock != 0);
+s = (tcn_ssl_conn_t *)(a-opaque);
switch (what) {
case SSL_INFO_SESSION_ID:
{
@@ -281,13 +283,15 @@
TCN_IMPLEMENT_CALL(jstring, SSLSocket, getInfoS)(TCN_STDARGS, jlong sock,
jint what)
{
-tcn_ssl_conn_t *s = J2P(sock, tcn_ssl_conn_t *);
+tcn_socket_t *a = J2P(sock, tcn_socket_t *);
+tcn_ssl_conn_t *s;
jstring value = NULL;
apr_status_t rv = APR_SUCCESS;
UNREFERENCED(o);
TCN_ASSERT(sock != 0);
+s = (tcn_ssl_conn_t *)(a-opaque);
switch (what) {
case SSL_INFO_SESSION_ID:
{
@@ -491,12 +495,15 @@
TCN_IMPLEMENT_CALL(jint, SSLSocket, getInfoI)(TCN_STDARGS, jlong sock,
jint what)
{
-tcn_ssl_conn_t *s = J2P(sock, tcn_ssl_conn_t *);
+tcn_socket_t *a = J2P(sock, tcn_socket_t *);
+tcn_ssl_conn_t *s;
jint value = -1;
UNREFERENCED(o);
TCN_ASSERT(sock != 0);
+s = (tcn_ssl_conn_t *)(a-opaque);
+
switch (what) {
case SSL_INFO_CIPHER_USEKEYSIZE:
case SSL_INFO_CIPHER_ALGKEYSIZE:
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jni/native/src sslinfo.c
mturk 2005/07/12 06:38:38 Modified:jni/native/src sslinfo.c Log: Set the rv to APR_SUCCESS if the CERT_CHAIN is valid Revision ChangesPath 1.8 +2 -1 jakarta-tomcat-connectors/jni/native/src/sslinfo.c Index: sslinfo.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jni/native/src/sslinfo.c,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- sslinfo.c 12 Jul 2005 13:28:57 - 1.7 +++ sslinfo.c 12 Jul 2005 13:38:38 - 1.8 @@ -485,6 +485,7 @@ free(result); } } +rv = APR_SUCCESS; } if (rv != APR_SUCCESS) tcn_ThrowAPRException(e, rv); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jni/native/src sslinfo.c
mturk 2005/07/12 06:43:59
Modified:jni/native/src sslinfo.c
Log:
Throw the exception if rv != APR_SUCCESS
Revision ChangesPath
1.9 +1 -1 jakarta-tomcat-connectors/jni/native/src/sslinfo.c
Index: sslinfo.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jni/native/src/sslinfo.c,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- sslinfo.c 12 Jul 2005 13:38:38 - 1.8
+++ sslinfo.c 12 Jul 2005 13:43:59 - 1.9
@@ -223,7 +223,7 @@
}
break;
default:
-tcn_ThrowAPRException(e, APR_EINVAL);
+rv = APR_EINVAL;
break;
}
if (what SSL_INFO_CLIENT_MASK) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Problem when a click a button that it execute a servlet n times
Hi, I have a problem with a button in my jsp page. When I click the button then it excutes a servlet. But if i click two or three or n times it executes a servlet n times. How can I do that this button execute only once independent of the number of times that you click the button. Thanks. - Correo Yahoo! Comprueba qué es nuevo, aquí http://correo.yahoo.es
cvs commit: jakarta-tomcat-connectors/jni/native/src sslinfo.c
mturk 2005/07/12 06:58:49
Modified:jni/native/src sslinfo.c
Log:
Get int param for obtaining the number of certificates in the chain,
so that we don't rely on the first exception for getting the certificate.
Revision ChangesPath
1.10 +8 -1 jakarta-tomcat-connectors/jni/native/src/sslinfo.c
Index: sslinfo.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jni/native/src/sslinfo.c,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- sslinfo.c 12 Jul 2005 13:43:59 - 1.9
+++ sslinfo.c 12 Jul 2005 13:58:49 - 1.10
@@ -521,6 +521,13 @@
}
}
break;
+case SSL_INFO_CLIENT_CERT_CHAIN:
+{
+X509 *xs;
+STACK_OF(X509) *sk = SSL_get_peer_cert_chain(s-ssl);
+value = sk_X509_num(sk);
+}
+break;
default:
tcn_ThrowAPRException(e, APR_EINVAL);
break;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat Connector Benchmark
Hi, I would like to know if there is an official benchmark to compare the scalability/throughput of the new connectors (APR, Grizzly, ...) and Coyote. If not, maybe it's a good time to define one. Regards, Vicenç - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Connector Benchmark
there isn't any official benchmark, but there's the benchmarks I ran this year and the results. peter On 7/12/05, Vicenc Beltran Querol [EMAIL PROTECTED] wrote: Hi, I would like to know if there is an official benchmark to compare the scalability/throughput of the new connectors (APR, Grizzly, ...) and Coyote. If not, maybe it's a good time to define one. Regards, Vicenç - 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 Connector Benchmark
Vicenc Beltran Querol wrote: Hi, I would like to know if there is an official benchmark to compare the scalability/throughput of the new connectors (APR, Grizzly, ...) and Coyote. If not, maybe it's a good time to define one. I am confident you are going to be willing to contribute rigged results. BTW, Grizzly is not a Tomcat connector, it is a component of a separate product. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jni/native/src dir.c error.c file.c info.c jnilib.c lock.c misc.c mmap.c network.c os.c poll.c pool.c proc.c shm.c ssl.c sslcontext.c sslinfo.c sslnetwork.c sslutils.c stdlib.c user.c
mturk 2005/07/12 07:56:12 Modified:jni/examples/org/apache/tomcat/jni Echo.java jni/java/org/apache/tomcat Apr.java jni/java/org/apache/tomcat/jni Address.java BIOCallback.java Directory.java Error.java File.java FileInfo.java Global.java Library.java Local.java Lock.java Mmap.java Multicast.java OS.java PasswordCallback.java Poll.java Pool.java PoolCallback.java Proc.java ProcErrorCallback.java Procattr.java SSL.java SSLContext.java SSLSocket.java Shm.java Sockaddr.java Socket.java Status.java Stdlib.java Time.java User.java jni/native/include ssl_private.h tcn.h tcn_version.h jni/native/os/netware system.c jni/native/os/unix system.c uxpipe.c jni/native/os/win32 ntpipe.c system.c jni/native/src dir.c error.c file.c info.c jnilib.c lock.c misc.c mmap.c network.c os.c poll.c pool.c proc.c shm.c ssl.c sslcontext.c sslinfo.c sslnetwork.c sslutils.c stdlib.c user.c Log: Update Copyright comments to reflect the current year. Revision ChangesPath 1.15 +2 -2 jakarta-tomcat-connectors/jni/examples/org/apache/tomcat/jni/Echo.java Index: Echo.java === RCS file: /home/cvs/jakarta-tomcat-connectors/jni/examples/org/apache/tomcat/jni/Echo.java,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- Echo.java 18 Jun 2005 08:03:21 - 1.14 +++ Echo.java 12 Jul 2005 14:56:09 - 1.15 @@ -1,5 +1,5 @@ /* - * Copyright 1999-2004 The Apache Software Foundation + * Copyright 2000-2005 The Apache Software Foundation * * Licensed under the Apache License, Version 2.0 (the License); * you may not use this file except in compliance with the License. 1.2 +1 -1 jakarta-tomcat-connectors/jni/java/org/apache/tomcat/Apr.java Index: Apr.java === RCS file: /home/cvs/jakarta-tomcat-connectors/jni/java/org/apache/tomcat/Apr.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- Apr.java 14 Jan 2005 13:45:58 - 1.1 +++ Apr.java 12 Jul 2005 14:56:09 - 1.2 @@ -1,5 +1,5 @@ /* - * Copyright 1999,2004 The Apache Software Foundation. + * Copyright 2000-2005 The Apache Software Foundation * * Licensed under the Apache License, Version 2.0 (the License); * you may not use this file except in compliance with the License. 1.8 +2 -2 jakarta-tomcat-connectors/jni/java/org/apache/tomcat/jni/Address.java Index: Address.java === RCS file: /home/cvs/jakarta-tomcat-connectors/jni/java/org/apache/tomcat/jni/Address.java,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- Address.java 1 Jun 2005 12:50:51 - 1.7 +++ Address.java 12 Jul 2005 14:56:09 - 1.8 @@ -1,5 +1,5 @@ /* - * Copyright 1999-2004 The Apache Software Foundation + * Copyright 2000-2005 The Apache Software Foundation * * Licensed under the Apache License, Version 2.0 (the License); * you may not use this file except in compliance with the License. 1.5 +2 -2 jakarta-tomcat-connectors/jni/java/org/apache/tomcat/jni/BIOCallback.java Index: BIOCallback.java === RCS file: /home/cvs/jakarta-tomcat-connectors/jni/java/org/apache/tomcat/jni/BIOCallback.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- BIOCallback.java 9 Jun 2005 09:33:40 - 1.4 +++ BIOCallback.java 12 Jul 2005 14:56:09 - 1.5 @@ -1,5 +1,5 @@ /* - * Copyright 1999-2004 The Apache Software Foundation + * Copyright 2000-2005 The Apache Software Foundation * * Licensed under the Apache License, Version 2.0 (the License); * you may not use this file except in compliance with the License. 1.3 +2 -2 jakarta-tomcat-connectors/jni/java/org/apache/tomcat/jni/Directory.java Index: Directory.java === RCS file: /home/cvs/jakarta-tomcat-connectors/jni/java/org/apache/tomcat/jni/Directory.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- Directory.java14 Jan 2005 14:42:37 - 1.2 +++ Directory.java12 Jul 2005 14:56:09 - 1.3 @@ -1,5 +1,5 @@ /* - * Copyright 1999-2004 The Apache Software Foundation + * Copyright
Re: j-t-c/common/build - j-t-c/jk/support ?
William A. Rowe, Jr. wrote: It turns out the common/build macros are only referenced within the jk tree (which is all I check out to build modjk). I'd like to move the apache.m4, get_ver.awk and os_apache.m4 scripts to this new home, preserving history by copying the ,v files, stripping old tags from the new copies and then cvs rm'ing the originals. Votes/comments/concerns? +1 Bill - 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]
how can I put enable a button when a servlet has finished.
Hi, I have a jsp page, and when I click a button it puts disable this button and calls a servlet. This servlet update a table of a database. I want to enable the button when the servlet has finished. How can I put enable this button? Thanks. - Correo Yahoo! Comprueba qué es nuevo, aquí http://correo.yahoo.es
mod_jk 1.2.10 and tomcat 5.5.9 buffer overflow
Hello all, I was kindly redirected to this list by Mr. Turk, the author of mod_jk. He suggested that someone here might be able to determine why when using mod_jk and tomcat and apache, I am getting buffer overflow messages in the catalina.out logfile. This tends to happen after 8 hours or so, and after users have been visiting the website, not when idle. I have the relevant portion of the log here: My mod_jk as stated is 1.2.10, tomcat is 5.5.9, and apache is 2.0.52-12 (RedHat 4.0ES build). SEVERE: Buffer overflow: buffer.len=8192 pos=70 data=18568 Jun 28, 2005 6:16:21 PM org.apache.jk.common.MsgAjp cpBytes SEVERE: Overflow java.lang.Throwable at org.apache.jk.common.MsgAjp.cpBytes(MsgAjp.java:172) at org.apache.jk.common.MsgAjp.appendByteChunk(MsgAjp.java:146) at org.apache.jk.common.MsgAjp.appendBytes(MsgAjp.java:132) at org.apache.jk.server.JkCoyoteHandler.appendHead(JkCoyoteHandler.java:407) at org.apache.jk.server.JkCoyoteHandler.action(JkCoyoteHandler.java:425) at org.apache.coyote.Response.action(Response.java:182) at org.apache.coyote.Response.sendHeaders(Response.java:374) at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:317) at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:278) at org.apache.catalina.connector.Response.finishResponse(Response.java:473) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:307) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:385) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) I'd appreciate any help you can offer, Thank you, Collin McClendon -- Collin McClendon Sr. Microsoft Systems Engineer Digicon, Inc. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35707] New: - Reactivate path attribute for Context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35707. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35707 Summary: Reactivate path attribute for Context Product: Tomcat 5 Version: 5.5.9 Platform: Other OS/Version: other Status: NEW Severity: enhancement Priority: P4 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] In Tomcat 4, when dropping an xml file in the webapps/ directory (or $CATALINA_HOME/conf/[enginename]/[hostname]/ in 5.5), the context path for the deployed application was taken from the path attribute of the Context element contained in the file. In Tomcat 5.5, it is no longer the case as the context path is infered from the file name (cf. http://jakarta.apache.org/tomcat/tomcat-5.5- doc/config/context.html) I think it was a great feature allowing to switch webapps version quickly: * I have a directory where I have multiple context xml files referencing different version of a single webapp: mywebapp-1.0.xml mywebapp-2.0.xml (they use the same context path, but *not* the same docBase) * When I need to test a given version I just copy the associated xml file to the tomcat $CATALINA_HOME/webapps directory and the correct webapp version is used. In Tomcat 5.5 the process is more difficult as I have to rename the file. Another advantage is that I could name webapps related to each other with the same prefix (with no relation at all with the context paths). Could it be possible to re-allow the path attribute to override the name infered from the file name? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35707] - Reactivate path attribute for Context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35707. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35707 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2005-07-12 18:54 --- No. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11AprProcessor.java
remm2005/07/12 10:01:42
Modified:jni/java/org/apache/tomcat/jni SSLSocket.java
http11/src/java/org/apache/coyote/http11
Http11AprProcessor.java
Log:
- Translate old SSL code to APR (untested right now).
Revision ChangesPath
1.18 +1 -4
jakarta-tomcat-connectors/jni/java/org/apache/tomcat/jni/SSLSocket.java
Index: SSLSocket.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jni/java/org/apache/tomcat/jni/SSLSocket.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- SSLSocket.java12 Jul 2005 14:56:09 - 1.17
+++ SSLSocket.java12 Jul 2005 17:01:42 - 1.18
@@ -16,9 +16,6 @@
package org.apache.tomcat.jni;
-/* Import needed classes */
-import java.nio.ByteBuffer;
-
/** SSL Socket
*
* @author Mladen Turk
1.23 +52 -31
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11AprProcessor.java
Index: Http11AprProcessor.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11AprProcessor.java,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- Http11AprProcessor.java 7 Jul 2005 22:54:13 - 1.22
+++ Http11AprProcessor.java 12 Jul 2005 17:01:42 - 1.23
@@ -16,6 +16,7 @@
package org.apache.coyote.http11;
+import java.io.ByteArrayInputStream;
import java.io.IOException;
import java.io.InterruptedIOException;
import java.net.InetAddress;
@@ -24,6 +25,8 @@
import java.util.regex.PatternSyntaxException;
import java.security.AccessController;
import java.security.PrivilegedAction;
+import java.security.cert.CertificateFactory;
+import java.security.cert.X509Certificate;
import org.apache.coyote.ActionCode;
import org.apache.coyote.ActionHook;
@@ -41,6 +44,8 @@
import org.apache.coyote.http11.filters.VoidOutputFilter;
import org.apache.coyote.http11.filters.BufferedInputFilter;
import org.apache.tomcat.jni.Address;
+import org.apache.tomcat.jni.SSL;
+import org.apache.tomcat.jni.SSLSocket;
import org.apache.tomcat.jni.Sockaddr;
import org.apache.tomcat.jni.Socket;
import org.apache.tomcat.util.buf.Ascii;
@@ -50,7 +55,6 @@
import org.apache.tomcat.util.http.FastHttpDateFormat;
import org.apache.tomcat.util.http.MimeHeaders;
import org.apache.tomcat.util.net.AprEndpoint;
-import org.apache.tomcat.util.net.SSLSupport;
import org.apache.tomcat.util.threads.ThreadWithAttributes;
@@ -90,6 +94,8 @@
outputBuffer = new InternalAprOutputBuffer(response,
headerBufferSize);
response.setOutputBuffer(outputBuffer);
request.setResponse(response);
+
+ssl = !off.equalsIgnoreCase(endpoint.getSSLEngine());
initializeFilters();
@@ -194,10 +200,10 @@
/**
- * SSL information.
+ * SSL enabled ?
*/
-protected SSLSupport sslSupport;
-
+protected boolean ssl = false;
+
/**
* Socket associated with the current connection.
@@ -645,14 +651,6 @@
/**
- * Set the SSL information for this HTTP connection.
- */
-public void setSSLSupport(SSLSupport sslSupport) {
-this.sslSupport = sslSupport;
-}
-
-
-/**
* Set the flag to control upload time-outs.
*/
public void setDisableUploadTimeout(boolean isDisabled) {
@@ -898,9 +896,6 @@
inputBuffer.recycle();
outputBuffer.recycle();
-// Recycle ssl info
-sslSupport = null;
-
return openSocket;
}
@@ -1084,23 +1079,36 @@
} else if (actionCode == ActionCode.ACTION_REQ_SSL_ATTRIBUTE ) {
try {
-if (sslSupport != null) {
-Object sslO = sslSupport.getCipherSuite();
+if (ssl) {
+Object sslO = SSLSocket.getInfoS(socket,
SSL.SSL_INFO_CIPHER);
if (sslO != null)
request.setAttribute
-(SSLSupport.CIPHER_SUITE_KEY, sslO);
-sslO = sslSupport.getPeerCertificateChain(false);
+(javax.servlet.request.cipher_suite, sslO);
+int certLength = SSLSocket.getInfoI(socket,
SSL.SSL_INFO_CLIENT_CERT_CHAIN);
+X509Certificate[] certs = new
X509Certificate[certLength];
+for (int i = 0; i certLength; i++) {
+byte[] data = SSLSocket.getInfoB(socket,
SSL.SSL_INFO_CLIENT_CERT_CHAIN + i);
+CertificateFactory cf =
+
DO NOT REPLY [Bug 35707] - Reactivate path attribute for Context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35707. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35707 --- Additional Comments From [EMAIL PROTECTED] 2005-07-12 19:03 --- At least the answer is clear. First and last enhancement posted... I guess this is your goal anyway. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.10 and tomcat 5.5.9 buffer overflow
The message is simply that you have a header value that is too big for the AJP/1.3 protocol to handle. If you enable DEBUG logging for org.apache.jk.common.MsgAjp, you should get a dump of the partial data that should include the name of the bad header. - Original Message - From: Collin McClendon [EMAIL PROTECTED] To: tomcat-dev@jakarta.apache.org Sent: Tuesday, July 12, 2005 9:38 AM Subject: mod_jk 1.2.10 and tomcat 5.5.9 buffer overflow Hello all, I was kindly redirected to this list by Mr. Turk, the author of mod_jk. He suggested that someone here might be able to determine why when using mod_jk and tomcat and apache, I am getting buffer overflow messages in the catalina.out logfile. This tends to happen after 8 hours or so, and after users have been visiting the website, not when idle. I have the relevant portion of the log here: My mod_jk as stated is 1.2.10, tomcat is 5.5.9, and apache is 2.0.52-12 (RedHat 4.0ES build). SEVERE: Buffer overflow: buffer.len=8192 pos=70 data=18568 Jun 28, 2005 6:16:21 PM org.apache.jk.common.MsgAjp cpBytes SEVERE: Overflow java.lang.Throwable at org.apache.jk.common.MsgAjp.cpBytes(MsgAjp.java:172) at org.apache.jk.common.MsgAjp.appendByteChunk(MsgAjp.java:146) at org.apache.jk.common.MsgAjp.appendBytes(MsgAjp.java:132) at org.apache.jk.server.JkCoyoteHandler.appendHead(JkCoyoteHandler.java:407) at org.apache.jk.server.JkCoyoteHandler.action(JkCoyoteHandler.java:425) at org.apache.coyote.Response.action(Response.java:182) at org.apache.coyote.Response.sendHeaders(Response.java:374) at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:317) at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:278) at org.apache.catalina.connector.Response.finishResponse(Response.java:473) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:307) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:385) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav a:684) at java.lang.Thread.run(Thread.java:595) I'd appreciate any help you can offer, Thank you, Collin McClendon -- Collin McClendon Sr. Microsoft Systems Engineer Digicon, Inc. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.10 and tomcat 5.5.9 buffer overflow
Bill Barker wrote: The message is simply that you have a header value that is too big for the AJP/1.3 protocol to handle. If you enable DEBUG logging for org.apache.jk.common.MsgAjp, you should get a dump of the partial data that should include the name of the bad header. Given the line, it could be a monster header value, possibly a cookie (the size is 18KB, which is way over the AJP/1.3 capabilities). Rémy (with the neophyte AJP developer hat on) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.10 and tomcat 5.5.9 buffer overflow
Thanks so much for replying! I can understand that concept. Given that we are using mod_jk to connect the Apache frontend to Tomcat running OpenCMS on the backend, perhaps the way that the application is working that is giving us this result? Also in response to Bill, where can one turn on DEBUG logging for a specific class such as org.apache.jk.common.MsgAjp ? I'm thinking that would be in one of the xml config files and I will do more research on that, but if you had a quick answer, I'd be happy to hear it. On the suggestion of Mladen Turk, I did upgrade to mod_jk 1.2.14, I hope to see some difference there. Thanks again, Collin Remy Maucherat wrote: Bill Barker wrote: The message is simply that you have a header value that is too big for the AJP/1.3 protocol to handle. If you enable DEBUG logging for org.apache.jk.common.MsgAjp, you should get a dump of the partial data that should include the name of the bad header. Given the line, it could be a monster header value, possibly a cookie (the size is 18KB, which is way over the AJP/1.3 capabilities). Rémy (with the neophyte AJP developer hat on) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Collin McClendon Sr. Microsoft Systems Engineer Digicon, Inc. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.10 and tomcat 5.5.9 buffer overflow
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/logging.html - Original Message - From: Collin McClendon [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Tuesday, July 12, 2005 10:57 AM Subject: Re: mod_jk 1.2.10 and tomcat 5.5.9 buffer overflow Thanks so much for replying! I can understand that concept. Given that we are using mod_jk to connect the Apache frontend to Tomcat running OpenCMS on the backend, perhaps the way that the application is working that is giving us this result? Also in response to Bill, where can one turn on DEBUG logging for a specific class such as org.apache.jk.common.MsgAjp ? I'm thinking that would be in one of the xml config files and I will do more research on that, but if you had a quick answer, I'd be happy to hear it. On the suggestion of Mladen Turk, I did upgrade to mod_jk 1.2.14, I hope to see some difference there. Thanks again, Collin Remy Maucherat wrote: Bill Barker wrote: The message is simply that you have a header value that is too big for the AJP/1.3 protocol to handle. If you enable DEBUG logging for org.apache.jk.common.MsgAjp, you should get a dump of the partial data that should include the name of the bad header. Given the line, it could be a monster header value, possibly a cookie (the size is 18KB, which is way over the AJP/1.3 capabilities). Rémy (with the neophyte AJP developer hat on) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Collin McClendon Sr. Microsoft Systems Engineer Digicon, Inc. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
wrowe 2005/07/12 12:17:43
Modified:jk/native/apache-2.0 mod_jk.c
Log:
Use the same mutex check as we use in the unix MPMs.
Revision ChangesPath
1.152 +3 -3 jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c
Index: mod_jk.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c,v
retrieving revision 1.151
retrieving revision 1.152
diff -u -r1.151 -r1.152
--- mod_jk.c 16 Jun 2005 06:30:45 - 1.151
+++ mod_jk.c 12 Jul 2005 19:17:42 - 1.152
@@ -68,7 +68,7 @@
#include apr_strings.h
-#if APR_USE_SYSVSEM_SERIALIZE || APR_USE_FLOCK_SERIALIZE
+#ifdef AP_NEED_SET_MUTEX_PERMS
#include unixd.h /* for unixd_set_global_mutex_perms */
#endif
/*
@@ -2419,7 +2419,7 @@
return HTTP_INTERNAL_SERVER_ERROR;
}
-#if APR_USE_SYSVSEM_SERIALIZE || APR_USE_FLOCK_SERIALIZE
+#ifdef AP_NEED_SET_MUTEX_PERMS
rv = unixd_set_global_mutex_perms(jk_log_lock);
if (rv != APR_SUCCESS) {
ap_log_error(APLOG_MARK, APLOG_CRIT, rv, s,
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.10 and tomcat 5.5.9 buffer overflow
Thanks, I'll read up on this. Bill Barker wrote: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/logging.html - Original Message - From: Collin McClendon [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Tuesday, July 12, 2005 10:57 AM Subject: Re: mod_jk 1.2.10 and tomcat 5.5.9 buffer overflow Thanks so much for replying! I can understand that concept. Given that we are using mod_jk to connect the Apache frontend to Tomcat running OpenCMS on the backend, perhaps the way that the application is working that is giving us this result? Also in response to Bill, where can one turn on DEBUG logging for a specific class such as org.apache.jk.common.MsgAjp ? I'm thinking that would be in one of the xml config files and I will do more research on that, but if you had a quick answer, I'd be happy to hear it. On the suggestion of Mladen Turk, I did upgrade to mod_jk 1.2.14, I hope to see some difference there. Thanks again, Collin Remy Maucherat wrote: Bill Barker wrote: The message is simply that you have a header value that is too big for the AJP/1.3 protocol to handle. If you enable DEBUG logging for org.apache.jk.common.MsgAjp, you should get a dump of the partial data that should include the name of the bad header. Given the line, it could be a monster header value, possibly a cookie (the size is 18KB, which is way over the AJP/1.3 capabilities). Rémy (with the neophyte AJP developer hat on) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Collin McClendon Sr. Microsoft Systems Engineer Digicon, Inc. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Collin McClendon Sr. Microsoft Systems Engineer Digicon, Inc. [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/support jk_apache_static.m4
wrowe 2005/07/12 12:38:18 Modified:jk/native configure.in jk/native/apache-1.3 Makefile.netware NWGNUmakefile.mak jk/native/apache-2.0 NWGNUmakefile jk/native/jni Makefile.netware jk/native/netscape Makefile.netware jk/native2/server/apache2 NWGNUmakefile jk/support jk_apache_static.m4 Removed: common/build apache.m4 get_ver.awk os_apache.m4 Log: Relocate apache.m4 get_ver.awk os_apache.m4 resources from common/build into jk/support. It appears apache.m4 may no longer be in use from a simple grep of the source tree. The new copies in jk/support already include revision history but no tags at that location. Revision ChangesPath 1.50 +2 -2 jakarta-tomcat-connectors/jk/native/configure.in Index: configure.in === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/configure.in,v retrieving revision 1.49 retrieving revision 1.50 diff -u -r1.49 -r1.50 --- configure.in 6 Jul 2005 13:36:55 - 1.49 +++ configure.in 12 Jul 2005 19:38:18 - 1.50 @@ -199,7 +199,7 @@ dnl Apache-2.0 needs the os subdirectory to include os.h dnl this include is copy from os/config.m4 -sinclude(../../common/build/os_apache.m4) +sinclude(../support/os_apache.m4) dnl it is copied from the configure of JServ ;=) dnl and adapted. 1.8 +1 -1 jakarta-tomcat-connectors/jk/native/apache-1.3/Makefile.netware Index: Makefile.netware === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-1.3/Makefile.netware,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- Makefile.netware 10 Jun 2005 16:24:35 - 1.7 +++ Makefile.netware 12 Jul 2005 19:38:18 - 1.8 @@ -165,7 +165,7 @@ $(OBJDIR)/version.inc: $(JKCOMMON)/jk_version.h $(AP_HOME)/src/include/httpd.h $(OBJDIR) @echo Creating $@ - @awk -f ../../../common/build/get_ver.awk $ $(AP_HOME)/src/include/httpd.h $@ + @awk -f ../../support/get_ver.awk $ $(AP_HOME)/src/include/httpd.h $@ dist: all -$(RM) $(OBJDIR)/*.o $(OBJDIR)/$(TARGET).map $(OBJDIR)/$(TARGET).ncv 1.3 +1 -1 jakarta-tomcat-connectors/jk/native/apache-1.3/NWGNUmakefile.mak Index: NWGNUmakefile.mak === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-1.3/NWGNUmakefile.mak,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- NWGNUmakefile.mak 13 Feb 2005 22:28:07 - 1.2 +++ NWGNUmakefile.mak 12 Jul 2005 19:38:18 - 1.3 @@ -273,7 +273,7 @@ $(OBJDIR)/version.inc: $(JKCOMMON)/jk_version.h $(SRC)/include/httpd.h $(OBJDIR) @echo Creating $@ - @awk -f ../../../common/build/get_ver.awk $ $(SRC)/include/httpd.h $@ + @awk -f ../../support/get_ver.awk $ $(SRC)/include/httpd.h $@ # Include the version info retrieved from jk_version.h -include $(OBJDIR)/version.inc 1.8 +1 -1 jakarta-tomcat-connectors/jk/native/apache-2.0/NWGNUmakefile Index: NWGNUmakefile === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/NWGNUmakefile,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- NWGNUmakefile 13 Feb 2005 12:25:04 - 1.7 +++ NWGNUmakefile 12 Jul 2005 19:38:18 - 1.8 @@ -297,7 +297,7 @@ $(OBJDIR)/version.inc: $(JKCOMMON)/jk_version.h $(OBJDIR) @echo Creating $@ - @awk -f ../../../common/build/get_ver.awk $ $@ + @awk -f ../../support/get_ver.awk $ $@ # 1.5 +1 -1 jakarta-tomcat-connectors/jk/native/jni/Makefile.netware Index: Makefile.netware === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/jni/Makefile.netware,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- Makefile.netware 28 Jul 2004 14:24:48 - 1.4 +++ Makefile.netware 12 Jul 2005 19:38:18 - 1.5 @@ -150,7 +150,7 @@ $(OBJDIR)/version.inc: $(JKCOMMON)/jk_version.h $(OBJDIR) @echo Creating $@ - @awk -f ../../../common/build/get_ver.awk $ $@ + @awk -f ../../support/get_ver.awk $ $@ dist: all -$(RM) $(OBJDIR)/*.o $(OBJDIR)/$(TARGET).map $(OBJDIR)/$(TARGET).ncv 1.6 +1 -1 jakarta-tomcat-connectors/jk/native/netscape/Makefile.netware Index: Makefile.netware === RCS file:
JK 1.2.14 core dump oddity
Something's not quite right in mod_jk-land. The pertinent httpd.conf is; ErrorDocument 404 /examplestomcat/error.jsp Alias /examplestomcat /local0/test/webapps/examplestomcat JkMount /examplestomcat/*.jsp ajp13 when the 404 causes error.jsp to be returned, the response code is unset from 404 to 200-ok. This behavior is not a regression, seems it's been that way for a long (1.2.8 or earlier) time. Line 1971 of jk/native/apache-2.0/mod_jk.c says... return OK; /* NOT r-status, even if it has changed. */ This goes back to version 1.1 of the module; the question is; WHY? Bill Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK 1.2.14 core dump oddity
William A. Rowe, Jr. wrote: Line 1971 of jk/native/apache-2.0/mod_jk.c says... return OK; /* NOT r-status, even if it has changed. */ This goes back to version 1.1 of the module; the question is; WHY? Well, mod_jk presumes that when Tomcat serves the page it is 200. You can make a custom error pages in Tomcat directly without using ErrorDocument 404 /xxx Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK 1.2.14 core dump oddity
It's not the return OK; my bad. Something deeper is going on here, some interaction with Apache 2, having to do with the request_rec status not being bubbled back to the origin error. But if anyone has clues to point me at, I'd appreciate it. At 02:52 PM 7/12/2005, William A. Rowe, Jr. wrote: Something's not quite right in mod_jk-land. The pertinent httpd.conf is; ErrorDocument 404 /examplestomcat/error.jsp Alias /examplestomcat /local0/test/webapps/examplestomcat JkMount /examplestomcat/*.jsp ajp13 when the 404 causes error.jsp to be returned, the response code is unset from 404 to 200-ok. This behavior is not a regression, seems it's been that way for a long (1.2.8 or earlier) time. Line 1971 of jk/native/apache-2.0/mod_jk.c says... return OK; /* NOT r-status, even if it has changed. */ This goes back to version 1.1 of the module; the question is; WHY? Bill Bill - 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: JK 1.2.14 core dump oddity
- Original Message - From: William A. Rowe, Jr. [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Tuesday, July 12, 2005 12:52 PM Subject: JK 1.2.14 core dump oddity Something's not quite right in mod_jk-land. The pertinent httpd.conf is; ErrorDocument 404 /examplestomcat/error.jsp Alias /examplestomcat /local0/test/webapps/examplestomcat JkMount /examplestomcat/*.jsp ajp13 when the 404 causes error.jsp to be returned, the response code is unset from 404 to 200-ok. This behavior is not a regression, seems it's been that way for a long (1.2.8 or earlier) time. It goes back at least to 1.1.x. Line 1971 of jk/native/apache-2.0/mod_jk.c says... return OK; /* NOT r-status, even if it has changed. */ This goes back to version 1.1 of the module; the question is; WHY? You're the httpd expert, not me ;-). As I understand it, it is to have httpd return the Tomcat response code (which won't be 404 unless error.jsp explictly sets it to that). Bill Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35709] New: - allow to crate a short-lived secondary session from a request to prevent cross-site scripting
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35709. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35709 Summary: allow to crate a short-lived secondary session from a request to prevent cross-site scripting Product: Tomcat 5 Version: Nightly Build Platform: Other OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: Connector:Coyote AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] org.apache.catalina.connector.Request.doGetSession(boolean create) only will create a new session if there is no existing one. Goal: - This would be used in the following way to prevent a cross-site scripting attack if a user doesn't allow for cookies and thus uses URL-rewriting with the jsessionid. Problem description: Often web-apps deliver html files entered by one user to a receiving user via the HttpServletResponse object. When the receiver then views the received file, the browser still has the jsession ID in the referrer field. A script could use this to transfer that jsessionid to another server to hijack that session before expiration. Apparently the referring URL will be presented to a remote (attacking) server for example when the receiver's browser loads images asked for by the html file from that remote server. Solution idea: -- 1) obtain a secondary session without invalidating the current one to which the receiving user is logged in 2) put the html file to be downloaded into that new session redirect the file-download to another (struts-) action with that temporary session id 3) deliver the html file to the receiving user with the response of the short-lived secondary session 4) upon closing the response's outputstream, immediately invalidate that temporary session Preliminary assessment: -- === i) by the time a remote server receives the temporary jsessionid, it is normally already invalidated ii) if the html-file is already rendered by the receiver's browser before fully being downloaded, a remote attacker might see the jsessionid before it is invalidated. However, since there was no real login into that session, it will not have any privileges and contents beyond the very html file the attacker originally put into circulation -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35709] - allow to crate a short-lived secondary session from a request to prevent cross-site scripting
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35709. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35709 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2005-07-12 22:50 --- You seem to have a bit too much time on your hands. There are gaping holes in session security (without SSL), it's not worth trying to patch the existing model. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35710] New: - Enable Session Replication via Cross Context calls
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35710. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35710 Summary: Enable Session Replication via Cross Context calls Product: Tomcat 5 Version: 5.5.9 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P3 Component: Catalina:Cluster AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] I am creating this issue as a documentation and watch point for the eventual enabling of session replication for contexts that are the targets of a cross context dispatch. This issue was discussed on the tomcat-dev mailing list. The archive of the discussion can be found here: http://www.mail-archive.com/tomcat-dev%40jakarta.apache.org/msg73283.html -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK 1.2.14 core dump oddity
At 03:04 PM 7/12/2005, William A. Rowe, Jr. wrote: It's not the return OK; my bad. Something deeper is going on here, some interaction with Apache 2, having to do with the request_rec status not being bubbled back to the origin error. But if anyone has clues to point me at, I'd appreciate it. Ok, most httpd modules presume r-status is 200, and only set it in the case of exceptions. This is why a cgi with no 'Status:' header will return the error code if it is configured as the errordocument, but if 'Status: 200' is passed with the headers, the 'error code' is lost. In mod_jk's case, we always set r-status. So we could decide to do nothing for 200 OK, or leave as is. But it seems that alot of modules make this 'mistake' and it really should be up to httpd to 'fix' the error result if it's using a given resource as an 'error page'. So I'm proposing to httpd that it gets fixed on that side. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Anne-Sophie Brichard/EUZ/ChubbMail is out of the office.
I will be out of the office starting 13/07/2005 and will not return until 19/07/2005. En cas d'urgence, merci de bien vouloir contacter Sandra Boutboul ([EMAIL PROTECTED]) au 01 70 36 65 90 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] SOC temporary committer Anders Nyman
At 03:48 AM 7/12/2005, Mladen Turk wrote: Well if Tim wants to mentor that project, then fine with me. I'm sure he will ensure the integrity of the Tomcat source outside that 'sandbox' repository. Exactly the point; there were no SoC participants who did not have mentors. If this slides into the Tomcat CVS, the mentor will help with calling the vote, following procedures, etc. If the project will have access and modify the files outside that repository, I'll be strongly against that. No; I don't think anyone is asking for the SoC participants to have live access on projects that have strong traditions of merit-before-commit privileges. Some projects are much loser granting commit, such projects would probably just add another committer for the summer. I'm sure the Tim will find a solution for a files that needs to be changed and that are are of the core, by simply mirroring them to the sandbox repository or something similar. Or merging back the outcome with history. I just wanted to point out three other things; * it's really much easier if the sandbox is in svn:, such users don't need accounts on a box. * no matter if cvs or svn, the sandbox commits must be broadcast to [EMAIL PROTECTED] read or ignore them as you please. And please don't complain about the outcome if you didn't feel like actually following the progress :) * development discussion under the tomcat umbrella should occur on [EMAIL PROTECTED], the whole point is for the participants to follow the day to day life of a project, and be welcome to put forward proposals and accept feedback. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35709] - allow to crate a short-lived secondary session from a request to prevent cross-site scripting
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35709. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35709 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Additional Comments From [EMAIL PROTECTED] 2005-07-13 07:09 --- as usual, Remy, the most friendly inhabitant of this planet... ;) You are right, I would obviously use this only together with SSL and possibly even a 2-out-of-3 rule as described in Bug 22679, comm. 12 Alternatively, if you were to think that this still is a WONTFIX, how would you then prevent cross-site scripting in presence of such gaping holes -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
