DO NOT REPLY [Bug 39850] - Need a way to invalidate SSL-session from web application

[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://issues.apache.org/bugzilla/show_bug.cgi?id=39850


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |




--- Additional Comments From [EMAIL PROTECTED]  2007-03-28 01:03 ---
The forum exactly illustrates the point I am trying to make. The existing
SSL-session will let the user (or worse, some other user) back in to the
application without really loging in. The only way to prevent this is by closing
all browser windows which will clear the SSL cache on the client side. But of
course we can't expect our users to close all browser windows every time they
log off.

A possible solution is to invalidate the SSL-session on the server side. The
SSL-stack provides methods to find a particular SSL-session and invalidate it.
The problem is that you can't find the right SSLContext from a web application.
I agree that there is no Servlet Specification that specifies this but it would
be nice if Tomcat could solve this problem. The best way to do this would be
invalidating the SSL-session when the HTTP-session is invalidated. That would
make it transparent to the application developer and does not require a
proprietary extension on the Servlet API.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 39850] - Need a way to invalidate SSL-session from web application

[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://issues.apache.org/bugzilla/show_bug.cgi?id=39850





--- Additional Comments From [EMAIL PROTECTED]  2007-03-28 01:08 ---
We are also experiencing same problem. This makes client SSL authentication
unreliable and really unusable in enterprise applications. It would be very nice
if Tomcat could solve this problem.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 41964] New: - missing links on the examples application.

