Tomcat 6.0 on HP Non-Stop Server

[Nagendra, Suveer]

Hello,
Am in the process of porting Tomcat 6.0.13 servlet container to run on a
HP Non-Stop Multi CPU environment. This would mean there would multiple
'servlet container' processes deployed on native deployment mechanisms.
This port involves the following tasks:


1.  Write connector to the native Webserver (an iTP Webserver) 
2.  Write/customise code for session handling. 
3.  Write/customize code for dynamic web application deployment. 
4.  Make changes to the JMX mechanism to ensure the changes are
communicated to all 'container' processes. 
5.  Importantly understand the internal working of the rest of the
container components and identify areas that would need change for a
successful port.

A typical environment would contain multiple Webserver processes and
multiple Container processes.
 
Currently am going through the code of Tomcat 6.0.13 and trying to
decipher the internal workings of various components and trying to
figure out if the components need any customization.
Am looking for guidance / help in this regard.
 
Am assuming that this would tantamount to a question pertaining to
"development of tomcat".
 
Thanks
 
Greetings,
Suveer

DO NOT REPLY [Bug 42689] New: - no way to timeout new connect attempts for replication sockets

[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=42689

   Summary: no way to timeout new connect attempts for replication
sockets
   Product: Tomcat 5
   Version: 5.5.23
  Platform: Sun
OS/Version: Solaris
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina:Cluster
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


While testing clustering in our lab we noticed that when connectivity to one of
the cluster members was lost by pulling the network cable (serving replication
traffic), the entire cluster would become unresponsive.  We were pulling the
network cable to simulate catastrophic switch port failure or interface failure.
We were testing under load, using synchronous replication.  We found that
existing replication sockets would honor our timeout (ackTimeout)
configurations, but new connections established because of pool growth or
retries would not timeout socket connect attempts.  Because of not having a
timeout, requests would backlog and effectively bring the cluster down.

Theoretically, this connection establishment problem exists for all users of the
DataSender class.

-- 
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 42689] - no way to timeout new connect attempts for replication sockets

[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=42689





--- Additional Comments From [EMAIL PROTECTED]  2007-06-18 06:50 ---
Created an attachment (id=20366)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=20366&action=view)
diff to use Socket.connect with timeout parameter

Our fix was to change DataSender.createSocket to use the ackTimeout for
connection establishment.  This fix will only work with jdk 1.4 or higher.

-- 
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 42691] New: - sessions increase timeout as cluster members join

