DO NOT REPLY [Bug 20568] New: - JK tomcat connector configured as plug-in mapped to extension ".jsp" invalidates session each time when processing HTTP GET requests

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=20568

JK tomcat connector configured as plug-in mapped to extension ".jsp" invalidates 
session each time when processing HTTP GET requests

   Summary: JK tomcat connector configured as plug-in mapped to
extension ".jsp" invalidates session each time when
processing HTTP GET requests
   Product: Tomcat 4
   Version: 4.1.12
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Connector:Coyote JK 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Using IIS to serve static content like static pages, images, etc. and Tomcat to 
serve JSPs and Servlets. IIS and Tomcat run on same Windows 2000 SP3 server. To 
communicate between IIS and Tomcat we are using Tomcat Connector JK version 
1.2.3 (isapi_redirect.dll). If it is configured as ISAPI Filter it will process 
POST and GET requests correctly in terms of keeping valid session. But if it is 
configured as plug-in mapped to extension ".jsp" it will keep valid session 
only while processing POST requests, it invalidates session each time when 
processing GET requests, therefore while processing GET requests Tomcat creates 
each time new HTTP session on the server.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20567] New: - JK2 tomcat connector does not work if configured in IIS as a plug-in mapped to extension.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=20567

JK2 tomcat connector does not work if configured in IIS as a plug-in mapped to 
extension.

   Summary: JK2 tomcat connector does not work if configured in IIS
as a plug-in mapped to extension.
   Product: Tomcat 4
   Version: 4.1.24
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Connector:Coyote JK 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Using IIS to serve static content like static pages, images, etc. and Tomcat to 
serve JSPs and Servlets. IIS and Tomcat run on same Windows 2000 SP3 server. To 
communicate between IIS and Tomcat we are using Tomcat Connector JK2 version 
2.0.2 (isapi_redirector2.dll). It works if it is configured as ISAPI Filter but 
it does not work if it is configured as plug-in mapped to extension ".jsp". In 
last case Browser displays error message and there are no log entries anywhere 
except IIS log that indicates that IIS received request.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit:jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5CoyoteRequest.java

[Jean-Francois Arcand]

Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:

jfarcand2003/06/06 12:04:51

  Modified:catalina/src/share/org/apache/coyote/tomcat5
CoyoteRequest.java
  Log:
  Revert the patch until I come with a better solution.


I'd like to be convinced there's a bug here ;-)

Look: When you access the request, getRequest will create a new facade 
if there's none.
It will then be cleared and nulled only on recycle, which only occurs at 
the end of the request processing (or there's a bug).

If your tag has incorrect pooling and keeps a reference, it could work 
very well without a security manager, but it's an accident (you're 
accessing a random underlying request). With a security manager, the 
request object becomes invalid after the request, and you get the NPE on 
the second request. The second request thing is a usual symptom of a bug 
with tag pooling.
Do you have the source of the tag, BTW ?
Yes, your explanation makes sence. I will look at the tag code to see 
what I can find.But the exception also occurs when tag pooling is set to 
off.

If the tag has a bug/not well designed, I still think the app should not 
fail with an NPE but with an IllegalSomething exception.The 
CoyoteRequest object shouldn't be set to null when the client still have 
some reference to it.

Thanks,

-- Jeanfrancois



Remy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5CoyoteRequest.java

[Remy Maucherat]

[EMAIL PROTECTED] wrote:
jfarcand2003/06/06 12:04:51

  Modified:catalina/src/share/org/apache/coyote/tomcat5
CoyoteRequest.java
  Log:
  Revert the patch until I come with a better solution.
I'd like to be convinced there's a bug here ;-)

Look: When you access the request, getRequest will create a new facade 
if there's none.
It will then be cleared and nulled only on recycle, which only occurs at 
the end of the request processing (or there's a bug).

If your tag has incorrect pooling and keeps a reference, it could work 
very well without a security manager, but it's an accident (you're 
accessing a random underlying request). With a security manager, the 
request object becomes invalid after the request, and you get the NPE on 
the second request. The second request thing is a usual symptom of a bug 
with tag pooling.
Do you have the source of the tag, BTW ?

Remy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20563] New: - Unable to reference jsps, tablibs across multiple contexts

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=20563

Unable to reference jsps, tablibs across multiple contexts

   Summary: Unable to reference jsps, tablibs across multiple
contexts
   Product: Tomcat 4
   Version: 4.1.24
  Platform: PC
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


How do I reference objects in different contexts?  For instance, if I am 
working in "../webapps/app1/hello.jsp" how would I refenence a tablib, jsp, etc 
in "../webapps/app2" from "../webapps/app1/hello.jsp".  I have set the "cross-
context" attribute to "true" for both context's, but this did not solve my 
problem.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteRequest.java

[jfarcand]

jfarcand2003/06/06 12:04:51

  Modified:catalina/src/share/org/apache/coyote/tomcat5
CoyoteRequest.java
  Log:
  Revert the patch until I come with a better solution.
  
  Revision  ChangesPath
  1.9   +5 -5  
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java
  
  Index: CoyoteRequest.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- CoyoteRequest.java6 Jun 2003 03:03:33 -   1.8
  +++ CoyoteRequest.java6 Jun 2003 19:04:50 -   1.9
  @@ -597,7 +597,7 @@
* is the facade.  This method must be implemented by a subclass.
*/
   public ServletRequest getRequest() {
  -if (facade == null || Constants.SECURITY) {
  +if (facade == null) {
   facade = new CoyoteRequestFacade(this);
   } 
   return (facade);
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit:jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5CoyoteRequest.java

[Jean-Francois Arcand]

Remy Maucherat wrote:
Jean-Francois Arcand wrote:

OK, let's try to describe the problem. First, here is the stack trace 
the application is throwing when running:

java.lang.NullPointerException
at 
org.apache.coyote.tomcat5.CoyoteRequestFacade.getAttribute(CoyoteRequestFaca 

de.java:271)
at com.sun.web.ui.view.html.CCButton.getAttribute(CCButton.java:306)
at 
com.sun.web.ui.view.html.CCButton.restoreStateData(CCButton.java:284)
at com.sun.web.ui.view.html.CCButton.beginDisplay(CCButton.java:204)
at 
com.sun.web.ui.taglib.html.CCButtonTag.getHTMLString(CCButtonTag.java:236) 

at 
com.sun.web.ui.taglib.html.CCButtonTag.doEndTag(CCButtonTag.java:178)
at 
org.apache.jsp.Module3_jsp._jspx_meth_cc_button_0(Module3_jsp.java:205)
at 
org.apache.jsp.Module3_jsp._jspx_meth_jato_form_0(Module3_jsp.java:138)
at 
org.apache.jsp.Module3_jsp._jspx_meth_jato_useViewBean_0(Module3_jsp.java:97 

)
at org.apache.jsp.Module3_jsp._jspService(Module3_jsp.java:70)
at 
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:136)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)

I don't think this is an application bug.

Note that the problem doesn't occurs with 4.0.x or if you run it 
without   the security manager. The first time the application runs 
(very simple test), no exception is produced. The second time you run, 
then the old facade object (the one used by the first request) is 
still available but since the clear method has been invoked, the 
request instance is set to null (so the NPE is thrown). It is clear 
that the facade object used when the NPE is thrown is the one used by 
the first invokation. It seems that facade object has not been 
recycled properly.

I can send you the war file if you want to see the behaviour. It is 
very easy to reproduce on both 4.1.x and 5.0 (so that has nothing to 
do with package protection/access and the security changes we made in 5).

I don't think the current solution open security issue, but I agree it 
is not an elegant solution. The other solution we have is to not 
invoke, in CoyoteRequest.recycle(), CoyoteRequestFacade.clear(), which 
set to null the CoyoteRequest. That solution works also:

Index: CoyoteRequest.java
===
RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java,v 

retrieving revision 1.8
diff -u -r1.8 CoyoteRequest.java
--- CoyoteRequest.java  6 Jun 2003 03:03:33 -   1.8
+++ CoyoteRequest.java  6 Jun 2003 16:55:13 -
@@ -438,7 +438,6 @@
 mappingData.recycle();
 if ((Constants.SECURITY) && (facade != null)) {
-facade.clear();
 facade = null;
 }
.
This way the facade will be cleared and we will not create a facade 
for every request.


If a webapp hags on to the facade, it can access the underlying request. 
That seems to me like a security problem. That also seems like a 
security bug to Bill, and that's why we both vetoed your commit.
I understand and I will revert the patch (but I/we need to fix the 
problem). What about not calling the clear() method? What I find strange 
is the following:

CoyoteRequest_instance invokes CoyoteRequestFacade_instance.clear() 
which set CoyoteRequest_instance = null. Same for the response.

So applying the above patch by not calling the clear method should be 
better that the current solution (hope to have less that 2 -1 ;-)


I will look at the bug. However, since the facade is only cleared at the 
end of the request processing (in the recycle), I don't see how you can 
produce a valid test case.
Very simple one actually.I was under the same impression until they 
sent me the test case.

It could be a bug with the tag and tag pooling. Disable tag pooling to 
see if it fixes the problem.
No, it doesn't fix the problem on both 4.1.x/5.x

-- Jeanfrancois

Remy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20561] New: - Limitation of availiable high ports for JK2

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=20561

Limitation of availiable high ports for JK2

   Summary: Limitation of availiable high ports for JK2
   Product: Tomcat 4
   Version: 4.1.18
  Platform: Sun
OS/Version: Solaris
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Connector:Coyote JK 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Solaris 9
Apache 2.0.46
Jakarta 4.1.18
mod_jk2 2.0.2

There seems to be a limitation on the range of ports you can use for the jk2 
connector.  For example port="7009" or port="17005" work in server.xml.
However, high ports such as port="58009" will not.

When the port is too high it seems to default to the default value (8009), even 
when 8009 isn't even mentioned in server.xml.  Tomcat does start a listener on 
port 58009 and netstat sees it as in a LISTEN state.

When the port is "in range" the logs are clean.

from apache 2.0.46 error.log:

[Fri Jun 06 11:56:47 2003] [error] channelSocket.open() connect failed 127.0.0.1
:8009 146 Connection refused 
[Fri Jun 06 11:56:47 2003] [error] ajp13.connect() failed ajp13:localhost:58009
[Fri Jun 06 11:56:47 2003] [error] ajp13.service() failed to connect endpoint er
rno=146 Connection refused
[Fri Jun 06 11:56:47 2003] [error] ajp13.service() Error  forwarding ajp13:local
host:58009 1 1
[Fri Jun 06 11:56:47 2003] [error] mod_jk.handler() Error connecting to tomcat 1
2

-Eric

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: jakarta-tomcat-connectors/jk/native configure.in

[Minimalist Manager]

ERROR:
There is no such list CONFIGURE.IN here.

SOLUTION:
Send a message to [EMAIL PROTECTED] with a subject
of 'info' (no quotes) for a list of available mailing lists.

-- 
Sincerely, the Minimalist

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 15790] - JkCoyoteHandler Unable to process X509 Certificate from Apache 2.0.43/mod_jk

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=15790

JkCoyoteHandler Unable to process X509 Certificate from Apache 2.0.43/mod_jk

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2003-06-06 18:29 ---
*** Bug 20556 has been marked as a duplicate of this bug. ***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20556] - 2 way authentication with JK2 Coyote Connector

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=20556

2 way authentication with JK2 Coyote Connector

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2003-06-06 18:29 ---


*** This bug has been marked as a duplicate of 15790 ***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20556] New: - 2 way authentication with JK2 Coyote Connector

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=20556

2 way authentication with JK2 Coyote Connector

   Summary: 2 way authentication with JK2 Coyote Connector
   Product: Tomcat 4
   Version: 4.1.24
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Connector:Coyote JK 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The JkCoyoteHandler class is giving a Certificate Convertion error when trying 
to send client certificates to the server on Apache 1.3.27, Tomcat 4.1.24, 
Jboss 3.0. I found this fix in a mailing list and it works. By the way, 
convertion is spelt conversion

-- james


Thorvald Natvig wrote:

>For those that have been suffering problems using 2-way authenticating
>with the JK2 Coyote connector, this patch should fix the problem. It's not
>a good fix, but it's a fix nonetheless.
>
>
>
>
>
>--- jakarta-tomcat-connectors-4.1.24-
src/jk/java/org/apache/jk/server/JkCoyoteHandler.java 2003-03-19 
10:21:04.0 +0100
>+++ jakarta-tomcat-connectors-4.1.24-src-
new/jk/java/org/apache/jk/server/JkCoyoteHandler.java 2003-03-25 
17:10:54.0 +0100
>@@ -384,7 +384,7 @@
> // Extract SSL certificate information (if requested)
> MessageBytes certString = (MessageBytes)req.getNote(WorkerEnv.SSL_CERT_NOTE);
> if( certString != null ) {
>- byte[] certData = certString.getByteChunk().getBytes();
>+ byte[] certData = certString.toString().getBytes();
> ByteArrayInputStream bais = new ByteArrayInputStream(certData);
>
> // Fill the first element.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re:cvscommit:jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Http11Processor.javaHttp11Protocol.java

[Jan Luehe]

Remy,

> > P.S.: I'm also +1 for removing the CertificatesValve, since it is
> > confusing to have several valves essentially doing the same thing.
> 
> There's no need to hardcode the authenticator, you only need to add it
> in startup.Authenticators.properties, and it will be added in the
> pipeline as needed. It's already there, BTW, so I don't quite see what's
> going on (but it should be fixed there, no harcoding required).

yes, I understand. The confusing part was that in ContextConfig, we
were adding both the CertificatesValve (in certificatesConfig) and the
Authenticator configured in web-app/login-config/auth-method, where
CertificatesValve and SSLAuthenticator were essentially doing the
same, except that CertificatesValve was operating on the (SSL)Socket
and was always failing on a CoyoteRequest (whose getSocket() always returns
null).

Bill has cleared up this confusion by removing the certificatesConfig() method.

Thanks,


Jan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5CoyoteRequest.java

[Remy Maucherat]

Jean-Francois Arcand wrote:
OK, let's try to describe the problem. First, here is the stack trace 
the application is throwing when running:

java.lang.NullPointerException
at 
org.apache.coyote.tomcat5.CoyoteRequestFacade.getAttribute(CoyoteRequestFaca 

de.java:271)
at com.sun.web.ui.view.html.CCButton.getAttribute(CCButton.java:306)
at 
com.sun.web.ui.view.html.CCButton.restoreStateData(CCButton.java:284)
at com.sun.web.ui.view.html.CCButton.beginDisplay(CCButton.java:204)
at 
com.sun.web.ui.taglib.html.CCButtonTag.getHTMLString(CCButtonTag.java:236)
at 
com.sun.web.ui.taglib.html.CCButtonTag.doEndTag(CCButtonTag.java:178)
at 
org.apache.jsp.Module3_jsp._jspx_meth_cc_button_0(Module3_jsp.java:205)
at 
org.apache.jsp.Module3_jsp._jspx_meth_jato_form_0(Module3_jsp.java:138)
at 
org.apache.jsp.Module3_jsp._jspx_meth_jato_useViewBean_0(Module3_jsp.java:97 

)
at org.apache.jsp.Module3_jsp._jspService(Module3_jsp.java:70)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:136)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
I don't think this is an application bug.

Note that the problem doesn't occurs with 4.0.x or if you run it without 
  the security manager. The first time the application runs (very simple 
test), no exception is produced. The second time you run, then the old 
facade object (the one used by the first request) is still available but 
since the clear method has been invoked, the request instance is set to 
null (so the NPE is thrown). It is clear that the facade object used 
when the NPE is thrown is the one used by the first invokation. It seems 
that facade object has not been recycled properly.

I can send you the war file if you want to see the behaviour. It is very 
easy to reproduce on both 4.1.x and 5.0 (so that has nothing to do with 
package protection/access and the security changes we made in 5).

I don't think the current solution open security issue, but I agree it 
is not an elegant solution. The other solution we have is to not invoke, 
in CoyoteRequest.recycle(), CoyoteRequestFacade.clear(), which set to 
null the CoyoteRequest. That solution works also:

Index: CoyoteRequest.java
===
RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java,v 

retrieving revision 1.8
diff -u -r1.8 CoyoteRequest.java
--- CoyoteRequest.java  6 Jun 2003 03:03:33 -   1.8
+++ CoyoteRequest.java  6 Jun 2003 16:55:13 -
@@ -438,7 +438,6 @@
 mappingData.recycle();
 if ((Constants.SECURITY) && (facade != null)) {
-facade.clear();
 facade = null;
 }
.
This way the facade will be cleared and we will not create a facade for 
every request.
If a webapp hags on to the facade, it can access the underlying request. 
That seems to me like a security problem. That also seems like a 
security bug to Bill, and that's why we both vetoed your commit.

I will look at the bug. However, since the facade is only cleared at the 
end of the request processing (in the recycle), I don't see how you can 
produce a valid test case.
It could be a bug with the tag and tag pooling. Disable tag pooling to 
see if it fixes the problem.

Remy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit:jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5CoyoteRequest.java

[Jean-Francois Arcand]

OK, let's try to describe the problem. First, here is the stack trace 
the application is throwing when running:

java.lang.NullPointerException
	at 
org.apache.coyote.tomcat5.CoyoteRequestFacade.getAttribute(CoyoteRequestFaca
de.java:271)
	at com.sun.web.ui.view.html.CCButton.getAttribute(CCButton.java:306)
	at com.sun.web.ui.view.html.CCButton.restoreStateData(CCButton.java:284)
	at com.sun.web.ui.view.html.CCButton.beginDisplay(CCButton.java:204)
	at 
com.sun.web.ui.taglib.html.CCButtonTag.getHTMLString(CCButtonTag.java:236)
	at com.sun.web.ui.taglib.html.CCButtonTag.doEndTag(CCButtonTag.java:178)
	at org.apache.jsp.Module3_jsp._jspx_meth_cc_button_0(Module3_jsp.java:205)
	at org.apache.jsp.Module3_jsp._jspx_meth_jato_form_0(Module3_jsp.java:138)
	at 
org.apache.jsp.Module3_jsp._jspx_meth_jato_useViewBean_0(Module3_jsp.java:97
)
	at org.apache.jsp.Module3_jsp._jspService(Module3_jsp.java:70)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:136)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)

I don't think this is an application bug.

Note that the problem doesn't occurs with 4.0.x or if you run it without 
  the security manager. The first time the application runs (very 
simple test), no exception is produced. The second time you run, then 
the old facade object (the one used by the first request) is still 
available but since the clear method has been invoked, the request 
instance is set to null (so the NPE is thrown). It is clear that the 
facade object used when the NPE is thrown is the one used by the first 
invokation. It seems that facade object has not been recycled properly.

I can send you the war file if you want to see the behaviour. It is very 
easy to reproduce on both 4.1.x and 5.0 (so that has nothing to do with 
package protection/access and the security changes we made in 5).

I don't think the current solution open security issue, but I agree it 
is not an elegant solution. The other solution we have is to not invoke, 
in CoyoteRequest.recycle(), CoyoteRequestFacade.clear(), which set to 
null the CoyoteRequest. That solution works also:

Index: CoyoteRequest.java
===
RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java,v
retrieving revision 1.8
diff -u -r1.8 CoyoteRequest.java
--- CoyoteRequest.java  6 Jun 2003 03:03:33 -   1.8
+++ CoyoteRequest.java  6 Jun 2003 16:55:13 -
@@ -438,7 +438,6 @@
 mappingData.recycle();

 if ((Constants.SECURITY) && (facade != null)) {
-facade.clear();
 facade = null;
 }
.
This way the facade will be cleared and we will not create a facade for 
every request.

-- Jeanfrancois





Bill Barker wrote:
- Original Message -
From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, June 05, 2003 11:49 PM
Subject: Re: cvs commit:
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5
CoyoteRequest.java


Bill Barker wrote:

I'm -1 on this patch unless you can explain what the bug exactly was,
and how the recycling couldn't properly reset the facade.
I'm not really happy with the patch either.  I'll postpone adding my