[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://issues.apache.org/bugzilla/show_bug.cgi?id=41964

   Summary: missing links on the examples application.
   Product: Tomcat 6
   Version: 6.0.10
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Hi,

I found missing links on the examples application.
It's because jsp-examples and servlet-examples were moved to under the examples.

Here is a patch.

Index:
C:/eclipse_workspaces/tomcat_trunk/tomcat6/webapps/examples/WEB-INF/classes/servletToJsp.java
===
---
C:/eclipse_workspaces/tomcat_trunk/tomcat6/webapps/examples/WEB-INF/classes/servletToJsp.java
(revision 522964)
+++
C:/eclipse_workspaces/tomcat_trunk/tomcat6/webapps/examples/WEB-INF/classes/servletToJsp.java
(working copy)
@@ -24,7 +24,7 @@
try {
// Set the attribute and Forward to hello.jsp
request.setAttribute ("servletName", "servletToJsp");
-  
getServletConfig().getServletContext().getRequestDispatcher("/jsptoserv/hello.jsp").forward(request,
response);
+  
getServletConfig().getServletContext().getRequestDispatcher("/jsp/jsptoserv/hello.jsp").forward(request,
response);
} catch (Exception ex) {
ex.printStackTrace ();
}
Index:
C:/eclipse_workspaces/tomcat_trunk/tomcat6/webapps/examples/jsp/include/include.jsp
===
---
C:/eclipse_workspaces/tomcat_trunk/tomcat6/webapps/examples/jsp/include/include.jsp
(revision 522964)
+++
C:/eclipse_workspaces/tomcat_trunk/tomcat6/webapps/examples/jsp/include/include.jsp
(working copy)
@@ -26,7 +26,7 @@
 
 <%@ include file="foo.jsp" %>
 
-  by including the
output of another JSP:
+  by including the output of
another JSP:
 
 
 
Index: 
C:/eclipse_workspaces/tomcat_trunk/tomcat6/webapps/examples/jsp/error/err.jsp
===
---
C:/eclipse_workspaces/tomcat_trunk/tomcat6/webapps/examples/jsp/error/err.jsp
(revision 522964)
+++
C:/eclipse_workspaces/tomcat_trunk/tomcat6/webapps/examples/jsp/error/err.jsp
(working copy)
@@ -24,7 +24,7 @@
 
if (request.getParameter("name") == null) {
%>
-   <%@ include file="/error/error.html" %>
+   <%@ include file="error.html" %>
<%
} else {
  foo.setName(request.getParameter("name"));
Index:
C:/eclipse_workspaces/tomcat_trunk/tomcat6/webapps/examples/jsp/forward/forward.jsp
===
---
C:/eclipse_workspaces/tomcat_trunk/tomcat6/webapps/examples/jsp/forward/forward.jsp
(revision 522964)
+++
C:/eclipse_workspaces/tomcat_trunk/tomcat6/webapps/examples/jsp/forward/forward.jsp
(working copy)
@@ -11,7 +11,7 @@
if (percent < 0.5) { 
 %>
 
-
+
 
 <% } else { %>
 
Index:
C:/eclipse_workspaces/tomcat_trunk/tomcat6/webapps/examples/jsp/sessions/carts.jsp
===
---
C:/eclipse_workspaces/tomcat_trunk/tomcat6/webapps/examples/jsp/sessions/carts.jsp
(revision 522964)
+++
C:/eclipse_workspaces/tomcat_trunk/tomcat6/webapps/examples/jsp/sessions/carts.jsp
(working copy)
@@ -40,5 +40,5 @@
 
 
 
-<%@ include file ="/sessions/carts.html" %>
+<%@ include file ="carts.html" %>
 

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 39850] - Need a way to invalidate SSL-session from web application

[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://issues.apache.org/bugzilla/show_bug.cgi?id=39850


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2007-03-28 04:09 ---
It's never going to be automated invalidation because that might break existing
apps.

Please understand that WONTFIX is not the same as INVALID.  I closed the bug as
WONTFIX because you (neither of you) didn't submit a patch, the issue is an
enhancement and not a bug, and no one else was interested in even commenting on
it in the year plus since it's been opened.

I'm going to close it again as WONTFIX.  If you want to reopen it, please do so
only with a working patch attached.  I'll be glad to look at said patch and
commit it if applicable or at least discuss it.  But please don't reopen this
issue just for the sake of reopening it.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 37918] - EL cannot find valid getter from object when using some inheritance

[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://issues.apache.org/bugzilla/show_bug.cgi?id=37918


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|NEEDINFO




--- Additional Comments From [EMAIL PROTECTED]  2007-03-28 04:11 ---
Interesting.  Just it still occur with Tomcat 6 (6.0.10), which has an improved
EL implementation?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 41966] New: - Tomcat crashes with: java.net.SocketException: No child processes

[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://issues.apache.org/bugzilla/show_bug.cgi?id=41966

   Summary: Tomcat crashes with: java.net.SocketException: No child
processes
   Product: Tomcat 5
   Version: 5.0.28
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


We are running a web-service application under Tomcat.
About once a day tomcat crashes. The only thing we see is the following 
stackTrace in nohup.out (i.e. written by System.out or System.err):

StandardServer.await: accept: java.net.SocketException: No child processes
java.net.SocketException: No child processes
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:353)
at java.net.ServerSocket.implAccept(ServerSocket.java:448)
at java.net.ServerSocket.accept(ServerSocket.java:419)
at 
org.apache.catalina.core.StandardServer.await(StandardServer.java:513)
at org.apache.catalina.startup.Catalina.await(Catalina.java:619)
at org.apache.catalina.startup.Catalina.start(Catalina.java:579)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:297)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:398)

What can be the cause for this crash?
Can a bug in the application cause it?
Or a misconfiguration?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

svn commit: r523324 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardThreadExecutor.java

[remm]

Author: remm
Date: Wed Mar 28 06:46:45 2007
New Revision: 523324

URL: http://svn.apache.org/viewvc?view=rev&rev=523324
Log:
- License header !

Modified:

tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardThreadExecutor.java

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardThreadExecutor.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardThreadExecutor.java?view=diff&rev=523324&r1=523323&r2=523324
==
--- 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardThreadExecutor.java 
(original)
+++ 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardThreadExecutor.java 
Wed Mar 28 06:46:45 2007
@@ -1,3 +1,20 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ * 
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ * 
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
 package org.apache.catalina.core;
 
 import java.util.Collection;



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

svn commit: r523327 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/Catalina.java

[remm]

Author: remm
Date: Wed Mar 28 06:52:08 2007
New Revision: 523327

URL: http://svn.apache.org/viewvc?view=rev&rev=523327
Log:
- Tweak startup time a bit.

Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/Catalina.java

