Tomcat Snapshots

2005-10-10 Thread Henri Yandell 
Currently the following CVS modules are snapshotted to
http://cvs.apache.org/snapshots/

jakarta-tomcat jakarta-tomcat-4.0 jakarta-tomcat-5
jakarta-tomcat-catalina jakarta-tomcat-jasper
jakarta-tomcat-connectors jakarta-tools jakarta-watchdog
jakarta-servletapi jakarta-servletapi-4 jakarta-servletapi-5
jakarta-watchdog-4.0

I need to identify the svn match to each one of those to continue the
snapshots going. ie)

jakarta-tomcat-tools  =>  tomcat/archive/tools/trunk/

Though I imagine something in archive/ isn't a candidate for snapshotting.

Could you let me know which parts of the tomcat svn directory you'd
like me to set snapshotting up for?

(knowing about the snapshots is a pretty recent thing for me, so it's
still somewhat of an afterthought to a migration)

Hen

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

DO NOT REPLY [Bug 35853] - Make JkMount compatible with servlet-mapping/url-pattern in web.xml

2005-10-10 Thread 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=35853


[EMAIL PROTECTED] changed:

   What|Removed |Added

  Component|Connector:JK/AJP|Native:JK
Product|Tomcat 4|Tomcat 5




-- 
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 36995] - duplicate session ids

2005-10-10 Thread 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=36995


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED




--- Additional Comments From [EMAIL PROTECTED]  2005-10-10 19:58 ---
I hava look inside also inside 5.5.x code (ManagerBase.generateSessionId()) and
think the duplication risk is there. But the risk is small, as random generator
works really good. I have test with Linux Suse 9.3 and have no chance to
reproduce your test result. Can you please send your testscripts and os 
information?

Thanks
Peter 

-- 
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 36995] New: - duplicate session ids

2005-10-10 Thread 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=36995

   Summary: duplicate session ids
   Product: Tomcat 4
   Version: 4.1.31
  Platform: PC
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Greetings,

We ran a simple load test against Tomcat 4.1.x after having some strange
session effects on our website, to see if the generated session ids are
really unique. The test made HTTP requests with wget, extracted the newly
generated session ids and wrote them into a file. It turned up two pairs
of duplicate session ids from active sessions.

I read the source code to see how the session ids are generated, and found
this code in org.apache.catalina.session.ManagerBase#createSession() from
Tomcat 4.1.31, line 544 to 555:

synchronized (sessions) {
while (sessions.get(sessionId) != null){ // Guarantee uniqueness
sessionId = generateSessionId();
duplicates++;
// @todo Move appending of jvmRoute generateSessionId()???
if (jvmRoute != null) {
sessionId += '.' + jvmRoute;
}
}
}

session.setId(sessionId);

I came up with the following scenario, where duplicate session ids could
be generated:

Thread 1 runs into the method, generates a session id, checks if the session
id is unique and leaves the synchronized block. There the thread 1 pauses and
thread 2, a request from a different user, takes over.

Thread 2 runs into the method, generates the same session id by pure chance
and checks if the session id is unique. Since thread 1 has not yet called
setId, the session id isn't stored in the HashMap, the session id is
considered unique and the loop is left. The method setId() is called, which
results in a call to the method add() of the ManageBase class. There the new
session object is stored in the HashMap with the session id.

Thread 1 continues and calls setId() as well, overwriting the already present
session object in the HashMap with a new one.

Both threads continue and return a duplicate session id to different user.
Both users use the same session object for subsequent requests.

I know the chances for this scenario are slim, as it must generate the same
session id and run into the race condition between the two syncronised blocks
in createSession() and add(), but it appears to be happening.

Shouldn't the check for uniqueness and the adding of the newly generated
session id be in the same syncronized block of "sessions", to really
ensure uniqueness? Or did I get something wrong here?

Tomcat 5.0.28 and Tomcat 5.5.9 appears to have the same problem, btw.

Thanks,

Christian

-- 
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 36994] New: - httpsession.getId() throws ISE after invalidation

2005-10-10 Thread 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=36994

   Summary: httpsession.getId() throws ISE after invalidation
   Product: Tomcat 5
   Version: 5.0.12
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


After a http session is invalidated a call to getId() throws an
IllegalStateException("already invalidated").

I think this doesn't conform to the servlet spec that doesn't say anything about
an ISE in the api doc. All ISEs that can be thrown by the session-methods are
explicit listed.

Beside this it is very essential to have the sessionId at least during
HttpSessionBindingListener.valueUnbound() if this method is called during the
invalidation.
The api doc of valueUnbound() says:
"Notifies the object that it is being unbound from a session and identifies the
session."
The session is identified by its Id, but if the Id is not accessible anymore...

The ISE was inserted in Version 5.5.10: excerpt from the changelog:
"Re-add patch causing Session.getId to throw an ISE, and make all internal
components use a safe getIdInternal"


Thanks
Lars

-- 
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 36990] New: - Undeployment fails when Tomcat service is restarted after successful deployment

2005-10-10 Thread 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=36990

   Summary: Undeployment fails when Tomcat service is restarted
after successful deployment
   Product: Tomcat 5
   Version: 5.5.9
  Platform: Other
OS/Version: Windows 2000
Status: NEW
  Severity: normal
  Priority: P2
 Component: Webapps:Manager
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


This may not be a bug as such, but I do not believe it is correct behaviour. It 
is using the Ant deploy script for a target Tomcat 5.5.12 for Windows using the 
service.

1. Deploy a WAR to a clean Tomcat using an embedded META-INF/context.xml, 
path="ROOT"
2. Application is deployed OK, requests succeed OK.
3. Restart Tomcat service
4. Call undeploy of ROOT web application

The undeploy fails with FAIL - No context exists for path /ROOT despite the 
following 3 facts