(since

it's the second, binding) -1 until you provide a better explaination.
Well, I have no idea what the bug report mentioned looks like, so I
can't provide a real evaluation. However, what I'm now pretty sure about
is that the patch is possibly unsafe.
Note: AFAIK, one -1 is enough.


I've had plenty of solo -1s ignored :).  I understood the rule as "more -1
than +1 with the committer assumed to +1".  Then, again, I'm not big on
rules, and that's for the PMC to work out anyway ;-).
Reading Remy's comments, I'm giving my official -1 (so, even with my
interpretation, this must be reverted unless you can convince someone to
change their Vote).

Remy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re:cvscommit:jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Http11Processor.javaHttp11Protocol.java

[Jan Luehe]

Bill,

> SSLAuthenticator makes a request for a special Request attribute
> ("org.apache.coyote.request.X509Certificate"), which fires off an Action
> hook (ACTION_REQ_SSL_CERTIFICATE) to renegotiate the handshake if necessary.
> 
> I changed TC 5 a little while back to do a lazy-evaluation of the SSL
> attributes.  If you are seeing problems, that might be where.

Well, the reason I was still using the (supposedly deprecated)
CertificatesValve was because it was still being added to the pipeline
in ContextConfig. I'm going to change ContextConfig as follows:

Index: ContextConfig.java
===
RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
retrieving revision 1.25
diff -u -r1.25 ContextConfig.java
--- ContextConfig.java  14 May 2003 17:42:55 -  1.25
+++ ContextConfig.java  5 Jun 2003 23:08:13 -
@@ -497,7 +497,7 @@
 Valve certificates = null;
 try {
 Class clazz =
-Class.forName("org.apache.catalina.valves.CertificatesValve");
+Class.forName("org.apache.catalina.authenticator.SSLAuthenticator");
 certificates = (Valve) clazz.newInstance();
 } catch (Throwable t) {
 return; // Probably JSSE classes not present

Even with this fix in place, the SSLAuthenticator's authenticate() method
was still not being invoked, because 
org.apache.catalina.authenticator.AuthenticatorBase
currently does not consider the CLIENT-CERT authentication constraint at
all.

After fixing this, the SSL handshake does get renegotiated in the way you
described, but for some reason the connection then times out. I'm still investigating.

Thanks for putting me on the right track, Bill!

Jan

P.S.: I'm also +1 for removing the CertificatesValve, since it is
confusing to have several valves essentially doing the same thing.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20551] - JK2 module for AOLserver

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=20551

JK2 module for AOLserver





--- Additional Comments From [EMAIL PROTECTED]  2003-06-06 16:01 ---
Created an attachment (id=6672)
JK2 connector module for AOLserver 4.0

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20551] New: - JK2 module for AOLserver

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=20551

JK2 module for AOLserver

   Summary: JK2 module for AOLserver
   Product: Tomcat 4
   Version: 4.1.24
  Platform: All
OS/Version: All
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Connector:Coyote JK 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


This code reflects comments from Tomcat developers. It removes Java-Tcl bridge
logic and corrects treatment of URI maps.

Files in the archive supercede what is already in CVS for
jtc/jk/native2/server/aolserver, and removes java/ directory completely, as well
as few .c files. Please be sure to do a diff on build.xml and
build.properties.sample files prior to merging archive content with CVS.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20527] New: - solution to Unable to compile class for JSP

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=20527

solution to Unable to compile class for JSP

   Summary: solution to Unable to compile class for JSP
   Product: Tomcat 4
   Version: 4.1.24
  Platform: Sun
OS/Version: Solaris
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Several users have encountered this jsp error, One possible cause is
if a temp file cannot be written to the current directory.

Symptom:

HTTP Status 500 - Internal Server Error

type Exception report

message Internal Server Error

description The server encountered an internal error (Internal Server
Error) that prevented it from fulfilling this request.

exception

org.apache.jasper.JasperException: Unable to compile class for JSP

An error occurred at line: -1 in the jsp file: null

Generated servlet error:
 [javac] Since fork is true, ignoring compiler setting.
 [javac] Compiling 1 source file
 [javac] Since fork is true, ignoring compiler setting.
  
  at
org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:130)
  at org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:293)
  at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:353)
  at org.apache.jasper.compiler.Compiler.compile(Compiler.java:370)
  at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:473)
  at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:190)
  at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)
  at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
[...]

Apache Tomcat/4.1.24


in catalina.out found this:

Error creating temporary file
at
org.apache.tools.ant.taskdefs.compilers.DefaultCompilerAdapter.executeExternalCompile(Def
aultCompilerAdapter.java:433)
at
org.apache.tools.ant.taskdefs.compilers.JavacExternal.execute(JavacExternal.java:81)
[etc etc]
Caused by: java.io.FileNotFoundException:
/usr/apache/jakarta-tomcat-4.1.24/files-1650139464 (Perm
ission denied)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.(FileOutputStream.java:176)
at java.io.FileOutputStream.(FileOutputStream.java:131)
at java.io.FileWriter.(FileWriter.java:73)
at
org.apache.tools.ant.taskdefs.compilers.DefaultCompilerAdapter.executeExternalCompile(Def
aultCompilerAdapter.java:424)
... 38 more
--- Nested Exception ---
java.io.FileNotFoundException:
/usr/apache/jakarta-tomcat-4.1.24/files-1650139464 (Permission deni
ed)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.(FileOutputStream.java:176)
at java.io.FileOutputStream.(FileOutputStream.java:131)
at java.io.FileWriter.(FileWriter.java:73)
at
org.apache.tools.ant.taskdefs.compilers.DefaultCompilerAdapter.executeExternalCompile(Def
aultCompilerAdapter.java:424)

Looking at the source of ant 1.5.1,
org.apache.tools.ant.taskdefs.compilers.DefaultCompilerAdapter.java
It does this:
   String userDirName = System.getProperty("user.dir");
   File userDir = new File(userDirName);
   tmpFile = fileUtils.createTempFile("files", "", userDir);
   out = new PrintWriter(new FileWriter(tmpFile));

Looks like ant wants to write to user.dir. What's that?
"The system property user.dir contains the current user directory."
Hmm. I like ${CATALINA_HOME} read only.

I start tomcat using "${CATALINA_HOME}/bin/catalina.sh start", so
adding 
CATALINA_OPTS='-Duser.dir=/an/appropriate/temp/directory'
export CATALINA_OPTS
is a workaround.

-- 
nord

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [5.0] More dependencies

[Bill Barker]

I know that at one point there was a problem if you enabled the JMX consol
(e.g. set mx.port=9000 in jk2.properties).  I don't remember if that's been
fixed.

But the short answer is, yes the HttpAdapter creates non-daemon threads.

- Original Message -
From: "Tim Funk" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, June 05, 2003 2:12 PM
Subject: Re: [5.0] More dependencies


> When I was testing with the HttpAdapter and Sun's JMX 1.2ri, on shutdown
of
> tomcat the JVM did not die. If I removed the jar - all was OK. (But of
course
> I lost HttpAdapter functionality) Does anyone know if Sun's HttpAdapter
> creates non-daemon threads? Of course the problem might be in tomcat too,
I'm
> sorry for not doing much debugging on this yet.
>
> Unfortunately, I was using cygwin and you can't get JVM stacktraces with
cygwin.
>
> Time permitting, I will try testing this on linux box tonight to see what
> threads are keeping the JVM alive. (Or *gasp* - go back to using the bat
files)
>
> -Tim
>
> Remy Maucherat wrote:
> >
> > JMX: I think we should try to ship with JMX 1.2 + a JSR 160
> > implementation if possible. I really hope MX4J will be able to provide
> > that.
> >
> >
> > Remy
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [5.0] More dependencies

[Remy Maucherat]

Jean-Francois Arcand wrote:
Remy Maucherat wrote:
commons-launcher: Problem; I think I did release 0.9 with Patrick Luby 
a long time ago, and the component has been dead since. Reviving it 
and putting a websiter up could help, but it's not certain. This piece 
of code was developed for the Sun web services pack 1.0 originally. 
Does anyone use it anymore ? Can it be removed (in favor of native 
wrappers) ? I have to admit it was quite nice, so I'd rather not have 
to remove it.
Yes, jwsdp 1.2 is still using it. I also think we should keep it.
Cool. IMO it's good enough to be released, and quite useful :) So we 
need to do a release then.

Watchdog: (to the Sun folks) Where is Watchdog 5 (or whatever it's 
called) ?
I'm unaware of such packages (but I will double check).
Well, there must be something to test the new specs, right ? Esp JSP 2.0 ...

Remy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [5.0] More dependencies

[Tim Funk]

When I was testing with the HttpAdapter and Sun's JMX 1.2ri, on shutdown of 
tomcat the JVM did not die. If I removed the jar - all was OK. (But of course 
I lost HttpAdapter functionality) Does anyone know if Sun's HttpAdapter 
creates non-daemon threads? Of course the problem might be in tomcat too, I'm 
sorry for not doing much debugging on this yet.

Unfortunately, I was using cygwin and you can't get JVM stacktraces with cygwin.

Time permitting, I will try testing this on linux box tonight to see what 
threads are keeping the JVM alive. (Or *gasp* - go back to using the bat files)

-Tim

Remy Maucherat wrote:
JMX: I think we should try to ship with JMX 1.2 + a JSR 160 
implementation if possible. I really hope MX4J will be able to provide 
that.

Remy


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20521] - javax.servlet.ServletException: No more connections available in pool

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=20521

javax.servlet.ServletException: No more connections available in pool

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-06-05 21:07 ---
Bug is in a 3rd party lib. Sorry to bother you.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20516] - Jasper2 compilation not JSP 2.0 compliant on J2SE 1.4

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=20516

Jasper2 compilation not JSP 2.0 compliant on J2SE 1.4





--- Additional Comments From [EMAIL PROTECTED]  2003-06-05 20:55 ---
Kin-Man,

Thank you for looking into the generation within Jasper 2.  I'll do exactly as 
you suggested and compare the WebLogic output with Jasper 2 and post my 
findings back here once I've completed the analysis.  It could be that Jasper 2 
is correct and WebLogic is wrong.  

Todd

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20516] - Jasper2 compilation not JSP 2.0 compliant on J2SE 1.4

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=20516

Jasper2 compilation not JSP 2.0 compliant on J2SE 1.4