Modified: tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/Catalina.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/Catalina.java?view=diff&rev=523327&r1=523326&r2=523327
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/Catalina.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/Catalina.java Wed Mar 
28 06:52:08 2007
@@ -445,6 +445,8 @@
  */
 public void load() {
 
+long t1 = System.nanoTime();
+
 initDirs();
 
 // Before digester - it may be needed
@@ -453,9 +455,7 @@
 
 // Create and execute our Digester
 Digester digester = createStartDigester();
-long t1 = System.currentTimeMillis();
 
-Exception ex = null;
 InputSource inputSource = null;
 InputStream inputStream = null;
 File file = null;
@@ -521,9 +521,9 @@
 }
 }
 
-long t2 = System.currentTimeMillis();
+long t2 = System.nanoTime();
 if(log.isInfoEnabled())
-log.info("Initialization processed in " + (t2 - t1) + " ms");
+log.info("Initialization processed in " + ((t2 - t1) / 100) + 
" ms");
 
 }
 
@@ -558,8 +558,8 @@
 load();
 }
 
-long t1 = System.currentTimeMillis();
-
+long t1 = System.nanoTime();
+
 // Start the new server
 if (server instanceof Lifecycle) {
 try {
@@ -569,9 +569,9 @@
 }
 }
 
-long t2 = System.currentTimeMillis();
+long t2 = System.nanoTime();
 if(log.isInfoEnabled())
-log.info("Server startup in " + (t2 - t1) + " ms");
+log.info("Server startup in " + ((t2 - t1) / 100) + " ms");
 
 try {
 // Register shutdown hook



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

Re: 6.0.11 anyone

[Filip Hanik - Dev Lists]

William L. Thomson Jr. wrote:

On Tue, 2007-03-27 at 17:45 -0600, Filip Hanik - Dev Lists wrote:
  

Remy Maucherat wrote:


Filip Hanik - Dev Lists wrote:
  
oh, and can we have the JULI with support for commons-logging built 
as part of the standard build?

if, yes, then I will be happy to do it

IMO, no. I'd like to keep a no dependencies, no nonsense build :) I 
don't see any need to use log4j for Tomcat logging anyway, unless you 
like running into problems.
  

it's more about being able to publish all our packages consistently.



That is understandable.

  
For example, Geronimo, needs to be able to have a unified logging 
system, and they do, commons logging.
And right now, since those packages are not part of an official release, 
I can't publish that JAR unless I do it manually. I'd like to be able to 
publish the actual JAR out of the release.



IMHO and pretty much the Gentoo Linux Java philosophy is bundled stuff
is bad. FOSS Java apps tend to do it more than others. Please consider a
slightly different viewpoint. But surely not trying to debate, or etc.

Anytime deps are bundled as part of a release, you are locked into that
version. If there are bug fixes and other releases. They don't tend to
make it into other applications. Take Netbeans for example, current 5.5
version ships with a now outdated version of Tomcat 5.5, I believe
5.5.17, might be 5.5.20. Can't recall exactly. 


Just to be clear either way, current addition of commons-logging won't
make much difference for us on Gentoo. Why? Because we install once
instance of a given library, app or etc. We then provide all apps using
that library, symbolic links to it said jar file or etc. Providing it's
API/ABI etc compliant with other dependencies. If dependencies are fixed
on a particular version. We "slot" it and allow for multiple instances
to be installed.

In Tomcat sense we install one version of Tomcat that say can be used
with either Netbeans or Eclipse, in place of any version being shipped.
( Although not sure if eclipse plugins or etc ship tc, I know they have
issues when tc is split via C_HOME/C_BASE as we do on Gentoo )

This allows for easier management. Say in this case, commons-logging has
a new release. As it's package and updated it's updated for all
applications using that "slot".

Now one might thing manually fetching a dep to be bad. (On Gentoo it's
automated) However that also allows end user to make a choice on version
to use. If it's been some time past primary app release, in this case
Tomcat. Then it's possible what ever version they ship at the time is
newer than the bundled version say in a previous Tomcat release.

For a further example take Tomcat's jasper-jdt.jar or should I really
call it by it's real name, Eclipse JDT. Or at least some of it. Which I
can understand slimming the package down to all that is necessary. But
that also means future updates to Eclipse JDT won't make it into Tomcat.
On Gentoo, I might end up replacing that file with a symlink. For I am
letting the build system do it's thing and repackage what it needs.

So again not trying to really change the direction or debate this. Just
providing a different view point. I can also understand our solution is
quite limited to operating systems that allow for symbolic links. Then
again from another point of view, could be more that allow for symbolic
links than not ;) 