1. /conf/Catalina/localhost/ROOT.xml exists
2. /webapps/ROOT.war exists
3. /webapps/ROOT (exploded) exists

Is it correct that a restart of Tomcat should prevent undeployments of 
previously deployed webapps?

-- 
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: r312627 - /tomcat/build/tc5.5.x/build.xml

2005-10-10 Thread funkman 
Author: funkman
Date: Mon Oct 10 04:53:41 2005
New Revision: 312627

URL: http://svn.apache.org/viewcvs?rev=312627&view=rev
Log:
Remove all cvs dependencies/


Modified:
tomcat/build/tc5.5.x/build.xml

Modified: tomcat/build/tc5.5.x/build.xml
URL: 
http://svn.apache.org/viewcvs/tomcat/build/tc5.5.x/build.xml?rev=312627&r1=312626&r2=312627&view=diff
==
--- tomcat/build/tc5.5.x/build.xml (original)
+++ tomcat/build/tc5.5.x/build.xml Mon Oct 10 04:53:41 2005
@@ -7,7 +7,7 @@
   
   
   
-  
+
   
 
   
@@ -16,7 +16,7 @@
   
   
   
-
+  
   
   
 
@@ -32,14 +32,11 @@
   
   
   
-  
-  
 
   
   
-  
   
@@ -62,13 +59,13 @@
   
   
   
-  
   
-  
-  
-  
   
   
@@ -127,17 +124,11 @@
   
 
 
-
   
 
 
-
   
 
 
@@ -146,24 +137,24 @@
 
 
 
-
 
-
 
 
 
 
-
 
 
-   
+file="${tomcat-native.tar.gz}" />
+
 
-   
+
   
 
   
@@ -195,7 +186,7 @@
 
   
 
-  
 == Building: tomcat-jk ${catalina.build} 
 
@@ -220,13 +211,13 @@
 
 
 
-   
 
-   
-   
+
+
   
 
 
@@ -239,8 +230,8 @@
 
   
 
-  
 == Building: tomcat-coyote 
 
@@ -253,9 +244,9 @@
   
 
 
-   
-   
-   
+
+
+
   
 
 
@@ -267,8 +258,8 @@
 
   
 
-  
 == Building: tomcat-http11 
 
@@ -280,9 +271,9 @@
   -->
   
 
-   
-   
-   
+
+
+
   
 
 
@@ -293,58 +284,58 @@
 
   
 
- 
-   == Building: tomcat-apr 
-
-   
- 
- 
- 
-   
-   
-   
-   
- 
-   
-   
-   
-   
- 
-   
-
- 
-
- 
-   == Building: tomcat-juli 
-
-   
- 
-   
-   
-   
-   
- 
-   
-   
-   
-   
- 
-   
-
-
-   
- 
+  
+== Building: tomcat-apr 
+
+
+  
+  
+  
+
+
+
+
+  
+
+
+
+
+  
+
 
-  
+
+  
+== Building: tomcat-juli 
+
+
+  
+
+
+
+
+  
+
+
+
+
+  
+
+
+
+
+  
+
+  
 == Building: jasper 
 
@@ -358,7 +349,7 @@
 
   
 
-  
 
 == Building: admin 
@@ -373,7 +364,7 @@
 
   
 
-  
 
 
@@ -410,7 +401,7 @@
   
 
 
-
 
-
 
-
+   srcdir="${ROOT.base}/WEB-INF/src"
+   excludes="**/*.smap">
   
 
 
@@ -469,8 +460,8 @@
deprecation="${compile.deprecation}"
source="${compile.source}"
failonerror="false"
-   srcdir="${jsp-examples.base}/WEB-INF/src" 
-  excludes="**/*.smap">
+   srcdir="${jsp-examples.base}/WEB-INF/src"
+   excludes="**/*.smap">
   
 
 
@@ -495,8 +486,8 @@
deprecation="${compile.deprecation}"
source="${compile.source}"
failonerror="false"
-   srcdir="${admin.base}/WEB-INF/src" 
-  excludes="**/*.smap">
+   srcdir="${admin.base}/WEB-INF/src"
+   excludes="**/*.smap">
   
 
 
@@ -568,9 +559,9 @@
 
 
 
-  
+
 
-  
+
 
 
 
@@ -584,7 +575,7 @@
 
   
 
-   
+
 
   
 
@@ -604,7 +595,7 @@
   
 
 
-   
+
 
   
 
@@ -617,37 +608,12 @@
 
   
 
-   
-  
-   
-  
 
-
-
-
+  
 
-  
 
 
@@ -663,7 +629,7 @@
   
   
 
-   
+
   
   
 
@@ -691,38 +657,38 @@
 
   
 
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 
-   
+
 
   
 
- 
-  
-  
- 
-  
- 
-
- 
-   
-   
-   
-   
-   
-   
-

DO NOT REPLY [Bug 36983] New: - session problems with cross context webapps

2005-10-10 Thread 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=36983

   Summary: session problems with cross context webapps
   Product: Tomcat 5
   Version: 5.5.12
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I encountered a problem with sessions and cross context calls. Here is a 
scenario:

We have to webapps (webapp1 and webapp2). 
webapp1 is configured with cross contex set to true so it is able to dispatch to
webapp2. 
Now user access webapp1 and webapp2. Two sessions are created for both webapps. 

request.getSession in webapp1 returns session1 
request.getSession in webapp2 returns session2

Problem is during dispatching request from webapp1 to webapp2, because 
request.getSession in webapp2 does not return session2, but only for request
which is dispatched from webapp1. all the following request which are not cross
context again return session2, so session is not lost. 

Tomcat 5.0.x works fine when dispatching cross context requests (two separate
sessions are maintained for each webapp).

-- 
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]