--- Additional Comments From [EMAIL PROTECTED]  2003-06-05 20:31 ---
As far as jasper is concern, it is responsible for generating the smap in the
SourceDebugExtension attribute of the class file.  How other tools uses this
information is not its concern.

I have dumped the generated class file, and as far as I can tell, the
SourceDebugExtension attribute contains the correct information.  If you can
point out the problems here, I'll fix them.

Perhaps if you compare the class files generated by Jasper to those generated by
Weblogic, you'll be able to tell me what Jasper is doing wrong.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20521] New: - javax.servlet.ServletException: No more connections available in pool

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=20521

javax.servlet.ServletException: No more connections available in pool

   Summary: javax.servlet.ServletException: No more connections
available in pool
   Product: Tomcat 4
   Version: 4.1.24
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Major
  Priority: Other
 Component: Servlet & JSP API
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have a JSP page that is getting this error intermittantly. Usually once or 
twice per day. Once I get the error, Tomcat will not respond to any further 
requests until it has been restarted. Here is the stack trace:

2003-06-04 19:04:15 StandardWrapperValve[jsp]: Servlet.service() for servlet 
jsp threw exception
org.apache.jasper.JasperException: No more connections available in pool.
at org.apache.jasper.servlet.JspServletWrapper.service
(JspServletWrapper.java:254)
at org.apache.jasper.servlet.JspServlet.serviceJspFile
(JspServlet.java:295)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:247)
at org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:256)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:191)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContext.invoke
(StandardContext.java:2415)
at org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:180)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke
(ErrorDispatcherValve.java:171)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:641)
at org.apache.catalina.valves.ErrorReportValve.invoke
(ErrorReportValve.java:172)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardEngineValve.invoke
(StandardEngineValve.java:174)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.coyote.tomcat4.CoyoteAdapter.service
(CoyoteAdapter.java:223)
at org.apache.coyote.http11.Http11Processor.process
(Http11Processor.java:594)
at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnectio
n(Http11Protocol.java:392)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt
(PoolTcpEndpoint.java:565)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
(ThreadPool.java:619)
at java.lang.Thread.run(Thread.java:536)
- Root Cause -
javax.servlet.ServletException: No more connections available in pool.
at org.apache.jasper.runtime.PageContextImpl.handlePageException
(PageContextImpl.java:536)
at org.apache.jsp.Save_jsp._jspService(Save_jsp.java:515)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:137)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.jasper.servlet.JspServletWrapper.service
(JspServletWrapper.java:210)
at org.apache.jasper.servlet.JspServlet.serviceJspFile
(JspServlet.java:295)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
at javax.servle

DO NOT REPLY [Bug 20546] New: - Tomcat sends an invalid HTTP response

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=20546

Tomcat sends an invalid HTTP response

   Summary: Tomcat sends an invalid HTTP response
   Product: Tomcat 4
   Version: 4.0.3 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Connector:Coyote HTTP/1.1
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I've uncovered a condition with 4.0.3 where the following response is returned 
to the client:

HTTP/1.1 400 Bad Request
Content-Type: text/html
Date: Wed, 28 May 2003 18:37:02 GMT
Connection: close
Server: Apache Tomcat/4.0.3 (HTTP/1.1 Connector)

Tomcat does not close the connection however which is causing the two
clients I've tested against (IE 6.0 and curl) to hang in their read loops.
I've been digging in RFC 2616 to try and understand who is at fault here,
and my understanding is that since there is no Content-Length returned and
the response is not chunked-encoded that the client should read until the
connection is closed.  Speaking with the curl developers they feel that this is 
a Tomcat bug and that the response needs to either set Content-Length: 0 or 
Tomcat needs to shutdown the connection after sending the header.  Also they 
point out that 2616 says that a 400 request SHOULD include an entity (but is 
obviously not required to do so).

So, any thoughts on this?  Are we understanding this properly as a server issue 
vs. a client problem?

P.S. The way I am able to duplicate this issue is to issue a GET request where 
the URI exceeds 32k.  I realize that in itself is pretty ridiculous and perhaps 
this behavior is some sort of defense against a DOS attack or the like but I 
could not find it documented anywhere.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit:jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Http11Processor.java Http11Protocol.java

[Bill Barker]

- Original Message -
From: "Jan Luehe" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, June 05, 2003 12:05 PM
Subject: Re: cvs
commit:jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Htt
p11Processor.java Http11Protocol.java


> Remy/Bill,
>
> > Ouch, that's one nasty hack.
> > -1, please revert it.
> >
> > There are callbacks to the processor to evaluate the SSL related
> > attributes. If something is broken, this should be fixed, but using that
> > pattern. I believe get/setSocket are useless, and the calls should be
> > entierely removed.
>
> I noticed the ActionHook calls to get SSL related attributes, however,
> CertificatesValve needs the SSLSocket in order to renegotiate an SSL
> handshake if the requested resource is from a webapp with this
> authentication constraint:
>
>
>   CLIENT-CERT
>
>
> If the request was received through an SSL-enabled connector that does
> not enforce SSL client authentication, the handshake needs to be
> reinitiated, with client authentication enforced. In order to do that,
> CertificatesValve needs access to the SSLSocket, in order to call its
> startHandshake() method.
>
> If the only purpose of CertificatesValve is to support the deprecated
> Http11Connector, which component is going to replace it and implement SSL
> handshake renegotiation?
>

SSLAuthenticator makes a request for a special Request attribute
("org.apache.coyote.request.X509Certificate"), which fires off an Action
hook (ACTION_REQ_SSL_CERTIFICATE) to renegotiate the handshake if necessary.

I changed TC 5 a little while back to do a lazy-evaluation of the SSL
attributes.  If you are seeing problems, that might be where.

>
> Jan
>
> -
> 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: [5.0] More dependencies

[Jean-Francois Arcand]

Remy Maucherat wrote:
Remy Maucherat wrote:

- daemon: Home of Mladen's procrun, a very promising exe wrapper for 
Java programs on Windows; this also contains a Unix wrapper for Java 
programs; the Unix wrapper could be advertised as "the" recommended 
solution to run Tomcat on 80 on Unix, and included as source with 
Tomcat's binary d/l; this component is currently in the sandbox, and 
would need to be either moved ASAP to commons proper, or be migrated 
to j-t-c (if thought to be too Tomcat specific to exist in the 
commons); a RM will be needed [Mladen, Jean-Frederic]


In this email, I forgot to speak about other commons (and others) 
dependencies. Thanks for all the volunteering, BTW, it really helps 
(damn day job ...) :)

commons-collection: No problem.

commons-beanutils: No problem.

commons-launcher: Problem; I think I did release 0.9 with Patrick Luby a 
long time ago, and the component has been dead since. Reviving it and 
putting a websiter up could help, but it's not certain. This piece of 
code was developed for the Sun web services pack 1.0 originally. Does 
anyone use it anymore ? Can it be removed (in favor of native wrappers) 
? I have to admit it was quite nice, so I'd rather not have to remove it.
Yes, jwsdp 1.2 is still using it. I also think we should keep it.

commons-digester: No problem.

commons-logging: No problem.

commons-pool: No problem.

JMX: I think we should try to ship with JMX 1.2 + a JSR 160 
implementation if possible. I really hope MX4J will be able to provide 
that.