But in the end bundled stuff is bad IMHO. If it can be avoided it should
be, and manually fetching deps is not a bad thing. Definitely when it's
not pertinent to the application. But only a subset that might run on
the application and want things available about of convenience.
Consistency again I can understand, but does that mean things have to be
consistent forever and not subject to change?

Anyway, just some food for thought. Sorry for length, and hijacking
thread topic a bit. Just felt it was kinda a good time to mention it
all, since the discussion was along similar lines.
  

sorry you had to go on for such a long rant,
no one is asking to bundle or to make dependencies.
simply asking that some other packages get built at the same time,
Filip

Thanks for your time :)

  



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

DO NOT REPLY [Bug 41969] New: - NullPointerException

[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://issues.apache.org/bugzilla/show_bug.cgi?id=41969

   Summary: NullPointerException
   Product: Tomcat 5
   Version: 5.5.23
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina:Modules
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


 

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 41969] - NullPointerException

[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://issues.apache.org/bugzilla/show_bug.cgi?id=41969


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 41969] - NullPointerException

[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://issues.apache.org/bugzilla/show_bug.cgi?id=41969


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

svn commit: r523331 - in /tomcat/tc6.0.x/trunk/java/org/apache: coyote/ajp/ coyote/http11/ tomcat/util/net/

[remm]

Author: remm
Date: Wed Mar 28 07:01:53 2007
New Revision: 523331

URL: http://svn.apache.org/viewvc?view=rev&rev=523331
Log:
- The poller now has good performance, so remove firstReadTimeout (the 
algorithm can still be retrieved from
  svn if needed).

Modified:
tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java
tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpAprProtocol.java
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11AprProcessor.java
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11AprProtocol.java

tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalAprInputBuffer.java
tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java

Modified: tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java?view=diff&rev=523331&r1=523330&r2=523331
==
--- tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java Wed 
Mar 28 07:01:53 2007
@@ -90,13 +90,6 @@
 responseHeaderMessage = new AjpMessage(packetSize);
 bodyMessage = new AjpMessage(packetSize);
 
-readTimeout = endpoint.getFirstReadTimeout() * 1000;
-if (readTimeout == 0) {
-readTimeout = 100 * 1000;
-} else if (readTimeout < 0) {
-readTimeout = -1;
-}
-
 // Allocate input and output buffers
 inputBuffer = ByteBuffer.allocateDirect(packetSize * 2);
 inputBuffer.limit(0);
@@ -189,13 +182,6 @@
 
 
 /**
- * The socket timeout used when reading the first block of the request
- * header.
- */
-protected long readTimeout;
-
-
-/**
  * Temp message bytes used for processing.
  */
 protected MessageBytes tmpMB = MessageBytes.newInstance();
@@ -371,11 +357,6 @@
 // Error flag
 error = false;
 
-int limit = 0;
-if (endpoint.getFirstReadTimeout() > 0) {
-limit = endpoint.getMaxThreads() / 2;
-}
-
 boolean openSocket = true;
 boolean keptAlive = false;
 
@@ -384,8 +365,7 @@
 // Parsing the request header
 try {
 // Get first message of the request
-if (!readMessage(requestHeaderMessage, true,
-keptAlive && (endpoint.getCurrentThreadsBusy() >= 
limit))) {
+if (!readMessage(requestHeaderMessage, true, keptAlive)) {
 // This means that no data is available right now
 // (long keepalive), so that the processor should be 
recycled
 // and the method should return true
@@ -1061,15 +1041,9 @@
 }
 int nRead;
 while (inputBuffer.remaining() < n) {
-if (readTimeout > 0) {
-nRead = Socket.recvbbt
-(socket, inputBuffer.limit(),
-inputBuffer.capacity() - inputBuffer.limit(), 
readTimeout);
-} else {
-nRead = Socket.recvbb
-(socket, inputBuffer.limit(),
-inputBuffer.capacity() - inputBuffer.limit());
-}
+nRead = Socket.recvbb
+(socket, inputBuffer.limit(),
+inputBuffer.capacity() - inputBuffer.limit());
 if (nRead > 0) {
 inputBuffer.limit(inputBuffer.limit() + nRead);
 } else {

Modified: tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpAprProtocol.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpAprProtocol.java?view=diff&rev=523331&r1=523330&r2=523331
==
--- tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpAprProtocol.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpAprProtocol.java Wed Mar 
28 07:01:53 2007
@@ -364,17 +364,6 @@
 }
 
 
-public int getFirstReadTimeout() {
-return ep.getFirstReadTimeout();
-}
-
-
-public void setFirstReadTimeout(int i) {
-ep.setFirstReadTimeout(i);
-setAttribute("firstReadTimeout", "" + i);
-}
-
-
 public int getPollTime() {
 return ep.getPollTime();
 }

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11AprProcessor.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11AprProcessor.java?view=diff&rev=523331&r1=523330&r2=523331
==
--- tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11AprProcessor.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11AprProcessor.java 
Wed Mar 28 07:01:53 2007
@@ -87,14

Re: 6.0.11 anyone

[Erik Bertelsen]

>
> I don't see any problem then. Since it is generated during the
> releases if you type "ant -f extras.xml", it should be possible for
> the RM to release these extra binaries (at least the binaries which
> may be legally shipped, or are practical to ship) along with the
> regular packages.
yes, this is what I was hoping for. Makes my life so much easier.


yes, please do.

This will make it possible for people using commons-logging as their general
logging framework to continue to doing that (regardless of whether commons-
logging is used with log4j or whatever).

- Erik

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

DO NOT REPLY [Bug 40809] - Tomcat 5.5.20 fails to load ServletContextListener in tld!

[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://issues.apache.org/bugzilla/show_bug.cgi?id=40809





--- Additional Comments From [EMAIL PROTECTED]  2007-03-28 10:52 ---
I'm experiencing the same problem with Tomcat 5.5.23.  If the path has spaces in
it, the tldCache.ser file gets created without the JSF configure listener.  If
the path does not have spaces, then it gets created correctly.  Copying the
tldCache.ser from a 5.5.17 deployment of the same webapp into the 5.5.23
deployment works around the problem temporarily without removing the spaces from
the path (I originally found both workarounds here:
http://forum.java.sun.com/thread.jspa?messageID=9581146 where other users are
describing the same problem).

I also found the same problem reported and fixed in the Glassfish bug tracker
over a year ago.  The path to the source file makes it look like they forked
Tomcat, so I am including the link to the bug and fix in their tracker in case
it turns out to be the same source:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6358409 .

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 41923] - Tomcat doesnt recognized client abort

[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://issues.apache.org/bugzilla/show_bug.cgi?id=41923





--- Additional Comments From [EMAIL PROTECTED]  2007-03-28 11:38 ---
But did you think its a bug? The documtation suggests here another behaviour. 
Dont know if anybody from the developer team cares about it.
Do you have a workaround for this problem, without changing architecture? I 
looked in mod_jk sources but it contains only handling the response code, if 
recovery_options=4 is set.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 41973] New: - IPv6 APR Connectors assumes IPv4-mapped IPv6 address support

[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://issues.apache.org/bugzilla/show_bug.cgi?id=41973

   Summary: IPv6 APR Connectors assumes IPv4-mapped IPv6 address
support
   Product: Tomcat 5
   Version: 5.5.23
  Platform: Other
OS/Version: OpenBSD
Status: NEW
  Severity: normal
  Priority: P2
 Component: Native:Integration
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Several operating systems don't support IPv4-mapped IPv6 address or have it 
disabled by default (windows, OpenBSD, FreeBSD, NetBSD).

In Sun's jvm on windows when a ServerSocket is created the jvm creates two 
sockets, one for IPv4 and another for IPv6. The BSD's haven't ported this 
feature yet and opted to disable IPv6 in jvm until someone ports the two socket 
approach.

When using tcnative on Windows or a *BSD system and the Connector element in 
Server.xml doesn't specify an address attribute, the behavior of the Connector
changes. On windows it goes from listening on both IPv6 and IPv4 to just 
listening on IPv6. For *BSD it goes from listening on IPv4 to listening on 
IPv6.

I should point out I've only seen the above described behavior change on the 
BSD's (I don't use windows), but based on my knowledge of how Sun's jvm works I 
expect the windows behavior to be as I described.

I believe the fully correct solution would be to implement the two socket 
approach like Sun did for server sockets on windows, however that's going to 
take a bit work. As a stop gap the following untested diff keeps IPv4 working 
for windows and *BSD. For windows to get both IPv4 and IPv6 support while using 
tcnative, users will need to configure a second Connector with address 
specified to "::" or other IPv6 address.

Index: util/java/org/apache/tomcat/util/net/AprEndpoint.java
===
--- util/java/org/apache/tomcat/util/net/AprEndpoint.java   (revision 
523411)
+++ util/java/org/apache/tomcat/util/net/AprEndpoint.java   (working copy)
@@ -555,10 +555,11 @@
 }
 int family = Socket.APR_INET;
 if (Library.APR_HAVE_IPV6) {
-if (addressStr == null)
+if (addressStr == null) {
+if (!OS.IS_BSD && !OS.IS_WIN32 && !OS.IS_WIN64)
+family = Socket.APR_UNSPEC;
+} else if (addressStr.indexOf(':') >= 0)
 family = Socket.APR_UNSPEC;
-else if (addressStr.indexOf(':') >= 0)
-family = Socket.APR_UNSPEC;
 }
 long inetAddress = Address.info(addressStr, family,
 port, 0, rootPool);

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 41973] - IPv6 APR Connectors assumes IPv4-mapped IPv6 address support

[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://issues.apache.org/bugzilla/show_bug.cgi?id=41973





--- Additional Comments From [EMAIL PROTECTED]  2007-03-28 11:54 ---
I agree with you, and yes windows has the same behavior as BSD
probably because Microsoft stole the entire networking from BSD ;)

Anyhow, in case the address is null it make sense to force the
IPV4 on those platforms (by default APR for windows comes without
IPV6 support, so you need to manually enable that during the build time).

On Windows and BSD one can simulate the same behavior like on Linux
or Solaris by using two connectors with the same port
IPV4 with address="0.0.0.0"
IPV6 with address="::"
(Something JDK is doing)

Anyhow, the problem is not with Tomcat native, but rather the APR
should probably support that transparently.
(It's on my TODO list for APR 2)


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: 6.0.11 anyone

[William L. Thomson Jr.]

On Wed, 2007-03-28 at 07:55 -0600, Filip Hanik - Dev Lists wrote:
>   
> sorry you had to go on for such a long rant,

No worries, just providing info that may or may not be know.

> no one is asking to bundle or to make dependencies.
> simply asking that some other packages get built at the same time,

Ok, so I must not be clear on the discussion. It seems like the build
process of Tomcat was to include some extra jars that would go elsewhere
in the binary release of Tomcat. But not something that would be a build
time dependency.

Is that not the case?

Are you just trying to get another Apache project to be released in
conjunction with Tomcat?

Sorry, just not clear because there were comments about build time
dependencies. And it was being brought up as part of another release of
Tomcat. So I understood it to be another jar being included with Tomcat
that is presently, not, and was in the past.

I have gone and re-read the entire thread several times.

Like the original comment that brought it all up

"oh, and can we have the JULI with support for commons-logging built as 
part of the standard build?"

Is that talking about the build of Tomcat? or build of another
application? Because the follow up talks about keeping deps to a min,
and a no nonsense build system for Tomcat.

With the response,

"That doesn't mean that the JAR has to be in the lib directory, all I'm 
asking is that it is generated during our releases"

Which I assume to be Tomcat's lib directory. And the jar would go in
another directory.

I assume the extras.xml is a build file that will be part of Tomcat's
build system?

So I am mighty confused as to the discussion being about building other
packages, that won't be bundled nor a dependency. The dependency part is
clear. The won't be bundled, and building other packages is not clear.

Will they be a separate bundle or download? Like the old embedded,
compat stuff, etc.

Sorry if all this is obvious and the plane is just flying over my
head ;)

-- 
William L. Thomson Jr.
Gentoo/Java


signature.asc
Description: This is a digitally signed message part

DO NOT REPLY [Bug 41976] New: - Add OpenBSD to OS.is(7/BSD)

[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://issues.apache.org/bugzilla/show_bug.cgi?id=41976

   Summary: Add OpenBSD to OS.is(7/BSD)
   Product: Tomcat 5
   Version: 5.5.23
  Platform: Other
OS/Version: OpenBSD
Status: NEW
  Severity: normal
  Priority: P2
 Component: Native:Integration
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Pretty straightforward. Thanks!

--- jni/native/os/unix/system.c.origWed Mar 28 11:53:50 2007
+++ jni/native/os/unix/system.c Wed Mar 28 11:54:06 2007
@@ -95,7 +95,7 @@ TCN_IMPLEMENT_CALL(jboolean, OS, is)(TCN_STDARGS, jint
 else if (type == 6)
 return JNI_TRUE;
 #endif
-#if defined(__FreeBSD__) || defined(__NetBSD__)
+#if defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__)
 else if (type == 7)
 return JNI_TRUE;
 #endif

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: 6.0.11 anyone

[Filip Hanik - Dev Lists]

man, you sure like to write.

The buildscript command:

ant -f extras.xml

generates two files
output\extras\tomcat-juli.jar
output\extras\tomcat-juli-adapters.jar

All i'm asking is that these two get generated at release time

what I'm doing is publishing .jar files to a maven repository for 
containers that use Tomcat embedded or just want to use independent jars


So, apache-tomcat-6.0.11.zip will NOT contain these jars.
But they were generated during the build, and is available somewhere so 
that I can run the "mavenize" script, and push those files to ASF's 
maven repository.


Filip

William L. Thomson Jr. wrote:

On Wed, 2007-03-28 at 07:55 -0600, Filip Hanik - Dev Lists wrote:
  
  
sorry you had to go on for such a long rant,



No worries, just providing info that may or may not be know.

  

no one is asking to bundle or to make dependencies.
simply asking that some other packages get built at the same time,



Ok, so I must not be clear on the discussion. It seems like the build
process of Tomcat was to include some extra jars that would go elsewhere
in the binary release of Tomcat. But not something that would be a build
time dependency.

Is that not the case?

Are you just trying to get another Apache project to be released in
conjunction with Tomcat?

Sorry, just not clear because there were comments about build time
dependencies. And it was being brought up as part of another release of
Tomcat. So I understood it to be another jar being included with Tomcat
that is presently, not, and was in the past.

I have gone and re-read the entire thread several times.

Like the original comment that brought it all up

"oh, and can we have the JULI with support for commons-logging built as 
part of the standard build?"


Is that talking about the build of Tomcat? or build of another
application? Because the follow up talks about keeping deps to a min,
and a no nonsense build system for Tomcat.

With the response,

"That doesn't mean that the JAR has to be in the lib directory, all I'm 
asking is that it is generated during our releases"


Which I assume to be Tomcat's lib directory. And the jar would go in
another directory.

I assume the extras.xml is a build file that will be part of Tomcat's
build system?

So I am mighty confused as to the discussion being about building other
packages, that won't be bundled nor a dependency. The dependency part is
clear. The won't be bundled, and building other packages is not clear.

Will they be a separate bundle or download? Like the old embedded,
compat stuff, etc.

Sorry if all this is obvious and the plane is just flying over my
head ;)

  



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

Re: 6.0.11 anyone

[William L. Thomson Jr.]

On Wed, 2007-03-28 at 14:51 -0600, Filip Hanik - Dev Lists wrote:
> man, you sure like to write.

Doesn't take long to type ;)

> The buildscript command:
> 
> ant -f extras.xml
> 
> generates two files
> output\extras\tomcat-juli.jar
> output\extras\tomcat-juli-adapters.jar
> 
> All i'm asking is that these two get generated at release time
> 
> what I'm doing is publishing .jar files to a maven repository for 
> containers that use Tomcat embedded or just want to use independent jars

Ok, that makes sense. We are discussing how we can integrate and use
maven with our packaging system on Gentoo. Also need to have an embedded
version of Tomcat available for like JBoss.

> So, apache-tomcat-6.0.11.zip will NOT contain these jars.

Ok great, I am 100% clear now. Thanks and sorry about all that. Despite
us building from source. We try to make the resulting install provide
what upstream does. So if those jars were in there, I would need to
include them. But they won't so I don't ;)

> But they were generated during the build, and is available somewhere so 
> that I can run the "mavenize" script, and push those files to ASF's 
> maven repository.

I was not clear on the generation vs packaging. Thanks and sorry for
lengths.

-- 
William L. Thomson Jr.
Gentoo/Java


signature.asc
Description: This is a digitally signed message part

svn commit: r523564 - /tomcat/connectors/trunk/jni/native/os/unix/system.c

[mturk]

Author: mturk
Date: Wed Mar 28 22:22:47 2007
New Revision: 523564

URL: http://svn.apache.org/viewvc?view=rev&rev=523564
Log:
Fix #41976 by adding Open BSD to the list of BSD* platforms

Modified:
tomcat/connectors/trunk/jni/native/os/unix/system.c

Modified: tomcat/connectors/trunk/jni/native/os/unix/system.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jni/native/os/unix/system.c?view=diff&rev=523564&r1=523563&r2=523564
==
--- tomcat/connectors/trunk/jni/native/os/unix/system.c (original)
+++ tomcat/connectors/trunk/jni/native/os/unix/system.c Wed Mar 28 22:22:47 2007
@@ -95,7 +95,7 @@
 else if (type == 6)
 return JNI_TRUE;
 #endif
-#if defined(__FreeBSD__) || defined(__NetBSD__)
+#if defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__)
 else if (type == 7)
 return JNI_TRUE;
 #endif



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

DO NOT REPLY [Bug 41976] - Add OpenBSD to OS.is(7/BSD)

[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://issues.apache.org/bugzilla/show_bug.cgi?id=41976


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2007-03-28 22:28 ---
Commited, thanks

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 41964] - missing links on the examples application.

[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://issues.apache.org/bugzilla/show_bug.cgi?id=41964


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE




--- Additional Comments From [EMAIL PROTECTED]  2007-03-28 23:14 ---


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

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 41684] - Some URIs need to be adapted to the changed layout of the stock webapps, some files are missing

[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://issues.apache.org/bugzilla/show_bug.cgi?id=41684


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2007-03-28 23:14 ---
*** Bug 41964 has been marked as a duplicate of this bug. ***

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 39850] - Need a way to invalidate SSL-session from web application

[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://issues.apache.org/bugzilla/show_bug.cgi?id=39850





--- Additional Comments From [EMAIL PROTECTED]  2007-03-29 00:27 ---
Ok, thanks for the quick reply. I do not have a patch (or time to create one)
that implements the automtic invalidation. I agree that changing the behaviour
of Tomcat might break existing apps but that can be fixed by by making this
behaviour configurable.

I still hope this feature will be implemented in future versions of Tomcat
because it is absolutely required when you use client authentication over SSL.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 39850] - Need a way to invalidate SSL-session from web application

[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://issues.apache.org/bugzilla/show_bug.cgi?id=39850





--- Additional Comments From [EMAIL PROTECTED]  2007-03-29 00:34 ---
Would it be acceptable if I'll try to create a path which will set session
attribute kind of "org.apache.tomcat.ssl.session" with the SSLSession object
(javax.net.ssl.SSLSession)?

We will be able to call invalidate() on that object.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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