[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=42691

   Summary: sessions increase timeout as cluster members join
   Product: Tomcat 5
   Version: 5.5.23
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina:Cluster
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


This is probably not a big problem for most users of session replication. 
However for us it was worth fixing.

In our environment we commonly perform rolling software upgrades across our web
site.  While testing replication, we noticed that as we shutdown and restarted
nodes, the session counts would continually grow.  Basically, we found that as
sessions are transfered at startup time, the local access time is set to the
transfer time.  Code comments imply that this is done to prevent incorrect node
time synchronization problems.  However, it also simulates activity for old
sessions that are about to expire.  Under load, if you restart nodes enough,
your session count will keep growing and growing.

We changed the current behavior to keep existing session access times by
commenting out the call to session.access() in DeltaManager.deserializeSessions
(line 782 in svn revision 548361)

-- 
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: r548385 - in /tomcat/tc6.0.x/trunk/java/javax/persistence: PersistenceContext.java PersistenceContextType.java

[remm]

Author: remm
Date: Mon Jun 18 08:54:54 2007
New Revision: 548385

URL: http://svn.apache.org/viewvc?view=rev&rev=548385
Log:
- Fix API. Submitted by Bill Burke.

Added:
tomcat/tc6.0.x/trunk/java/javax/persistence/PersistenceContextType.java   
(with props)
Modified:
tomcat/tc6.0.x/trunk/java/javax/persistence/PersistenceContext.java

Modified: tomcat/tc6.0.x/trunk/java/javax/persistence/PersistenceContext.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/javax/persistence/PersistenceContext.java?view=diff&rev=548385&r1=548384&r2=548385
==
--- tomcat/tc6.0.x/trunk/java/javax/persistence/PersistenceContext.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/javax/persistence/PersistenceContext.java Mon Jun 
18 08:54:54 2007
@@ -27,10 +27,6 @@
 @Retention(RetentionPolicy.RUNTIME)
 
 public @interface PersistenceContext {
-public enum PersistenceContextType {
-TRANSACTION,
-EXTENDED
-}
String name() default "";
String unitName() default "";
PersistenceContextType type() default PersistenceContextType.TRANSACTION;

Added: tomcat/tc6.0.x/trunk/java/javax/persistence/PersistenceContextType.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/javax/persistence/PersistenceContextType.java?view=auto&rev=548385
==
--- tomcat/tc6.0.x/trunk/java/javax/persistence/PersistenceContextType.java 
(added)
+++ tomcat/tc6.0.x/trunk/java/javax/persistence/PersistenceContextType.java Mon 
Jun 18 08:54:54 2007
@@ -0,0 +1,24 @@
+/*
+ * 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 javax.persistence;
+
+public enum PersistenceContextType {
+TRANSACTION,
+EXTENDED
+}
\ No newline at end of file

Propchange: 
tomcat/tc6.0.x/trunk/java/javax/persistence/PersistenceContextType.java
--
svn:eol-style = native



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

DO NOT REPLY [Bug 42693] New: - JSP-Generation error with recursive tagfile structure

[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=42693

   Summary: JSP-Generation error with recursive tagfile structure
   Product: Tomcat 6
   Version: unspecified
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: critical
  Priority: P1
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


addendum: it's Version 6.13 (not available in combobox above)

scenario:
=
a menu is decribed by a tree structure;
rendering the menu is done by a tagfile 'render_menuitem', which renders the
current item either as a leaf item (clicking on it causes an action) or as a
node item (clicking on it opens another next-level submenu);
rendering the submenu is done by calling the tagfile again from within its body;
this worked fine with tomcat 5.0.x and 5.5.x

to make it clear see the following pseudo code (the original code is to
voluminous): 
tagfile 'render_menuitem.tagx':

   
   
  


 
  
  
 leaf: ${menu_item.label}
  
   


faulty behaviour:

with tomcat 6.0.13, the generated Java-Source for the tagfile reveals, that the
body of the doTag() method is empty and therefore emits no html; the compilation
itself was silently done, no error or warning was shown in the logfiles.

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

May Chun Chew/FEA/PEC is out of the office.

[May Chun Chew]

I will be out of the office starting  06/19/2007 and will not return until
06/21/2007.

For urgent matters, pls contact [EMAIL PROTECTED] Tel:
(65)63629461.
I am also Contactable at (65)97876648.


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

client ssl re-negotiation after invalidating session

[atul]

Is there a way in tomcat to re-negotiate client certificate after the http 
session has been invalidated (it had been successfully authenticated once 
before) in the app. i.e. without closing and starting a new client browser.
I tried accessing request attributes javax.servlet.request.X509Certificate and 
org.apache.coyote.request.X509certificate,
but it did not work.

I guess the old ssl socket is still around and tomact just returns the old 
authenticated client certificate without going to the browser. I have to 
restart the browser to get the client cert again.

* I need tomcat to ask for the client cert again (renegotiate) from the browser 
without restarting a new one. *

Any prompt help is really appreciated.


Thanks,


 

Get your own web address.  
Have a HUGE year through Yahoo! Small Business.
http://smallbusiness.yahoo.com/domains/?p=BESTDEAL

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

Re: client ssl re-negotiation after invalidating session

[Mark Thomas]

atul wrote:
> Is there a way in tomcat to re-negotiate client certificate after the http 
> session has been invalidated (it had been successfully authenticated once 
> before) in the app. i.e. without closing and starting a new client browser.
> I tried accessing request attributes javax.servlet.request.X509Certificate 
> and org.apache.coyote.request.X509certificate,
> but it did not work.

Please do not cross post.

Mark

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

[CVE-2007-1358] Apache Tomcat XSS vulnerability in Accept-Language header processing

[Mark Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

CVE-2007-1358: Apache Tomcat XSS vulnerability in Accept-Language
header processing

Severity:
Low (cross-site scripting)

Vendor:
The Apache Software Foundation

Versions Affected:
Tomcat 4.0.0 to 4.0.6
Tomcat 4.1.0 to 4.1.34
Tomcat 5.0.0 to 5.0.30
Tomcat 5.5.0 to 5.5.20
Tomcat 6.0.0 to 6.0.5

Description:
Web pages that display the Accept-Language header value sent by the
client are susceptible to a cross-site scripting attack if they assume
the Accept-Language header value conforms to RFC 2616. Under normal
circumstances this would not be possible to exploit, however older
versions of Flash player were known to allow carefully crafted
malicious Flash files to make requests with such custom headers.
Tomcat now ignores invalid values for Accept-Language headers that do
not conform to RFC 2616.

Mitigation:
1. Upgrade to fixed version
2. Escape values obtained from Accept-Language header before use.

Credit:
This issue was reported by Masato Anzai and Toshiharu Sugiyama.

References:
http://tomcat.apache.org/security.html

Mark Thomas



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGdxWMb7IeiTPGAkMRAgDgAJkBG6sVBDP/8yxGrZ7CqvEXPNW1mACgiL8M
CyWgpvE5125qciTSYPJbOgU=
=A84r
-END PGP SIGNATURE-

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