Tyrex: This project seems dead (unfortunately) :-( We could replace it 
with some other TM, or (I like that one better) not provide an object 
factory implementation for UserTransaction by default, and let third 
parties provide it. That model seems to work great for J2EE providers 
(JOTM, OpenEJB, etc).

Struts: We need 1.1 ! (I think the rest of the world does also :-D)

Watchdog: (to the Sun folks) Where is Watchdog 5 (or whatever it's 
called) ?
I'm unaware of such packages (but I will double check).

-- Jeanfrancois


Remy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteRequest.java

[luehe]

luehe   2003/06/05 12:47:41

  Modified:catalina/src/share/org/apache/catalina Request.java
   catalina/src/share/org/apache/catalina/connector
RequestWrapper.java
   catalina/src/share/org/apache/coyote/tomcat5
CoyoteRequest.java
  Log:
  Undid previous changes
  
  Revision  ChangesPath
  1.5   +12 -4 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Request.java
  
  Index: Request.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Request.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- Request.java  5 Jun 2003 16:43:41 -   1.4
  +++ Request.java  5 Jun 2003 19:47:41 -   1.5
  @@ -204,6 +204,14 @@
   
   
   /**
  + * Set the Socket (if any) through which this Request was received.
  + *
  + * @param socket The socket through which this request was received
  + */
  +public void setSocket(Socket socket);
  +
  +
  +/**
* Return the input stream associated with this Request.
*/
   public InputStream getStream();
  
  
  
  1.3   +16 -4 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/RequestWrapper.java
  
  Index: RequestWrapper.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/RequestWrapper.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- RequestWrapper.java   5 Jun 2003 16:43:41 -   1.2
  +++ RequestWrapper.java   5 Jun 2003 19:47:41 -   1.3
  @@ -258,6 +258,18 @@
   
   
   /**
  + * Set the Socket (if any) through which this Request was received.
  + *
  + * @param socket The socket through which this request was received
  + */
  +public void setSocket(Socket socket) {
  +
  +request.setSocket(socket);
  +
  +}
  +
  +
  +/**
* Return the input stream associated with this Request.
*/
   public InputStream getStream() {
  
  
  
  1.7   +18 -5 
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java
  
  Index: CoyoteRequest.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- CoyoteRequest.java5 Jun 2003 16:43:41 -   1.6
  +++ CoyoteRequest.java5 Jun 2003 19:47:41 -   1.7
  @@ -633,7 +633,20 @@
* an SSLSocket.
*/
   public Socket getSocket() {
  -return coyoteRequest.getSocket();
  +return (socket);
  +}
  +
  +/**
  + * Set the Socket (if any) through which this Request was received.
  + *
  + * @param socket The socket through which this request was received
  + */
  +public void setSocket(Socket socket) {
  +this.socket = socket;
  +remoteHost = null;
  +remoteAddr = null;
  +remotePort = -1;
  +localAddr = null;
   }
   
   
  
  
  

-
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 Http11Processor.java

[luehe]

luehe   2003/06/05 12:46:49

  Modified:coyote/src/java/org/apache/coyote Request.java
   http11/src/java/org/apache/coyote/http11
Http11Processor.java
  Log:
  Undid previous changes
  
  Revision  ChangesPath
  1.22  +0 -20 
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Request.java
  
  Index: Request.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Request.java,v
  retrieving revision 1.21
  retrieving revision 1.22
  diff -u -r1.21 -r1.22
  --- Request.java  5 Jun 2003 16:42:48 -   1.21
  +++ Request.java  5 Jun 2003 19:46:49 -   1.22
  @@ -62,7 +62,6 @@
   
   import java.io.IOException;
   import java.util.Hashtable;
  -import java.net.Socket;
   
   import org.apache.tomcat.util.buf.ByteChunk;
   import org.apache.tomcat.util.buf.MessageBytes;
  @@ -138,8 +137,6 @@
   
   private int remotePort;
   
  -private Socket socket;
  -
   private MessageBytes schemeMB = new MessageBytes();
   
   private MessageBytes methodMB = new MessageBytes();
  @@ -307,23 +304,6 @@
   this.remotePort = port;
   }
   
  -/**
  - * Sets the socket through which this request was received.
  - *
  - * @param socket The socket through which this request was received
  - */
  -public void setSocket(Socket socket) {
  - this.socket = socket;
  -}
  -
  -/**
  - * Gets the socket through which this request was received.
  - *
  - * @return The socket through which this request was received
  - */
  -public Socket getSocket() {
  - return socket;
  -}
   
   //  encoding/type 
   
  
  
  
  1.67  +0 -1  
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java
  
  Index: Http11Processor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java,v
  retrieving revision 1.66
  retrieving revision 1.67
  diff -u -r1.66 -r1.67
  --- Http11Processor.java  5 Jun 2003 16:42:48 -   1.66
  +++ Http11Processor.java  5 Jun 2003 19:46:49 -   1.67
  @@ -517,7 +517,6 @@
   public void setSocket(Socket socket)
   throws IOException {
   this.socket = socket;
  - this.request.setSocket(socket);
   }
   
   /**
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[5.0] More dependencies

[Remy Maucherat]

Remy Maucherat wrote:
- daemon: Home of Mladen's procrun, a very promising exe wrapper for 
Java programs on Windows; this also contains a Unix wrapper for Java 
programs; the Unix wrapper could be advertised as "the" recommended 
solution to run Tomcat on 80 on Unix, and included as source with 
Tomcat's binary d/l; this component is currently in the sandbox, and 
would need to be either moved ASAP to commons proper, or be migrated to 
j-t-c (if thought to be too Tomcat specific to exist in the commons); a 
RM will be needed [Mladen, Jean-Frederic]
In this email, I forgot to speak about other commons (and others) 
dependencies. Thanks for all the volunteering, BTW, it really helps 
(damn day job ...) :)

commons-collection: No problem.

commons-beanutils: No problem.

commons-launcher: Problem; I think I did release 0.9 with Patrick Luby a 
long time ago, and the component has been dead since. Reviving it and 
putting a websiter up could help, but it's not certain. This piece of 
code was developed for the Sun web services pack 1.0 originally. Does 
anyone use it anymore ? Can it be removed (in favor of native wrappers) 
? I have to admit it was quite nice, so I'd rather not have to remove it.

commons-digester: No problem.

commons-logging: No problem.

commons-pool: No problem.

JMX: I think we should try to ship with JMX 1.2 + a JSR 160 
implementation if possible. I really hope MX4J will be able to provide that.

Tyrex: This project seems dead (unfortunately) :-( We could replace it 
with some other TM, or (I like that one better) not provide an object 
factory implementation for UserTransaction by default, and let third 
parties provide it. That model seems to work great for J2EE providers 
(JOTM, OpenEJB, etc).

Struts: We need 1.1 ! (I think the rest of the world does also :-D)

Watchdog: (to the Sun folks) Where is Watchdog 5 (or whatever it's called) ?

Remy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit:jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Http11Processor.javaHttp11Protocol.java

[Remy Maucherat]

Jan Luehe wrote:
Remy/Bill,


Ouch, that's one nasty hack.
-1, please revert it.
There are callbacks to the processor to evaluate the SSL related
attributes. If something is broken, this should be fixed, but using that
pattern. I believe get/setSocket are useless, and the calls should be
entierely removed.


I noticed the ActionHook calls to get SSL related attributes, however,
CertificatesValve needs the SSLSocket in order to renegotiate an SSL
handshake if the requested resource is from a webapp with this
authentication constraint:
   
  CLIENT-CERT
   
If the request was received through an SSL-enabled connector that does
not enforce SSL client authentication, the handshake needs to be
reinitiated, with client authentication enforced. In order to do that,
CertificatesValve needs access to the SSLSocket, in order to call its
startHandshake() method.
If the only purpose of CertificatesValve is to support the deprecated
Http11Connector, which component is going to replace it and implement SSL
handshake renegotiation?
Well, first of all, even if there's a bug or some missing feature, or 
anything, it's not a valid reason for adding a nasty hack. So please 
revert your patch.

It seems pretty clear to me that if you want to really implement that, 
you could add an additional callback (aka action), like the other SSL 
ones which are already there.
BTW, either there's client cert on the connector, or there isn't, right 
? This seems best left to the lower level of the container, rather than 
trying to be too smart (and since it will be hard to make it consistent 
between JK and HTTP/1.1, I'm close to being -1 for trying to implement 
it). And yes, if JK can't be implemented in a compliant way, then I 
believe that part of the specification is broken and should be fixed.

Remy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvscommit:jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Http11Processor.javaHttp11Protocol.java

[Jan Luehe]

Remy/Bill,

> Ouch, that's one nasty hack.
> -1, please revert it.
> 
> There are callbacks to the processor to evaluate the SSL related
> attributes. If something is broken, this should be fixed, but using that
> pattern. I believe get/setSocket are useless, and the calls should be
> entierely removed.

I noticed the ActionHook calls to get SSL related attributes, however,
CertificatesValve needs the SSLSocket in order to renegotiate an SSL
handshake if the requested resource is from a webapp with this
authentication constraint:

   
  CLIENT-CERT
   

If the request was received through an SSL-enabled connector that does
not enforce SSL client authentication, the handshake needs to be
reinitiated, with client authentication enforced. In order to do that,
CertificatesValve needs access to the SSLSocket, in order to call its
startHandshake() method.

If the only purpose of CertificatesValve is to support the deprecated
Http11Connector, which component is going to replace it and implement SSL
handshake renegotiation?


Jan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java Http11Protocol.java

[Bill Barker]

- Original Message -
From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, June 05, 2003 10:54 AM
Subject: Re: cvs commit:
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11
Http11Processor.java Http11Protocol.java


> Bill Barker wrote:
> > I'm very strongly -1 on this.  The o.a.coyote.Request should not have a
> > set/getSocket method for the simple reason that there is no reason that
> > Coyote should be assumed to be tied to a socket transport.
>
> I plan to test the memory only protocol handler someday. The Netbeans
> folks should be happy about that (and the auto reload everything, of
> course).
>
> > CertificatesValve doesn't do anything any more with Coyote.  It is only
left
> > around to support the deprecated Http11Connector.
>
> Well, the connector won't work with TC 5 anyway, so ...

I'm +1 for removing CertificatesValve from TC 5.  Especially since it is
tied to JSSE 1.0.x, so it will almost certainly break Tomcat running on a
non-Sun 1.4 JVM.

>
> Remy
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-catalina/webapps/docs setup.xml

[remm]

remm2003/06/05 11:28:49

  Added:   webapps/docs setup.xml
  Log:
  - Add placeholder page for the setup instructions.
  
  Revision  ChangesPath
  1.1  jakarta-tomcat-catalina/webapps/docs/setup.xml
  
  Index: setup.xml
  ===
  
  
  ]>
  
  
&project;
  

  Remy Maucherat
  Tomcat Setup

  
  
  

  
  
  

  
  
  
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-5 build.properties.default build.xml

[remm]

remm2003/06/05 11:28:07

  Modified:.build.properties.default build.xml
  Log:
  - Package the jsvc source code with Tomcat, for Unix users.
  
  Revision  ChangesPath
  1.93  +2 -1  jakarta-tomcat-5/build.properties.default
  
  Index: build.properties.default
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
  retrieving revision 1.92
  retrieving revision 1.93
  diff -u -r1.92 -r1.93
  --- build.properties.default  4 Jun 2003 18:14:26 -   1.92
  +++ build.properties.default  5 Jun 2003 18:28:07 -   1.93
  @@ -76,6 +76,7 @@
   commons-daemon.procrun.home=${commons-daemon.lib}/bin
   commons-daemon.procrun.exe=${commons-daemon.procrun.home}/tomcat.exe
   commons-daemon.procrunw.exe=${commons-daemon.procrun.home}/tomcatw.exe
  +commons-daemon.jsvc.tar.gz=${commons-daemon.lib}/bin/jsvc.tar.gz
   
   
   # - Commons Digester, version 1.4 or later -
  
  
  
  1.130 +6 -1  jakarta-tomcat-5/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
  retrieving revision 1.129
  retrieving revision 1.130
  diff -u -r1.129 -r1.130
  --- build.xml 3 Jun 2003 21:38:52 -   1.129
  +++ build.xml 5 Jun 2003 18:28:07 -   1.130
  @@ -151,6 +151,8 @@
   
   
   
  +
  +
   
 
   
  @@ -814,7 +816,6 @@
   
 
   
  -
   Target: Modeler - Dist ...
   
   
  @@ -848,6 +849,10 @@
   
 
   
  +
  +
  +
   
   Target: Webapps precompilation ...
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20518] - JNDIRealm not retrying primary LDAP server after failed attempt against alternate server.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=20518

JNDIRealm not retrying primary LDAP server after failed attempt against alternate 
server.





--- Additional Comments From [EMAIL PROTECTED]  2003-06-05 18:14 ---
Created an attachment (id=6652)
Removes the "connectionAttempt" reset to a "finally" block.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20518] New: - JNDIRealm not retrying primary LDAP server after failed attempt against alternate server.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=20518

JNDIRealm not retrying primary LDAP server after failed attempt against alternate 
server.

   Summary: JNDIRealm not retrying primary LDAP server after failed
attempt against alternate server.
   Product: Tomcat 4
   Version: 4.1.24
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


After a failed attempt at connecting to the configured "alternateURL", 
JNDIRealm will not reattempt connecting to the "connectionURL" until after 
Tomcat is restarted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20517] New: - Adding recursive find for library references

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=20517

Adding recursive find for library references

   Summary: Adding recursive find for library references
   Product: Tomcat 4
   Version: 4.1.25
  Platform: All
OS/Version: All
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


regarding the Catalina class loader and how it searches for libraries to load
classes from:

It would be nice if .jar files under the $CATALINA_HOME/shared/lib (and, for
that matter, an application's WEB-INF/lib) directories could be grouped into
subdirectories.  

For instance, when using several frameworks, these directories can get quite
cluttered.  It would be nice to have something like the following:
$CATALINA_HOME/shared/lib/
  hibernate-vx.y/
  
  struts-vx.y/
  

dig?  I looked thru the servlet spec and it doesn't speak to how a container
manages it's shared/common libraries (and there isn't any verbage to discuss the
structure of a WEB-INF/lib directory either...)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20516] New: - Jasper2 compilation not JSP 2.0 compliant on J2SE 1.4

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=20516

Jasper2 compilation not JSP 2.0 compliant on J2SE 1.4

   Summary: Jasper2 compilation not JSP 2.0 compliant on J2SE 1.4
   Product: Tomcat 5
   Version: 5.0.2
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


According to the JSP 2.0 specification, Section 11.5 - Debugging Requirements:
"Full runtime support for JSR-45 (as opposed to only generating the SMAPs that 
are used at runtime) is only required when the JSP container is running in a 
J2SE 1.4 or greater environment."

While Jasper2 correctly generates SMAP's during JSP compilation, when running 
in a J2SE 1.4 environment, the SMAP is not properly stored in the resulting 
class file as required by the JSP 2.0 & JSR-45 specifications.

Following is a full description of the issue.  It is effectively a duplicate of 
an email I posted to the tomcat-dev mailing list, to which there was no 
response.

We're working to support source-level JSP debugging for Tomcat 5 using its JSR-
045 support.  However,we've been unsuccessful at getting this to work because 
the line to code index map that we retrieve from our SourceDebugExtension JDWP 
request does not agree with the  SMAP that was generated when my example JSP 
was compiled.  The SMAP appears to be correct but for whatever reason the line
mapping returned from the JVM has little in common with the SMAP.  

We've already gotten our debugging implementation working properly with 
WebLogic 7.0 and 8.1 so I have a high degree of confidence that once this 
mapping issue is resolved we'll also have a source-level JSP debugging
solution for Tomcat 5 also. 

Here are the details of our test environment:
Platform: Window 2000, latest SP
JDK: 1.4.1_02-b06
Tomcat: Version 5.0.2 (alpha)
Tomcat 5 JSP servlet settings from web.xml:

jsp
org.apache.jasper.servlet.JspServlet

logVerbosityLevel
WARNING


classdebuginfo
true


suppressSmap
false


dumpSmap
true


development
true

3




For the test, we attempt to set a breakpoint on line 18, which
according to the SMAP corresponds to line 62 of the servlet.
Here's the test JSP, with line numbers for convenience.
1  
2  <%@ page language="java" import="java.lang.*,java.util.*" %>
3  <%
4  String path = request.getContextPath();
5  String basePath =
"http://"+request.getServerName()+":"+request.getServerPort()+path+"/";
6  %>
7  
8   
9  
10  My JSP 'TestJSP.jsp' starting page
11 
12
13 
14 <%
15Date date = new Date();
16out.println("Current time is: " + date);
17  out.println(".  ");
18  date = new Date();
19  out.println("Now the time is " + date);
20  out.println(".  ");
21  %>
22  This is my test JSP page. 
23  
24  


Here's the SMAP generated by Tomcat:
SMAP
C:\dev\ApacheGroup\Tomcat
5.0.2alpha\work\Catalina\localhost\TomcatTest\org\apache\jsp\TomcatTestJSP_j
sp.java
JSP
*S JSP
*F
+ 0 TomcatTestJSP.jsp
/TomcatTestJSP.jsp
*L
1:42
4,3:45
7:49
8:50
9:51
9:52
9:53
10:54
10:55
11:56
13:57
15,7:59
22:67
22:68
23:69
24:70
*E


Here's the generated servlet.  As you can see,
line 62 is correct for the breakpont request from
line 18 of the JSP file.
1 package org.apache.jsp;
2
3 import javax.servlet.*;
4 import javax.servlet.http.*;
5 import javax.servlet.jsp.*;
6 import java.lang.*;
7 import java.util.*;
8
9 public final class TomcatTestJSP_jsp extends
org.apache.jasper.runtime.HttpJspBase
10implements org.apache.jasper.runtime.JspSourceDependent {
11
12  private static java.util.Vector _jspx_dependants;
13
14  public java.util.List getDependants() {
15return _jspx_dependants;
16  }
17
18  public void _jspService(HttpServletRequest request,
HttpServletResponse response)
19throws java.io.IOException, ServletException {
20
21JspFactory _jspxFactory = null;
22PageContext pageContext = null;
23HttpSession session = null;
24ServletContext application = null;
25ServletConfig config = null;
26JspWriter out = null;
27Object page = this;
28JspWriter _jspx_out = null;
29
30
31try {
32  _jspxFactory = JspFactory.getDefaultFactory();
33  response.setContentType("te

Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Http11Processor.java Http11Protocol.java

[Remy Maucherat]

Bill Barker wrote:
I'm very strongly -1 on this.  The o.a.coyote.Request should not have a
set/getSocket method for the simple reason that there is no reason that
Coyote should be assumed to be tied to a socket transport.
I plan to test the memory only protocol handler someday. The Netbeans 
folks should be happy about that (and the auto reload everything, of 
course).

CertificatesValve doesn't do anything any more with Coyote.  It is only left
around to support the deprecated Http11Connector.
Well, the connector won't work with TC 5 anyway, so ...

Remy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Http11Processor.java Http11Protocol.java

[Remy Maucherat]

[EMAIL PROTECTED] wrote:
luehe   2003/06/05 09:42:48

  Modified:coyote/src/java/org/apache/coyote Request.java
   http11/src/java/org/apache/coyote/http11
Http11Processor.java Http11Protocol.java
  Log:
  Removed setSocket() method from org.apache.catalina.Request, since it
  was never called in any of the classes implementing this interface.
  
  For example, setSocket() was never called on
  org.apache.coyote.tomcat5.CoyoteRequest, causing its getSocket()
  method to always return null, which broke the CertificatesValve, which
  relies on having access to the (SSL)Socket so that it can reinitiate a
  handshake if necessary.
  
  Instead, added setSocket() and getSocket() methods on org.apache.coyote.Request:
  
  - setSocket() is called as part of
org.apache.coyote.http11.Http11Processor.setSocket(), as follows:
  
  public void setSocket(Socket socket)
  throws IOException {
  this.socket = socket;
  this.request.setSocket(socket); // NEW
  }
  
  - getSocket() is called as part of
org.apache.coyote.tomcat5.CoyoteRequest.getSocket(), as follows:
Ouch, that's one nasty hack.
-1, please revert it.
There are callbacks to the processor to evaluate the SSL related 
attributes. If something is broken, this should be fixed, but using that 
pattern. I believe get/setSocket are useless, and the calls should be 
entierely removed.

Remy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java Http11Protocol.java

[Bill Barker]

I'm very strongly -1 on this.  The o.a.coyote.Request should not have a
set/getSocket method for the simple reason that there is no reason that
Coyote should be assumed to be tied to a socket transport.

CertificatesValve doesn't do anything any more with Coyote.  It is only left
around to support the deprecated Http11Connector.

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 05, 2003 9:42 AM
Subject: cvs commit:
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11
Http11Processor.java Http11Protocol.java


> luehe   2003/06/05 09:42:48
>
>   Modified:coyote/src/java/org/apache/coyote Request.java
>http11/src/java/org/apache/coyote/http11
> Http11Processor.java Http11Protocol.java
>   Log:
>   Removed setSocket() method from org.apache.catalina.Request, since it
>   was never called in any of the classes implementing this interface.
>
>   For example, setSocket() was never called on
>   org.apache.coyote.tomcat5.CoyoteRequest, causing its getSocket()
>   method to always return null, which broke the CertificatesValve, which
>   relies on having access to the (SSL)Socket so that it can reinitiate a
>   handshake if necessary.
>
>   Instead, added setSocket() and getSocket() methods on
org.apache.coyote.Request:
>
>   - setSocket() is called as part of
> org.apache.coyote.http11.Http11Processor.setSocket(), as follows:
>
>   public void setSocket(Socket socket)
>   throws IOException {
>   this.socket = socket;
>   this.request.setSocket(socket); // NEW
>   }
>
>   - getSocket() is called as part of
> org.apache.coyote.tomcat5.CoyoteRequest.getSocket(), as follows:
>
>   diff -u -r1.5 CoyoteRequest.java
>   --- CoyoteRequest.java  31 May 2003 15:00:25 -  1.5
>   +++ CoyoteRequest.java  5 Jun 2003 16:41:17 -
>   @@ -633,20 +633,7 @@
> * an SSLSocket.
> */
>public Socket getSocket() {
>   -return (socket);
>   -}
>   -
>   -/**
>   - * Set the Socket (if any) through which this Request was received.
>   - *
>   - * @param socket The socket through which this request was received
>   - */
>   -public void setSocket(Socket socket) {
>   -this.socket = socket;
>   -remoteHost = null;
>   -remoteAddr = null;
>   -remotePort = -1;
>   -localAddr = null;
>   +return coyoteRequest.getSocket();
>}
>
>   Revision  ChangesPath
>   1.21  +20 -0
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Request.java
>
>   Index: Request.java
>   ===
>   RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Reques
t.java,v
>   retrieving revision 1.20
>   retrieving revision 1.21
>   diff -u -r1.20 -r1.21
>   --- Request.java 23 Mar 2003 08:57:48 - 1.20
>   +++ Request.java 5 Jun 2003 16:42:48 - 1.21
>   @@ -62,6 +62,7 @@
>
>import java.io.IOException;
>import java.util.Hashtable;
>   +import java.net.Socket;
>
>import org.apache.tomcat.util.buf.ByteChunk;
>import org.apache.tomcat.util.buf.MessageBytes;
>   @@ -137,6 +138,8 @@
>
>private int remotePort;
>
>   +private Socket socket;
>   +
>private MessageBytes schemeMB = new MessageBytes();
>
>private MessageBytes methodMB = new MessageBytes();
>   @@ -304,6 +307,23 @@
>this.remotePort = port;
>}
>
>   +/**
>   + * Sets the socket through which this request was received.
>   + *
>   + * @param socket The socket through which this request was received
>   + */
>   +public void setSocket(Socket socket) {
>   + this.socket = socket;
>   +}
>   +
>   +/**
>   + * Gets the socket through which this request was received.
>   + *
>   + * @return The socket through which this request was received
>   + */
>   +public Socket getSocket() {
>   + return socket;
>   +}
>
>//  encoding/type 
>
>
>
>
>   1.66  +1 -0
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Pro
cessor.java
>
>   Index: Http11Processor.java
>   ===
>   RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11
/Http11Processor.java,v
>   retrieving revision 1.65
>   retrieving revision 1.66
>   diff -u -r1.65 -r1.66
>   --- Http11Processor.java 13 May 2003 22:45:58 - 1.65
>   +++ Http11Processor.java 5 Jun 2003 16:42:48 - 1.66
>   @@ -517,6 +517,7 @@
>public void setSocket(Socket socket)
>throws IOException {
>this.socket = socket;
>   + this.request.setSocket(socket);
>}
>
>/**
>
>
>
>   1.27  +6 -5
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Pro
tocol.java
>

DO NOT REPLY [Bug 20542] - Stream closed error

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=20542

Stream closed error

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-06-06 10:48 ---
Please use tomcat-user to debug this issue.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 7831] - [PATCH] JNDIRealm does not work with CLIENT-CERT auth method

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=7831

[PATCH] JNDIRealm does not work with CLIENT-CERT auth method





--- Additional Comments From [EMAIL PROTECTED]  2003-06-06 10:14 ---
For me it seems that this moule has no maitainer right now, so it is leaved "as 
is" and no is interested in this. Does aonybody knows who should we contact to 
put his changes to CVS.
Acctually in "contribution" part of Jakarta it is said that you can make patch 
but no way who should I contact - leave this patch on bugzilla maybe someone 
will pick it up.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteRequest.java

[luehe]

luehe   2003/06/05 09:43:42

  Modified:catalina/src/share/org/apache/catalina Request.java
   catalina/src/share/org/apache/catalina/connector
RequestWrapper.java
   catalina/src/share/org/apache/coyote/tomcat5
CoyoteRequest.java
  Log:
  Removed setSocket() method from org.apache.catalina.Request, since it
  was never called in any of the classes implementing this interface.
  
  For example, setSocket() was never called on
  org.apache.coyote.tomcat5.CoyoteRequest, causing its getSocket()
  method to always return null, which broke the CertificatesValve, which
  relies on having access to the (SSL)Socket so that it can reinitiate a
  handshake if necessary.
  
  Instead, added setSocket() and getSocket() methods on org.apache.coyote.Request:
  
  - setSocket() is called as part of
org.apache.coyote.http11.Http11Processor.setSocket(), as follows:
  
  public void setSocket(Socket socket)
  throws IOException {
  this.socket = socket;
  this.request.setSocket(socket); // NEW
  }
  
  - getSocket() is called as part of
org.apache.coyote.tomcat5.CoyoteRequest.getSocket(), as follows:
  
  diff -u -r1.5 CoyoteRequest.java
  --- CoyoteRequest.java  31 May 2003 15:00:25 -  1.5
  +++ CoyoteRequest.java  5 Jun 2003 16:41:17 -
  @@ -633,20 +633,7 @@
* an SSLSocket.
*/
   public Socket getSocket() {
  -return (socket);
  -}
  -
  -/**
  - * Set the Socket (if any) through which this Request was received.
  - *
  - * @param socket The socket through which this request was received
  - */
  -public void setSocket(Socket socket) {
  -this.socket = socket;
  -remoteHost = null;
  -remoteAddr = null;
  -remotePort = -1;
  -localAddr = null;
  +return coyoteRequest.getSocket();
   }
  
  Revision  ChangesPath
  1.4   +4 -12 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Request.java
  
  Index: Request.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Request.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- Request.java  28 Jan 2003 18:20:05 -  1.3
  +++ Request.java  5 Jun 2003 16:43:41 -   1.4
  @@ -204,14 +204,6 @@
   
   
   /**
  - * Set the Socket (if any) through which this Request was received.
  - *
  - * @param socket The socket through which this request was received
  - */
  -public void setSocket(Socket socket);
  -
  -
  -/**
* Return the input stream associated with this Request.
*/
   public InputStream getStream();
  
  
  
  1.2   +4 -16 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/RequestWrapper.java
  
  Index: RequestWrapper.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/RequestWrapper.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- RequestWrapper.java   18 Jul 2002 16:47:57 -  1.1
  +++ RequestWrapper.java   5 Jun 2003 16:43:41 -   1.2
  @@ -258,18 +258,6 @@
   
   
   /**
  - * Set the Socket (if any) through which this Request was received.
  - *
  - * @param socket The socket through which this request was received
  - */
  -public void setSocket(Socket socket) {
  -
  -request.setSocket(socket);
  -
  -}
  -
  -
  -/**
* Return the input stream associated with this Request.
*/
   public InputStream getStream() {
  
  
  
  1.6   +5 -18 
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java
  
  Index: CoyoteRequest.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- CoyoteRequest.java31 May 2003 15:00:25 -  1.5
  +++ CoyoteRequest.java5 Jun 2003 16:43:41 -   1.6
  @@ -633,20 +633,7 @@
* an SSLSocket.
*/
   public Socket getSocket() {
  -return (socket);
  -}
  -
  -/**
  - * Set the Socket (if any) through which this Request was received.
  - *
  - * @param socket The socket through which this request was received
  - */
  -public void setSocket(Socket socket) {
  -this.socket = socket;
  -remoteHost = null;
  -remoteAddr = null;
  -remotePort = -1;
  -localAddr = null;
  +return coyoteRequest.getSocket();
   }
   
   
  
  
  

cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java Http11Protocol.java

[luehe]

luehe   2003/06/05 09:42:48

  Modified:coyote/src/java/org/apache/coyote Request.java
   http11/src/java/org/apache/coyote/http11
Http11Processor.java Http11Protocol.java
  Log:
  Removed setSocket() method from org.apache.catalina.Request, since it
  was never called in any of the classes implementing this interface.
  
  For example, setSocket() was never called on
  org.apache.coyote.tomcat5.CoyoteRequest, causing its getSocket()
  method to always return null, which broke the CertificatesValve, which
  relies on having access to the (SSL)Socket so that it can reinitiate a
  handshake if necessary.
  
  Instead, added setSocket() and getSocket() methods on org.apache.coyote.Request:
  
  - setSocket() is called as part of
org.apache.coyote.http11.Http11Processor.setSocket(), as follows:
  
  public void setSocket(Socket socket)
  throws IOException {
  this.socket = socket;
  this.request.setSocket(socket); // NEW
  }
  
  - getSocket() is called as part of
org.apache.coyote.tomcat5.CoyoteRequest.getSocket(), as follows:
  
  diff -u -r1.5 CoyoteRequest.java
  --- CoyoteRequest.java  31 May 2003 15:00:25 -  1.5
  +++ CoyoteRequest.java  5 Jun 2003 16:41:17 -
  @@ -633,20 +633,7 @@
* an SSLSocket.
*/
   public Socket getSocket() {
  -return (socket);
  -}
  -
  -/**
  - * Set the Socket (if any) through which this Request was received.
  - *
  - * @param socket The socket through which this request was received
  - */
  -public void setSocket(Socket socket) {
  -this.socket = socket;
  -remoteHost = null;
  -remoteAddr = null;
  -remotePort = -1;
  -localAddr = null;
  +return coyoteRequest.getSocket();
   }
  
  Revision  ChangesPath
  1.21  +20 -0 
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Request.java
  
  Index: Request.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Request.java,v
  retrieving revision 1.20
  retrieving revision 1.21
  diff -u -r1.20 -r1.21
  --- Request.java  23 Mar 2003 08:57:48 -  1.20
  +++ Request.java  5 Jun 2003 16:42:48 -   1.21
  @@ -62,6 +62,7 @@
   
   import java.io.IOException;
   import java.util.Hashtable;
  +import java.net.Socket;
   
   import org.apache.tomcat.util.buf.ByteChunk;
   import org.apache.tomcat.util.buf.MessageBytes;
  @@ -137,6 +138,8 @@
   
   private int remotePort;
   
  +private Socket socket;
  +
   private MessageBytes schemeMB = new MessageBytes();
   
   private MessageBytes methodMB = new MessageBytes();
  @@ -304,6 +307,23 @@
   this.remotePort = port;
   }
   
  +/**
  + * Sets the socket through which this request was received.
  + *
  + * @param socket The socket through which this request was received
  + */
  +public void setSocket(Socket socket) {
  + this.socket = socket;
  +}
  +
  +/**
  + * Gets the socket through which this request was received.
  + *
  + * @return The socket through which this request was received
  + */
  +public Socket getSocket() {
  + return socket;
  +}
   
   //  encoding/type 
   
  
  
  
  1.66  +1 -0  
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java
  
  Index: Http11Processor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java,v
  retrieving revision 1.65
  retrieving revision 1.66
  diff -u -r1.65 -r1.66
  --- Http11Processor.java  13 May 2003 22:45:58 -  1.65
  +++ Http11Processor.java  5 Jun 2003 16:42:48 -   1.66
  @@ -517,6 +517,7 @@
   public void setSocket(Socket socket)
   throws IOException {
   this.socket = socket;
  + this.request.setSocket(socket);
   }
   
   /**
  
  
  
  1.27  +6 -5  
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Protocol.java
  
  Index: Http11Protocol.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Protocol.java,v
  retrieving revision 1.26
  retrieving revision 1.27
  diff -u -r1.26 -r1.27
  --- Http11Protocol.java   22 May 2003 04:51:03 -  1.26
  +++ Http11Protocol.java   5 Jun 2003 16:42:48 -   1.27
  @@ -86,8 +86,8 @@
*/
   public class Http11Protocol implements ProtocolHandler, MBeanRegistration
   {
  -
   public Http11Protocol() {
  + cHandler = new Http11ConnectionHandler( this );
   setSoLinger(Constants.DEFAULT_CONNECTION_LIN

Re: mod_jk 1.2.4 release Monday 6/9

[jean-frederic clere]

Jess M. Holle wrote:
Without diffing the sources, can you point out whether this is solely in 
the build machinery or also involved a source code change?
+++
Index: configure.in
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/configure.in,v
  retrieving revision 1.23
  retrieving revision 1.24
  diff -u -r1.23 -r1.24
  --- configure.in  27 May 2003 13:04:46 -  1.23
  +++ configure.in  5 Jun 2003 09:15:37 -   1.24
  @@ -103,6 +103,7 @@
APXSCFLAGS="`${APXS} -q CFLAGS` `${APXS} -q EXTRA_CFLAGS`"
APXSCPPFLAGS="`${APXS} -q EXTRA_CPPFLAGS`"
   APACHE_CONFIG_VARS=${apache_dir}/build/config_vars.mk
  +LIBTOOL=`$APXS -q LIBTOOL`
   fi
   AC_MSG_RESULT([building connector for \"$WEBSERVER\"])
+++
Only a build problem.
Glenn Nielsen wrote:

A bug was reported with the linux build with Apache 2.0.46 with libtool.
This has been fixed and an updated mod_jk 1.2.4 source distribution 
for testing
is available at:

http://cvs.apache.org/~glenn/jakarta-tomcat-connectors-jk-1.2.4-src.tar.gz 

Thanks Henri and JF for taking care of this.

Glenn

Glenn Nielsen wrote:

So far there have been no problems reported with mod_jk 1.2.4 except for
one minor documentation typo which has been fixed.
If I don't see any problems reported from further testing before Monday
I will make the mod_jk 1.2.4 source release and announcement.
Thanks for all the help testing.

Once the release is announced binaries can be and installed in
the release directory.
Regards,

Glenn



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[GUMP] Build timed out - jk

[Craig McClanahan]

This email is autogenerated from the output from:



Buildfile: build.xml

init:
 [echo] /home/rubys
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-connectors/jk/build/jk
 [echo] linux=true solaris=${solaris} win32=${win32} hpux=${hpux} 
netware=${netware}

apache20:

apache13:

iis:

netscape:

jni:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-connectors/jk/build/jk/jni
   [so] Compiling 4 out of 4
Compiling /home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/common/jk_map.c
Compiling /home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/common/jk_pool.c
Compiling /home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/common/jk_util.c
Compiling /home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/jni/jk_jnicb.c
Linking /home/rubys/jakarta/jakarta-tomcat-connectors/jk/build/jk/jni/jni_connect.so
/home/rubys/bin/timeout: timed out

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20542] New: - Stream closed error

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=20542

Stream closed error

   Summary: Stream closed error
   Product: Tomcat 4
   Version: 4.1.24
  Platform: HP
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have an application that is using the TOMCAT 4.1.24, and is using JSP's. The 
average of users connected simultaneously to this application is around 70. The 
log level of the TOMCAT is on ERROR level. The problem is that at the end of 
the day the log is full with this error message:

2003-06-06 02:08:39 StandardWrapperValve[jsp]: Servlet.service() for servlet 
jsp threw exception
org.apache.jasper.JasperException: Stream closed
at org.apache.jasper.servlet.JspServletWrapper.service
(JspServletWrapper.java:254)
at org.apache.jasper.servlet.JspServlet.serviceJspFile
(JspServlet.java:295)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:247)
at org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:256)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:191)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContext.invoke
(StandardContext.java:2415)
at org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:180)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke
(ErrorDispatcherValve.java:171)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:641)
at org.apache.catalina.valves.ErrorReportValve.invoke
(ErrorReportValve.java:172)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardEngineValve.invoke
(StandardEngineValve.java:174)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.coyote.tomcat4.CoyoteAdapter.service
(CoyoteAdapter.java:223)
at org.apache.coyote.http11.Http11Processor.process
(Http11Processor.java:594)
at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnectio
n(Http11Protocol.java:392)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt
(PoolTcpEndpoint.java:565)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
(ThreadPool.java:619)
at java.lang.Thread.run(Thread.java:536)

I could not identify a problem in our application, so I think that the problem 
might be in the TOMCAT engine. It is really noisy that at the end of the day to 
have a log file (localhost_log.*.txt) of almost 1Gb size. The frequency of this 
bug in the log is very high (sometimes there are 10 entries per second for this 
bug). On the discussion boards I found that this error is associated with the 
fact that the generated HTML file is closed before it was completely loaded. 
Maybe an explanation is that our application is using multiple frames in the 
JSP pages, and that's why there are so many occurrences per second, but I doubt 
that a user is closing a file at every second, in order to obtain this 
frequency of the error in the logs.

---

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteRequest.java

[Bill Barker]

- Original Message -
From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, June 05, 2003 11:49 PM
Subject: Re: cvs commit:
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5
CoyoteRequest.java


> Bill Barker wrote:
> >>I'm -1 on this patch unless you can explain what the bug exactly was,
> >>and how the recycling couldn't properly reset the facade.
> >
> > I'm not really happy with the patch either.  I'll postpone adding my
(since
> > it's the second, binding) -1 until you provide a better explaination.
>
> Well, I have no idea what the bug report mentioned looks like, so I
> can't provide a real evaluation. However, what I'm now pretty sure about
> is that the patch is possibly unsafe.
>
> Note: AFAIK, one -1 is enough.

I've had plenty of solo -1s ignored :).  I understood the rule as "more -1
than +1 with the committer assumed to +1".  Then, again, I'm not big on
rules, and that's for the PMC to work out anyway ;-).

Reading Remy's comments, I'm giving my official -1 (so, even with my
interpretation, this must be reverted unless you can convince someone to
change their Vote).

>
> Remy
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_jk 1.2.4 release Monday 6/9

[Jess M. Holle]

Without diffing the sources, can you point out whether this is solely in 
the build machinery or also involved a source code change?

Glenn Nielsen wrote:

A bug was reported with the linux build with Apache 2.0.46 with libtool.
This has been fixed and an updated mod_jk 1.2.4 source distribution 
for testing
is available at:

http://cvs.apache.org/~glenn/jakarta-tomcat-connectors-jk-1.2.4-src.tar.gz

Thanks Henri and JF for taking care of this.

Glenn

Glenn Nielsen wrote:

So far there have been no problems reported with mod_jk 1.2.4 except for
one minor documentation typo which has been fixed.
If I don't see any problems reported from further testing before Monday
I will make the mod_jk 1.2.4 source release and announcement.
Thanks for all the help testing.

Once the release is announced binaries can be and installed in
the release directory.
Regards,

Glenn



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 7831] - [PATCH] JNDIRealm does not work with CLIENT-CERT auth method

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=7831

[PATCH] JNDIRealm does not work with CLIENT-CERT auth method





--- Additional Comments From [EMAIL PROTECTED]  2003-06-06 07:09 ---
Realm Configuration for Attachment#2

ldap://server:389";
userBase="CN=Users,dc=company,dc=hq"
certSearch="(altSecurityIdentities={0})"
certUserName="sAMAccountName"
userSearch="(sAMAccountName={0})"
userRoleName="member"
roleBase="CN=Users,dc=company,dc=hq"
roleName="cn"
roleSearch="(member={0})"
connectionName="CN=tomcat,CN=Users,DC=company,DC=hq"
connectionPassword="***"
roleSubtree="true"
userSubtree="true" />

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 7831] - [PATCH] JNDIRealm does not work with CLIENT-CERT auth method

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=7831

[PATCH] JNDIRealm does not work with CLIENT-CERT auth method





--- Additional Comments From [EMAIL PROTECTED]  2003-06-06 07:07 ---
Created an attachment (id=)
Discussion base for a common solution on how to authenticate clients certificates

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20540] New: - Unable to compile the JSP files

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=20540

Unable to compile the JSP files

   Summary: Unable to compile the JSP files
   Product: Tomcat 4
   Version: 4.1.24
  Platform: HP
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have an application which is running on TOMCAT 4.1.24, using j2sdk1.4.1. The 
application consist in a taglib and JSP files. I just migrate the aplication 
from TOMCAT 4.0.6 to TOMCAT 4.1.24, and since then I caught this strange 
behaviour 3 times: after starting the TOMCAT, some JSP files could not be 
compiled, only a blank page was loaded instead of the expected page. Also 
looking in the TOMCAT cache folder (WORK), I noticed that only the *.java file 
was created. In the log file I found the following error, which I think is 
related to the behaviour described previously:

Compile failed; see the compiler error output for details.
at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:842)
at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:682)
at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:317)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:370)
at org.apache.jasper.JspCompilationContext.compile
(JspCompilationContext.java:473)
at org.apache.jasper.servlet.JspServletWrapper.service
(JspServletWrapper.java:190)
at org.apache.jasper.servlet.JspServlet.serviceJspFile
(JspServlet.java:295)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:247)
at org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:256)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:191)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContext.invoke
(StandardContext.java:2415)
at org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:180)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke
(ErrorDispatcherValve.java:171)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:641)
at org.apache.catalina.valves.ErrorReportValve.invoke
(ErrorReportValve.java:172)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardEngineValve.invoke
(StandardEngineValve.java:174)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.coyote.tomcat4.CoyoteAdapter.service
(CoyoteAdapter.java:223)
at org.apache.coyote.http11.Http11Processor.process
(Http11Processor.java:594)
at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnectio
n(Http11Protocol.java:392)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt
(PoolTcpEndpoint.java:565)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
(ThreadPool.java:619)
at java.lang.Thread.run(Thread.java:536)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTEC