date:20090812

sunil chandran wrote:
 Hello Sir,
 I wish to confirm one more thing.
 The issue is SSL vulnerability. from the responses, i understood that i need 
 to upgrade to tomcat latest version. As per the team, it is recommended to go 
 for Tomcat 5 in our environment.
 my quesiton is:
 Is this vulernability solved in tomcat 5 version?
http://tomcat.apache.org/security-5.html

 Do i need to perform some additional stuff to avoid this vulnerability?
No.

Mark

 
 regardsSunil C
 --- On Tue, 11/8/09, Mark Thomas ma...@apache.org wrote:
 
 From: Mark Thomas ma...@apache.org
 Subject: Re: avoiding ssl vulnerabilities in tomcat
 To: Tomcat Users List users@tomcat.apache.org
 Date: Tuesday, 11 August, 2009, 4:55 PM
 
 sunil chandran wrote:
 Hello all,
   
 OK i will upgrade.
 But what all changes required to update to tomcat 5.
 what all changes reuired to upgrade to tomcat 4.1.40
 
 You may as well do the job properly and upgrade to 6.0.20.
 
 For you app? No changes should be required.
 
 For your Tomcat configuration? Start with the clean configuration
 provided with 6.0.20 and add any modifications you need. Be aware that
 the config has changed in particular:
 - the Logger element is no longer used
 - Resource configuration has changed
 
 See the docs for the details.
 
 Mark
 
 
 
   
   

 --- On Mon, 10/8/09, Caldarale, Charles R chuck.caldar...@unisys.com wrote:


 From: Caldarale, Charles R chuck.caldar...@unisys.com
 Subject: RE: avoiding ssl vulnerabilities in tomcat
 To: Tomcat Users List users@tomcat.apache.org
 Date: Monday, 10 August, 2009, 7:10 PM


 From: sunil chandran [mailto:sunilonweb2...@yahoo.co.in]
 Subject: Re: avoiding ssl vulnerabilities in tomcat

 Is there any patch provided so that i can still use the same version
 4.1.24 itself.
 No, you *must* upgrade.  Your reluctance to do so borders on the ridiculous.

 - Chuck


 THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
 MATERIAL and is thus for use only by the intended recipient. If you received 
 this in error, please contact the sender and delete the e-mail and its 
 attachments from all computers.



 Send free SMS to your Friends on Mobile from your Yahoo! Messenger. Download 
 Now! http://messenger.yahoo.com/download.php
 
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
 
 
 
   Yahoo! recommends that you upgrade to the new and safer Internet 
 Explorer 8. http://downloads.yahoo.com/in/internetexplorer/



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat not starting - No error messages seen

Anisha Parveen -X (anparvee - Infosys at Cisco) wrote:
 Hi all,
 
 I am trying to start tomcat 4.1.3 on Solaris. ps -ef | grep tomcat
 returns nothing.

4.1.3 is extremely old and the 4.1.x release is no longer supported.

I'd suggest starting again with 6.6.20

Mark




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Problem in configuring tomcat for PKCS 11 for HSM

Tk, Pramod (NSN - IN/Bangalore) wrote:
 Hello,
 
 I have configured apache-tomcat-6.0.20 for PKCS11 to use the keystore
 present on HSM(Hardware security Module) which is SCA6000 in my case.

I think you have found a bug but confirming this and then fixing it is
going to be somewhat complicated by not having access to a hardware
keystore.

I don't suppose you have a development box with similar hardware and a
test key that you'd be happy for someone to ssh into?

If not, we can the somewhat slower trial and error with patches approach.

Mark

 
 My Connector looks like this 
 
 Connector port=443 protocol=HTTP/1.1 SSLEnabled=true
maxThreads=150 scheme=https secure=true
  clientAuth=false sslProtocol=TLS
 protocols=TLSv1 
  algorithm=SunX509  
  keystore=NONE keystoreType=PKCS11
 keystoreProvider=SunPKCS11-SCA6000 keystorePass=X
 /
 
 This works fine by taking the a random certificate from the keystore.
 
 But,
 
 If I specify the keyAlias = SpecificCerificate , in the Connector I am
 getting the folling Exception
 
 java.security.KeyManagementException: FIPS mode: only SunJSSE
 KeyManagers may be used
   at
 com.sun.net.ssl.internal.ssl.SSLContextImpl.chooseKeyManager(Unknown
 Source)
   at
 com.sun.net.ssl.internal.ssl.SSLContextImpl.engineInit(Unknown Source)
   at javax.net.ssl.SSLContext.init(Unknown Source)
   at
 org.apache.tomcat.util.net.jsse.JSSESocketFactory.init(JSSESocketFactory
 .java:416)
   at
 org.apache.tomcat.util.net.jsse.JSSESocketFactory.createSocket(JSSESocke
 tFactory.java:131)
   at
 org.apache.tomcat.util.net.JIoEndpoint.init(JIoEndpoint.java:503)
   at
 org.apache.coyote.http11.Http11Protocol.init(Http11Protocol.java:176)
   at
 org.apache.catalina.connector.Connector.initialize(Connector.java:1058)
   at
 org.apache.catalina.core.StandardService.initialize(StandardService.java
 :677)
   at
 org.apache.catalina.core.StandardServer.initialize(StandardServer.java:7
 95)
   at org.apache.catalina.startup.Catalina.load(Catalina.java:535)
   at org.apache.catalina.startup.Catalina.load(Catalina.java:555)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
 Source)
   at java.lang.reflect.Method.invoke(Unknown Source)
   at
 org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:260)
   at
 org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:412)
 
 --
 Aug 11, 2009 11:33:12 PM org.apache.coyote.http11.Http11Protocol init
 SEVERE: Error initializing endpoint
 java.io.IOException: FIPS mode: only SunJSSE KeyManagers may be used
   at
 org.apache.tomcat.util.net.jsse.JSSESocketFactory.init(JSSESocketFactory
 .java:462)
   at
 org.apache.tomcat.util.net.jsse.JSSESocketFactory.createSocket(JSSESocke
 tFactory.java:131)
   at
 org.apache.tomcat.util.net.JIoEndpoint.init(JIoEndpoint.java:503)
   at
 org.apache.coyote.http11.Http11Protocol.init(Http11Protocol.java:176)
   at
 org.apache.catalina.connector.Connector.initialize(Connector.java:1058)
   at
 org.apache.catalina.core.StandardService.initialize(StandardService.java
 :677)
   at
 org.apache.catalina.core.StandardServer.initialize(StandardServer.java:7
 95)
   at org.apache.catalina.startup.Catalina.load(Catalina.java:535)
   at org.apache.catalina.startup.Catalina.load(Catalina.java:555)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
 Source)
   at java.lang.reflect.Method.invoke(Unknown Source)
   at
 org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:260)
   at
 org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:412)
 Aug 11, 2009 11:33:12 PM org.apache.catalina.startup.Catalina load
 SEVERE: Catalina.start
 LifecycleException:  Protocol handler initialization failed:
 java.io.IOException: FIPS mode: only SunJSSE KeyManagers may be used
   at
 org.apache.catalina.connector.Connector.initialize(Connector.java:1060)
   at
 org.apache.catalina.core.StandardService.initialize(StandardService.java
 :677)
   at
 org.apache.catalina.core.StandardServer.initialize(StandardServer.java:7
 95)
   at org.apache.catalina.startup.Catalina.load(Catalina.java:535)
   at org.apache.catalina.startup.Catalina.load(Catalina.java:555)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
 Source)
   at java.lang.reflect.Method.invoke(Unknown Source)

Re: Graceful Stop

2009-08-12 Thread jeffoule


This script is the catalina.sh officially packaged with tomcat.



jgroups wrote:
 
 Red hat linux:
 
 Here is the script:
 
 #!/bin/sh
 
 # 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.
 
 #
 -
 # Start/Stop Script for the CATALINA Server
 #
 # Environment Variable Prequisites
 #
 #   CATALINA_HOME   May point at your Catalina build directory.
 #
 #   CATALINA_BASE   (Optional) Base directory for resolving dynamic
 portions
 #   of a Catalina installation.  If not present, resolves
 to
 #   the same directory that CATALINA_HOME points to.
 #
 #   CATALINA_OPTS   (Optional) Java runtime options used when the start,
 #   or run command is executed.
 #
 #   CATALINA_TMPDIR (Optional) Directory path location of temporary
 directory
 #   the JVM should use (java.io.tmpdir).  Defaults to
 #   $CATALINA_BASE/temp.
 #
 #   JAVA_HOME   Must point at your Java Development Kit installation.
 #   Required to run the with the debug or javac
 argument.
 #
 #   JRE_HOMEMust point at your Java Development Kit installation.
 #   Defaults to JAVA_HOME if empty.
 #
 #   JAVA_OPTS   (Optional) Java runtime options used when the start,
 #   stop, or run command is executed.
 #
 #   JPDA_TRANSPORT  (Optional) JPDA transport used when the jpda start
 #   command is executed. The default is dt_socket.
 #
 #   JPDA_ADDRESS(Optional) Java runtime options used when the jpda
 start
 #   command is executed. The default is 8000.
 #
 #   JPDA_SUSPEND(Optional) Java runtime options used when the jpda
 start
 #   command is executed. Specifies whether JVM should
 suspend
 #   execution immediately after startup. Default is n.
 #
 #   JPDA_OPTS   (Optional) Java runtime options used when the jpda
 start
 #   command is executed. If used, JPDA_TRANSPORT,
 JPDA_ADDRESS,
 #   and JPDA_SUSPEND are ignored. Thus, all required jpda
 #   options MUST be specified. The default is:
 #
 #   -Xdebug -Xrunjdwp:transport=$JPDA_TRANSPORT,
 #  
 address=$JPDA_ADDRESS,server=y,suspend=$JPDA_SUSPEND
 #
 #   JSSE_HOME   (Optional) May point at your Java Secure Sockets
 Extension
 #   (JSSE) installation, whose JAR files will be added to
 the
 #   system class path used to start Tomcat.
 #
 #   CATALINA_PID(Optional) Path of the file which should contains the
 pid
 #   of catalina startup java process, when start (fork) is
 used
 #
 # $Id: catalina.sh 656834 2008-05-15 21:04:04Z markt $
 #
 -
 
 # OS specific support.  $var _must_ be set to either true or false.
 cygwin=false
 os400=false
 darwin=false
 case `uname` in
 CYGWIN*) cygwin=true;;
 OS400*) os400=true;;
 Darwin*) darwin=true;;
 esac
 
 # resolve links - $0 may be a softlink
 PRG=$0
 
 while [ -h $PRG ]; do
   ls=`ls -ld $PRG`
   link=`expr $ls : '.*- \(.*\)$'`
   if expr $link : '/.*'  /dev/null; then
 PRG=$link
   else
 PRG=`dirname $PRG`/$link
   fi
 done
 
 # Get standard environment variables
 PRGDIR=`dirname $PRG`
 
 # Only set CATALINA_HOME if not already set
 [ -z $CATALINA_HOME ]  CATALINA_HOME=`cd $PRGDIR/.. ; pwd`
 
 if [ -r $CATALINA_BASE/bin/setenv.sh ]; then
   . $CATALINA_BASE/bin/setenv.sh
 elif [ -r $CATALINA_HOME/bin/setenv.sh ]; then
   . $CATALINA_HOME/bin/setenv.sh
 fi
 
 # For Cygwin, ensure paths are in UNIX format before anything is touched
 if $cygwin; then
   [ -n $JAVA_HOME ]  JAVA_HOME=`cygpath --unix $JAVA_HOME`
   [ -n $JRE_HOME ]  JRE_HOME=`cygpath --unix $JRE_HOME`
   [ -n $CATALINA_HOME ]  CATALINA_HOME=`cygpath --unix
 $CATALINA_HOME`
   [ -n $CATALINA_BASE ]  CATALINA_BASE=`cygpath --unix
 $CATALINA_BASE`
   [ -n $CLASSPATH ]  CLASSPATH=`cygpath --path --unix $CLASSPATH`
   [ -n $JSSE_HOME ]  JSSE_HOME=`cygpath --absolute --unix
 $JSSE_HOME`
 fi
 
 # For OS400
 if $os400; then
   # Set job priority to standard for

Re: Problem in configuring tomcat for PKCS 11 for HSM

Mark Thomas wrote:
 Tk, Pramod (NSN - IN/Bangalore) wrote:
 Hello,

 I have configured apache-tomcat-6.0.20 for PKCS11 to use the keystore
 present on HSM(Hardware security Module) which is SCA6000 in my case.
 
 I think you have found a bug but confirming this and then fixing it is
 going to be somewhat complicated by not having access to a hardware
 keystore.

Scratch that. I have looked at the code some more and I see what the
problem is. The KeyManager interface provides no mechanism for
specifying a default alias. Therefore, if you specify an alias Tomcat
has to wrap each KeyManager to ensure that the correct alias is
returned. This wrapper is Tomcat code, not part of JSSE, and therefore
not part of the FIPS accreditation. Hence you see the error. I can't see
any way to code around this problem.

With no alias, the KeyManager is not wrapped but you get a random key.

Looking at the features of the SCA6000 [1], one of them is multiple
keystores. You'll need to configure a dedicated keystore for Tomcat with
the single key and not specify the alias in the connector.

Mark

[1]
http://www.sun.com/products/networking/sslaccel/suncryptoaccel6000/features.xml#anchor3


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

How to configure per-webapp logging

2009-08-12 Thread Markus Meyer


Hi,

I'd like to configure my webapp to log into a separate file. (Actually, 
I'd like to have two files, one with only the SEVERE messages and one 
with all messages, but let's start with an easy example here.)


This is a Debian 5.0 server.

The webapp is installed in 
/var/lib/tomcat5.5/webapps/productionserver_test, and I have created a 
file 
/var/lib/tomcat5.5/webapps/productionserver_test/WEB-INF/classes/logging.properties 
as per the tutorials with the following content:



handlers= org.apache.juli.FileHandler

org.apache.juli.FileHandler.level = ALL
org.apache.juli.FileHandler.directory = 
${catalina.base}/logs/productionserver_test

org.apache.juli.FileHandler.prefix = productionserver_test

com.gfii.productionserver.handlers = org.apache.juli.FileHandler


The class com.gfii.productionserver is the name of the logger. In the 
webapp, I call Logger.getLogger(com.gfii.productionserver) whenever I 
need to have access to the logger.


When I add this logging.properties file, this has two effects:

- Logging information for com.gfii.productionserver is not logged to 
the main Tomcat logs anymore

- The directory ${catalina.base}/logs/productionserver_test is created

However, no log files are created in this directory.

What am I doing wrong? Please let me know if you need more information.

Thanks in advance!


Markus


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: java.security.NoSuchProviderException: No provider configured for S/MIME

2009-08-12 Thread TomazM

TomazM wrote:
 1) Linux problem
 Env:
 OS: Linux version 2.6.18-128.1.16.el5PAE
 java: 1.5
 Tomcat: 6.0.18
 
 I'm sign mail with javamail-crypto and bouncycastle-smime, I put 
 $JAVA_HOME/jre/lib/ext/bcprov-jdk15-143.jar and in java.securety I add new 
 provider.
 
 When I'm runing application as stand alone it work(in eclipse and all jar's 
 in CLASSPATH).
 But when I'm trying as web application on Tomcat I get this
 
 error: java.security.NoSuchProviderException: No provider configured for 
 S/MIME
 
 
 2) XP problem
 Env:
 OS: Windows  XP
 java: 1.6.0_10
 Tomcat: 6.0.18
 
 I'm sign mail with javamail-crypto and bouncycastle-smime, I put 
 $JAVA_HOME/jre/lib/ext/bcprov-jdk16-143.jar and in java.securety I add new 
 provider.
 
 When I'm runing application as stand alone it work. But when I'm trying as 
 web application on Tomcat I get different error(no more problem whit provider)
 
 error: javax.activation.UnsupportedDataTypeException: no object DCH for MIME 
 type application/pkcs7-signature; name=smime.p7s; smime-type=signed-data
 
 
 I try tu put new activation.jar in $JAVA_HOME/jre/lib/ext/activation1.1.1.jar 
 but no luck.
 
 Have anybody any ideas?
 
 
 Regards Tomaz
 



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

tomcat connects to eso.apache.org

2009-08-12 Thread Joaquín Rodriguez-Guerra Urcelay

Hello all, I am using tomcat with liferay, and when uploading applications it 
is taking too much time. After using a sniffer to see the outgoing connections 
we found out that liferay was trying to access file-01.liferay.com to obtain 
files, but the firewall was not allowing the connections, whice was mking a 
delay. We configured liferay to block these connections, and uploading time 
decrement to the half (from 7 min to 3.5). But now, we are seeing that when 
uploading applications, there are still connections to eos.apache.org, probably 
by tomcat, blocked by the firewall, which are producing this delay. Do you know 
how can we block these connections that tomcat is doing to avoid the delay?? 
Thank you!
__
Este mensaje, y en su caso, cualquier fichero anexo al mismo,
 puede contener informacion clasificada por su emisor como confidencial
 en el marco de su Sistema de Gestion de Seguridad de la 
Informacion siendo para uso exclusivo del destinatario, quedando 
prohibida su divulgacion copia o distribucion a terceros sin la 
autorizacion expresa del remitente. Si Vd. ha recibido este mensaje 
 erroneamente, se ruega lo notifique al remitente y proceda a su borrado. 
Gracias por su colaboracion.
__
This message including any attachments may contain confidential 
information, according to our Information Security Management System,
 and intended solely for a specific individual to whom they are addressed.
 Any unauthorised copy, disclosure or distribution of this message
 is strictly forbidden. If you have received this transmission in error,
 please notify the sender immediately and delete it.
__

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

test

2009-08-12 Thread support_hockey


i will delete this after i test how to create a message  here...
-- 
View this message in context: 
http://www.nabble.com/test-tp24934739p24934739.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

test

2009-08-12 Thread support_hockey


i will delete this after i test how to create a message  here...
-- 
View this message in context: 
http://www.nabble.com/test-tp24934738p24934738.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: tomcat connects to eso.apache.org

Joaquín Rodriguez-Guerra Urcelay wrote:
 Hello all, I am using tomcat with liferay, and when uploading applications it 
 is taking too much time. After using a sniffer to see the outgoing 
 connections we found out that liferay was trying to access 
 file-01.liferay.com to obtain files, but the firewall was not allowing the 
 connections, whice was mking a delay. We configured liferay to block these 
 connections, and uploading time decrement to the half (from 7 min to 3.5). 
 But now, we are seeing that when uploading applications, there are still 
 connections to eos.apache.org, probably by tomcat, blocked by the firewall, 
 which are producing this delay. Do you know how can we block these 
 connections that tomcat is doing to avoid the delay?? Thank you!

That isn't Tomcat. It is your app or a library your app is using. My
money would be on an XML schema. Since you are sniffing traffic, what
URLs are being requested?

Mark



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: test

2009-08-12 Thread Konstantin Kolinko

2009/8/12 support_hockey antas.mis...@tcs.com:

 i will delete this after i test how to create a message  here...
 --
 View this message in context: 
 http://www.nabble.com/test-tp24934739p24934739.html
 Sent from the Tomcat - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org



It is not a forum. It is a mailing list.
You cannot delete an e-mail once that it is sent.

Please start here:
http://tomcat.apache.org/lists.html#tomcat-users


BTW, archived copies of your test mails:
http://markmail.org/thread/cfvxc3xdeqtjb6g6
http://markmail.org/thread/a35f3tabuc6ddzpm

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Tomcat 6 clustering and engine's defaulthost

2009-08-12 Thread Ossi

hi!

Looks like if configuring  a Tomcat 6 cluster Engine's and host's default
host must be localhost, ie.

Engine name=Catalina defaultHost=localhost
jvmRoute=private-tomcat1

 Host name=localhost appBase=webapps
unpackWARs=true autoDeploy=true
xmlValidation=false xmlNamespaceAware=false

If having something else than localhost, an error is logged:

2009-04-03 12:48:15,492 WARN [pool-2-thread-1]
(org.apache.catalina.ha.ClusterListener) Context manager doesn't
exist:private-tomcat1#

Since we are planning to run different Tomcat servers on the same box, each
with their own ip, so it would seem to be more convenient if Engine could
use the same address.

 Regards,
Ossi

change the default JSP index.jsp for ROOT context in Tomcat 6

I'm running Tomcat 6 on Linux and I want change the index.jsp of the ROOT 
context which is displayed by http://localhost:8080/.
For Tomcat 5 I could comment out the index_jsp mapping in web.xml for ROOT. The 
web.xml for the ROOT in Tomcat 6 doesn't contain such a mapping. So how could I 
remove the default JSP index.jsp which is called for http://localhost:8080/ for 
Tomcat 6?

Any help is welcome!
Regards,
Joerg



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: change the default JSP index.jsp for ROOT context in Tomcat 6

2009-08-12 Thread Pid


On 12/08/2009 14:26, Jörg Spilling wrote:

I'm running Tomcat 6 on Linux and I want change the index.jsp of the ROOT 
context which is displayed by http://localhost:8080/.
For Tomcat 5 I could comment out the index_jsp mapping in web.xml for ROOT. The 
web.xml for the ROOT in Tomcat 6 doesn't contain such a mapping. So how could I 
remove the default JSP index.jsp which is called for http://localhost:8080/ for 
Tomcat 6?

Any help is welcome!


Why not just replace the ROOT application with your own ROOT.war?

p


Regards,
Joerg



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

AW: change the default JSP index.jsp for ROOT context in Tomcat 6

I want no own ROOT application. I will disable the access to the manager 
application by using http://localhost:8080/. On Tomcat 5, I have disabled the 
mapping of index_jsp, I have renamed the index.jsp in ROOT/ to 
access_manager.jsp and I have created a new index.jsp which doesn't contain a 
link to the manager application. That's what I want have also on Tomcat 6 too: 
an empty index.jsp if http://localhost:8080/ is called and the possibility to 
access the original index.jsp with another name, like 
http://localhost:8080/original-index.jsp ...

Regards,
Joerg

-Ursprüngliche Nachricht-
Von: Pid [mailto:p...@pidster.com] 
Gesendet: Mittwoch, 12. August 2009 15:34
An: Tomcat Users List
Betreff: Re: change the default JSP index.jsp for ROOT context in Tomcat 6

On 12/08/2009 14:26, Jörg Spilling wrote:
 I'm running Tomcat 6 on Linux and I want change the index.jsp of the ROOT 
 context which is displayed by http://localhost:8080/.
 For Tomcat 5 I could comment out the index_jsp mapping in web.xml for ROOT. 
 The web.xml for the ROOT in Tomcat 6 doesn't contain such a mapping. So how 
 could I remove the default JSP index.jsp which is called for 
 http://localhost:8080/ for Tomcat 6?

 Any help is welcome!

Why not just replace the ROOT application with your own ROOT.war?

p

 Regards,
 Joerg



 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Why myApps classpath is tomcat/common

2009-08-12 Thread Lin Chun

Hi,
I have a java class packaged in a jar in  /myApp/WEB-INF/lib
In this class I have to get a resouce ,

ClassLoader.getSystemResource(CONFIG_FILE_NAME).toURI())


I get null of this, when I trace the pb I find that the current path of
class was tomcat/common but not myApp/WEB-INF/lib


regard,




-- 
-
Lin Chun
Samuel Goldwynhttp://www.brainyquote.com/quotes/authors/s/samuel_goldwyn.html
- I'm willing to admit that I may not always be right, but I am never
wrong.

RE: change the default JSP index.jsp for ROOT context in Tomcat 6

 From: Jörg Spilling [mailto:spill...@equicon.de]
 Subject: AW: change the default JSP index.jsp for ROOT context in
 Tomcat 6

 I want no own ROOT application. I will disable the access to the
 manager application by using http://localhost:8080/. On Tomcat 5, I
 have disabled the mapping of index_jsp, I have renamed the index.jsp in
 ROOT/ to access_manager.jsp and I have created a new index.jsp which
 doesn't contain a link to the manager application. That's what I want
 have also on Tomcat 6 too: an empty index.jsp if
 http://localhost:8080/ is called and the possibility to access the
 original index.jsp with another name, like
 http://localhost:8080/original-index.jsp ...

The default web application in Tomcat 6 uses index.html, not index.jsp, as the 
home page.  Tomcat 6 also does not pre-compile index.jsp as 5.5 did.  If you 
delete or rename both index.html and index.jsp, you'll get the odd arrangement 
you're trying to create.

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

AW: change the default JSP index.jsp for ROOT context in Tomcat 6

Chuck,

that's it - but only, if the compiled index*.java/*.class files are removed 
from the work directory ;-(

(and it's not odd: it's a security hint - simply hide it!)

Cheers,
Joerg 

-Ursprüngliche Nachricht-
Von: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] 
Gesendet: Mittwoch, 12. August 2009 15:51
An: Tomcat Users List
Betreff: RE: change the default JSP index.jsp for ROOT context in Tomcat 6

 From: Jörg Spilling [mailto:spill...@equicon.de]
 Subject: AW: change the default JSP index.jsp for ROOT context in
 Tomcat 6
 
 I want no own ROOT application. I will disable the access to the
 manager application by using http://localhost:8080/. On Tomcat 5, I
 have disabled the mapping of index_jsp, I have renamed the index.jsp in
 ROOT/ to access_manager.jsp and I have created a new index.jsp which
 doesn't contain a link to the manager application. That's what I want
 have also on Tomcat 6 too: an empty index.jsp if
 http://localhost:8080/ is called and the possibility to access the
 original index.jsp with another name, like
 http://localhost:8080/original-index.jsp ...

The default web application in Tomcat 6 uses index.html, not index.jsp, as the 
home page.  Tomcat 6 also does not pre-compile index.jsp as 5.5 did.  If you 
delete or rename both index.html and index.jsp, you'll get the odd arrangement 
you're trying to create.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: change the default JSP index.jsp for ROOT context in Tomcat 6

 From: Jörg Spilling [mailto:spill...@equicon.de]
 Subject: AW: change the default JSP index.jsp for ROOT context in
 Tomcat 6

 (and it's not odd: it's a security hint - simply hide it!)

If you think that constitutes security, you're fooling yourself.  Security by 
obscurity is an invitation to hackers.

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: tomcat connects to eso.apache.org

2009-08-12 Thread Joaquín Rodriguez-Guerra Urcelay

Thanks Mark. Since the connection is never established with eos.apache.org, we 
can not know the urls that liferay is requesting, right? So, if tomcat is not 
the responsible for those connections, I guess there isn't any way to configure 
tomcat to avoid them, right? Thanks for your help.

-Mensaje original-
De: Mark Thomas [mailto:ma...@apache.org] 
Enviado el: miércoles, 12 de agosto de 2009 13:45
Para: Tomcat Users List
Asunto: Re: tomcat connects to eso.apache.org

Joaquín Rodriguez-Guerra Urcelay wrote:
 Hello all, I am using tomcat with liferay, and when uploading applications it 
 is taking too much time. After using a sniffer to see the outgoing 
 connections we found out that liferay was trying to access 
 file-01.liferay.com to obtain files, but the firewall was not allowing the 
 connections, whice was mking a delay. We configured liferay to block these 
 connections, and uploading time decrement to the half (from 7 min to 3.5). 
 But now, we are seeing that when uploading applications, there are still 
 connections to eos.apache.org, probably by tomcat, blocked by the firewall, 
 which are producing this delay. Do you know how can we block these 
 connections that tomcat is doing to avoid the delay?? Thank you!

That isn't Tomcat. It is your app or a library your app is using. My
money would be on an XML schema. Since you are sniffing traffic, what
URLs are being requested?

Mark



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


__
Este mensaje, y en su caso, cualquier fichero anexo al mismo,
 puede contener informacion clasificada por su emisor como confidencial
 en el marco de su Sistema de Gestion de Seguridad de la 
Informacion siendo para uso exclusivo del destinatario, quedando 
prohibida su divulgacion copia o distribucion a terceros sin la 
autorizacion expresa del remitente. Si Vd. ha recibido este mensaje 
 erroneamente, se ruega lo notifique al remitente y proceda a su borrado. 
Gracias por su colaboracion.
__
This message including any attachments may contain confidential 
information, according to our Information Security Management System,
 and intended solely for a specific individual to whom they are addressed.
 Any unauthorised copy, disclosure or distribution of this message
 is strictly forbidden. If you have received this transmission in error,
 please notify the sender immediately and delete it.
__

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: avoiding ssl vulnerabilities in tomcat

 From: sunil chandran [mailto:sunilonweb2...@yahoo.co.in]
 Subject: Re: avoiding ssl vulnerabilities in tomcat

 As per the team, it is recommended to go for Tomcat 5
 in our environment.

Why would you waste your time with Tomcat 5?  If you're going to upgrade from 
4, move to the version that's being actively maintained - Tomcat 6.0.x.

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

AW: change the default JSP index.jsp for ROOT context in Tomcat 6

Chuck,

I will not start a discussion about security ...
It's only an additional simple trick to hide it to some curious people in the 
inner ring, like students and so on.
The Tomcat itself is by it's port 8080 not accessible from outside.

;-)

-Ursprüngliche Nachricht-
Von: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] 
Gesendet: Mittwoch, 12. August 2009 16:10
An: Tomcat Users List
Betreff: RE: change the default JSP index.jsp for ROOT context in Tomcat 6

 From: Jörg Spilling [mailto:spill...@equicon.de]
 Subject: AW: change the default JSP index.jsp for ROOT context in
 Tomcat 6
 
 (and it's not odd: it's a security hint - simply hide it!)

If you think that constitutes security, you're fooling yourself.  Security by 
obscurity is an invitation to hackers.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: tomcat connects to eso.apache.org

Joaquín Rodriguez-Guerra Urcelay wrote:
 Thanks Mark. Since the connection is never established with eos.apache.org, 
 we can not know the urls that liferay is requesting, right? So, if tomcat is 
 not the responsible for those connections, I guess there isn't any way to 
 configure tomcat to avoid them, right? Thanks for your help.

So run your app on a box that does have access to www.apache.org and see
what happens.

You could also take a thread dump whilst it is hanging to see what code
is trying to make the connection(s). That should point you at the right
part of the source code.

Mark

 
 -Mensaje original-
 De: Mark Thomas [mailto:ma...@apache.org] 
 Enviado el: miércoles, 12 de agosto de 2009 13:45
 Para: Tomcat Users List
 Asunto: Re: tomcat connects to eso.apache.org
 
 Joaquín Rodriguez-Guerra Urcelay wrote:
 Hello all, I am using tomcat with liferay, and when uploading applications 
 it is taking too much time. After using a sniffer to see the outgoing 
 connections we found out that liferay was trying to access 
 file-01.liferay.com to obtain files, but the firewall was not allowing the 
 connections, whice was mking a delay. We configured liferay to block these 
 connections, and uploading time decrement to the half (from 7 min to 3.5). 
 But now, we are seeing that when uploading applications, there are still 
 connections to eos.apache.org, probably by tomcat, blocked by the firewall, 
 which are producing this delay. Do you know how can we block these 
 connections that tomcat is doing to avoid the delay?? Thank you!
 
 That isn't Tomcat. It is your app or a library your app is using. My
 money would be on an XML schema. Since you are sniffing traffic, what
 URLs are being requested?
 
 Mark
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
 
 __
 Este mensaje, y en su caso, cualquier fichero anexo al mismo,
  puede contener informacion clasificada por su emisor como confidencial
  en el marco de su Sistema de Gestion de Seguridad de la 
 Informacion siendo para uso exclusivo del destinatario, quedando 
 prohibida su divulgacion copia o distribucion a terceros sin la 
 autorizacion expresa del remitente. Si Vd. ha recibido este mensaje 
  erroneamente, se ruega lo notifique al remitente y proceda a su borrado. 
 Gracias por su colaboracion.
 __
 This message including any attachments may contain confidential 
 information, according to our Information Security Management System,
  and intended solely for a specific individual to whom they are addressed.
  Any unauthorised copy, disclosure or distribution of this message
  is strictly forbidden. If you have received this transmission in error,
  please notify the sender immediately and delete it.
 __
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Tomcat 6 clustering and engine's defaulthost

 From: Ossi [mailto:los...@gmail.com]
 Subject: Tomcat 6 clustering and engine's defaulthost

 Looks like if configuring  a Tomcat 6 cluster Engine's and host's
 default host must be localhost, ie.

 If having something else than localhost, an error is logged:
 2009-04-03 12:48:15,492 WARN [pool-2-thread-1]
 (org.apache.catalina.ha.ClusterListener) Context manager doesn't
 exist:private-tomcat1#

It would be more informative if you posted the configuration that produces the 
error rather than one that doesn't.

 Since we are planning to run different Tomcat servers on the same box,
 each with their own ip, so it would seem to be more convenient if Engine
 could use the same address.

The name of the Host has nothing to do with the IP address it's listening on. 
 Again, post the server.xml you're having trouble with.

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: avoiding ssl vulnerabilities in tomcat

2009-08-12 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sunil,

On 8/12/2009 3:12 AM, sunil chandran wrote:
 The issue is SSL vulnerability. from the responses, i understood that
 i need to upgrade to tomcat latest version. As per the team, it is
 recommended to go for Tomcat 5 in our environment.

With all due respect to your team, I think they are making a mistake.
Either of these are better choices in my opinion:

1. Upgrade to the latest version of 4.1.x, which is 4.1.40. This will
   provide the least headache because you will be staying on your
   current Tomcat version, just improving your patch level.
   Plan to upgrade to a newer release of Tomcat in the future.

2. Upgrade directly to Tomcat 6 without making a stop at Tomcat 5.5.
   If you are going to upgrade major versions, there is absolutely
   no reason for you to go to Tomcat 5.5, which will eventually have
   support dropped just like Tomcat 4.1 did.

 my quesiton is: Is this vulernability solved in tomcat 5 version?

Sheesh. Did you read the CVE description?
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2007-1858

It clearly says that Tomcat 5.5 is vulnerable through 5.5.17 (which is
inaccurate: the fix for this is documented to be in 5.5.17). Make sure
you are using a version later than that if you must use 5.5.

Now, before you ask about what version of Tomcat 6 you need in order to
avoid this vulnerability, let me help you:

1. Go to Tomcat's web site (http://tomcat.apache.org/)
2. Follow the link that says Security
3. Pick your major Tomcat version
4. Read the fixes. Each one mentions the CVE identifier, a description
   of the problem, the versions of Tomcat affected, and the version in
   which a fix appears.

All this information is easy to find on the Tomcat web site. Please read
the documentation before continuing to ask questions such as these.

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

iEYEARECAAYFAkqC1ZUACgkQ9CaO5/Lv0PCU0ACfRTpiCEBpHAPCHyU0zB9nEX7s
ZSEAoJb6rG+4aQCzX2iyP9B3VqLODGFX
=z6Bp
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: avoiding ssl vulnerabilities in tomcat

2009-08-12 Thread Jeffrey Janner


***  NOTICE  *
This message is intended for the use of the individual or entity to which
it is addressed and may contain information that is privileged,
confidential, and exempt from disclosure under applicable law.  If the
reader of this message is not the intended recipient or the employee or
agent responsible for delivering this message to the intended recipient,
you are hereby notified that any dissemination, distribution, or copying
of this communication is strictly prohibited.  If you have received this
communication in error, please notify us immediately by reply or by
telephone (call us collect at 512-343-9100) and immediately delete this
message and all its attachments.
---BeginMessage---
Just to clarify some things:  This CVE only applies to the default SSL 
connector functionality.  It doesn't apply to the APR/OpenSSL connector. 
Correct?
Jeff

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Wednesday, August 12, 2009 9:46 AM
To: Tomcat Users List
Subject: Re: avoiding ssl vulnerabilities in tomcat

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sunil,

On 8/12/2009 3:12 AM, sunil chandran wrote:
 The issue is SSL vulnerability. from the responses, i understood that
 i need to upgrade to tomcat latest version. As per the team, it is
 recommended to go for Tomcat 5 in our environment.

With all due respect to your team, I think they are making a mistake.
Either of these are better choices in my opinion:

1. Upgrade to the latest version of 4.1.x, which is 4.1.40. This will
   provide the least headache because you will be staying on your
   current Tomcat version, just improving your patch level.
   Plan to upgrade to a newer release of Tomcat in the future.

2. Upgrade directly to Tomcat 6 without making a stop at Tomcat 5.5.
   If you are going to upgrade major versions, there is absolutely
   no reason for you to go to Tomcat 5.5, which will eventually have
   support dropped just like Tomcat 4.1 did.

 my quesiton is: Is this vulernability solved in tomcat 5 version?

Sheesh. Did you read the CVE description?
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2007-1858

It clearly says that Tomcat 5.5 is vulnerable through 5.5.17 (which is
inaccurate: the fix for this is documented to be in 5.5.17). Make sure
you are using a version later than that if you must use 5.5.

Now, before you ask about what version of Tomcat 6 you need in order to
avoid this vulnerability, let me help you:

1. Go to Tomcat's web site (http://tomcat.apache.org/)
2. Follow the link that says Security
3. Pick your major Tomcat version
4. Read the fixes. Each one mentions the CVE identifier, a description
   of the problem, the versions of Tomcat affected, and the version in
   which a fix appears.

All this information is easy to find on the Tomcat web site. Please read
the documentation before continuing to ask questions such as these.

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

iEYEARECAAYFAkqC1ZUACgkQ9CaO5/Lv0PCU0ACfRTpiCEBpHAPCHyU0zB9nEX7s
ZSEAoJb6rG+4aQCzX2iyP9B3VqLODGFX
=z6Bp
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


---End Message---

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Log4j vs JULI configuration discrepancy

Caldarale, Charles R chuck.caldar...@unisys.com wrote in message
news:0aae5ab84b013e45a7b61cb66943c17229b6492...@usea-exch7.na.uis.unisys.com...
 I don't understand why when using Juli anything that webapp's log4j
 logs to Stdout gets logged to a file, however, when using log4j with
 tomcat this behaviour isn't replicated.

 Note that catalina.out isn't actually being logged to; the Tomcat startup
 script simply redirects stdout and stderr to this file.
 I don't know what happens to System.out and System.err when log4j is in
 the game.

 Are you using swallowOutput in your Context element?

No.  Am actually a little confused by the docs on the swallowOutput param. 
From what I would understand from the param name by iteslf, it would imply 
that std output from the context is ignored/swallowed.  But from reading the 
docs, it says:   If the value of this flag is true, the bytes output to 
System.out and System.err by the web application will be redirected to the 
web application logger.  Which makes me think that if it is true, the the 
web logger is used to log the output?

Just to be safe, I added it in an tried to turn it to true and false.  False 
made no difference at all (as expected since it is the default setting). 
Setting it to true caused no log files to be genereated at all.  Really 
strange  even more confusing.


Anyone have any ideas why the java logger and log4j would work differently
when trying to log the root loggers?  On a similar note, is there a way in
that case to log anything a context logs to stdout to individual files?

The goal would be to have all stdout from context1 logged to context1.log,
anything from context b to contextb.log, etc...

Thanks!

Eric





-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Why myApps classpath is tomcat/common

2009-08-12 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Lin,

On 8/12/2009 9:43 AM, Lin Chun wrote:
 I have a java class packaged in a jar in  /myApp/WEB-INF/lib
 In this class I have to get a resouce ,
 
 ClassLoader.getSystemResource(CONFIG_FILE_NAME).toURI())

Note that this uses the system ClassLoader to locate resources. I
suspect the CLASSPATH for that loader is something like
/opt/sun-jdk-x-y-z/lib/rt.jar plus a few other things. No Tomcat stuff.
No webapp libraries or WEB-INF/classes or anything like that.

 I get null of this, when I trace the pb I find that the current path of
 class was tomcat/common but not myApp/WEB-INF/lib

Do you mean that the current working directory of the JVM process is
tomcat/common? That's not surprising: Tomcat probably never changes its
working directory for any reason.

The CWD is pretty much irrelevant if you want to load things from the
ClassLoader.

I don't think you want to use the system ClassLoader, so let me suggest
an alternative:

InputStream configFile = this.getClass().getClassLoader()
  .getResourceAsStream(CONFIG_FILE_NAME);

This will work if your config file is rooted in your webapp's root (like
webapps/myApp). If your config file is located in
.../webapps/myApp/WEB-INF/config.xml then you want to set
CONFIG_FILE_NAME to /WEB-INF/config.xml.

Remember that the input stream returned from getResourceAsStream can be
null if the resource is not found (instead of an exception being
thrown), so you should check the return value before using it.

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

iEYEARECAAYFAkqC14oACgkQ9CaO5/Lv0PAd6ACdFF4jNr2FUn60Dm25HQgmbESk
tioAnjFD8a4hHFjphOWV0IV9vmBN/A2c
=mowI
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Why myApps classpath is tomcat/common

 From: Christopher Schultz [mailto:ch...@christopherschultz.net]
 Subject: Re: Why myApps classpath is tomcat/common

 Note that this uses the system ClassLoader to locate resources. I
 suspect the CLASSPATH for that loader is something like
 /opt/sun-jdk-x-y-z/lib/rt.jar plus a few other things.

No, the system classloader is the one used to load the primary application 
classes; when running Tomcat, it normally references Tomcat's bin/bootstrap.jar 
file plus the jars linked from that one via META-INF.  The rt.jar and other JRE 
jars are handled by the JVM's bootstrap (aka null) classloader.

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

How to add more alias to host in tomcat

2009-08-12 Thread sumanth kollipara


 I need to create a alias for host in tomcat, lot of alias need to create.
 We have more than 500 users are using the web application. Each user should
 have saparate url but all r going to use same application. I thought i can
 use alias but how to create alias like' *.xyz.com'. In the place of ''
 client name has to come. Any body can suggest me solutions for this.
 Can i add wild chatacter to alias in host.



 exmaple abc.xyz.com, in this 'abc' can become any thing. Is there any
 thing to complete this or shell we pass like '*.xyz.com'(its not working).

 Thanks
 Sumanth

Re: Log4j vs JULI configuration discrepancy

Mark Thomas ma...@apache.org wrote in message 
news:4a7c9110.50...@apache.org...
 Eric B. wrote:
 Is there a workaround for this, or just one of those things that you have 
 to
 learn to live with?

 In catalina.properties, modify the following entry as shown:
 common.loader=${catalina.base}/lib,${catalina.home}/lib,${catalina.home}/lib/*.jar

 then you can place log4j.properties in CATALINA_BASE/lib

Another really strange result.  If I delete the logging.properties in 
CATALINA_BASE/conf, I get the following error msg:
Exception in thread main java.lang.NoClassDefFoundError:
Caused by: java.lang.ClassNotFoundException:
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
Could not find the main class: .  Program will exit.

Not quite sure why - I looked at the startup script and it is supposed to 
ignore it if missing, so not sure why I would be getting the 
ClassNotFoundException.  So far, my workaround has been to use an empty 
logging.properties, and tomcat launches.

Weird?

Eric




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: avoiding ssl vulnerabilities in tomcat

2009-08-12 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jeff,

(Strange... to me, your message looked like an attachment to the
security notice that would typically be put at the end of a message.
When I tried to reply to that, all the characters got all wonky. At
least coy-paste still works :)

On 8/12/2009 10:51 AM, Jeffrey Janner wrote:
 Just to clarify some things:  This CVE only applies to the default
 SSL connector functionality.  It doesn't apply to the APR/OpenSSL
 connector. Correct?

I would guess not, since APR uses openssl which has its own default set
of ciphers. On the other hand, Tomcat could override the default set of
ciphers when configuring APR at runtime.

I can't seem to find this bug listed in bugzilla for any version of
Tomcat, so I can't see which commit fixed it (and whether it included
connectors other than Coyote). I also looked at the release notes, but
they don't include a changelog. The changelog itself for Tomcat 5.5 does
not contain the text 1858. The only thing I can find in the changelog
is this note under 5.5.17 which is listed as a fix without a bug number:


Make the default cipher suites available for SSL the same as the set of
cipher suites enabled by default rather than the set of all cipher
suites. This prevents ciphers suites that do not provide confidentiality
protection and/or server authentication being used by default. (markt)


Tomcat 6.0 does not appear to suffer from this vulnerability, and there
does not appear to be a changelog for Tomcat 4 (at least not easily
accessible from the web site).

Fortunately, GI/M/F:

http://archive.apache.org/dist/tomcat/tomcat-4/v4.1.40/RELEASE-NOTES-4.1.txt

...though I can't find anything in there :(

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

iEYEARECAAYFAkqC3BIACgkQ9CaO5/Lv0PDHsACgrKo9iE3r4dX/8nbbMFH1szRX
AvQAni40g61cQnBe4oEmgd51SnICMZ3c
=9m0c
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: avoiding ssl vulnerabilities in tomcat

2009-08-12 Thread Martin Gainty


Jeff-
the first patch (for WEB-INF) was supposed to be fixed for 6.0.20
http://svn.apache.org/viewvc?view=revrevision=734734

after re-implementing your webapps to TC 6.0.20
please let us know if you have a corner case which is able to bypass this patch

as this is an important patch feel free to ping me offline 
thanks,
Martin Gainty 
__ 
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
 
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem 
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. 
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung 
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez 
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est 
interdite. Ce message sert à l'information seulement et n'aura pas n'importe 
quel effet légalement obligatoire. Étant donné que les email peuvent facilement 
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité 
pour le contenu fourni.




Subject: RE: avoiding ssl vulnerabilities in tomcat
Date: Wed, 12 Aug 2009 09:51:30 -0500
From: jeffrey.jan...@polydyne.com
To: users@tomcat.apache.org





 




***  NOTICE  *

This message is intended for the use of the individual or entity to which 

it is addressed and may contain information that is privileged, 

confidential, and exempt from disclosure under applicable law.  If the 

reader of this message is not the intended recipient or the employee or 

agent responsible for delivering this message to the intended recipient, 

you are hereby notified that any dissemination, distribution, or copying 

of this communication is strictly prohibited.  If you have received this 

communication in error, please notify us immediately by reply or by 

telephone (call us collect at 512-343-9100) and immediately delete this 

message and all its attachments.



--Forwarded Message Attachment--
Subject: RE: avoiding ssl vulnerabilities in tomcat
Date: Wed, 12 Aug 2009 09:51:30 -0500
From: jeffrey.jan...@polydyne.com
To: users@tomcat.apache.org

Just to clarify some things:  This CVE only applies to the default SSL 
connector functionality.  It doesn't apply to the APR/OpenSSL connector. 
Correct?
Jeff
 
-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Wednesday, August 12, 2009 9:46 AM
To: Tomcat Users List
Subject: Re: avoiding ssl vulnerabilities in tomcat
 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
Sunil,
 
On 8/12/2009 3:12 AM, sunil chandran wrote:
 The issue is SSL vulnerability. from the responses, i understood that
 i need to upgrade to tomcat latest version. As per the team, it is
 recommended to go for Tomcat 5 in our environment.
 
With all due respect to your team, I think they are making a mistake.
Either of these are better choices in my opinion:
 
1. Upgrade to the latest version of 4.1.x, which is 4.1.40. This will
   provide the least headache because you will be staying on your
   current Tomcat version, just improving your patch level.
   Plan to upgrade to a newer release of Tomcat in the future.
 
2. Upgrade directly to Tomcat 6 without making a stop at Tomcat 5.5.
   If you are going to upgrade major versions, there is absolutely
   no reason for you to go to Tomcat 5.5, which will eventually have
   support dropped just like Tomcat 4.1 did.
 
 my quesiton is: Is this vulernability solved in tomcat 5 version?
 
Sheesh. Did you read the CVE description?
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2007-1858
 
It clearly says that Tomcat 5.5 is vulnerable through 5.5.17 (which is
inaccurate: the fix for this is documented to be in 5.5.17). Make sure
you are using a version later than that if you must use 5.5.
 
Now, before you ask about what version of Tomcat 6 you need in order to
avoid this vulnerability, let me help you:
 
1. Go to Tomcat's web site (http://tomcat.apache.org/)
2. Follow the link that says Security
3. Pick your major Tomcat version
4. Read the fixes. Each one mentions the CVE identifier, a description
   of the problem, the versions of Tomcat affected, and the version in
   which a fix appears.
 
All this information is easy to find on the Tomcat web site. Please read
the documentation before continuing to ask questions such as these.
 
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iEYEARECAAYFAkqC1ZUACgkQ9CaO5/Lv0PCU0ACfRTpiCEBpHAPCHyU0zB9nEX7s
ZSEAoJb6rG+4aQCzX2iyP9B3VqLODGFX
=z6Bp
-END PGP

RE: avoiding ssl vulnerabilities in tomcat

2009-08-12 Thread Jeffrey Janner

Chris -
(I just did a reply in Outlook and this is how it got packaged. Didn't look 
that way to me, but got it that way on the send-back.  Either Exchange or my 
email filter - which adds the confidentialiy footer - did this.)

I figured it was only with the regular.  Just wanted a clarification in case 
some folks were thinking it applied to the native libraries (APR). I've noticed 
a lot of folks confuse the two on this list.

Also it was a slight prompt to the original poster that perhaps he should 
install the native libraries when he does finally go to 6.x.  IIRC, they are 
not available to 4.x.
Jeff

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 

Jeff,

(Strange... to me, your message looked like an attachment to the
security notice that would typically be put at the end of a message.
When I tried to reply to that, all the characters got all wonky. At
least coy-paste still works :)

On 8/12/2009 10:51 AM, Jeffrey Janner wrote:
 Just to clarify some things:  This CVE only applies to the default
 SSL connector functionality.  It doesn't apply to the APR/OpenSSL
 connector. Correct?

I would guess not, since APR uses openssl which has its own default set
of ciphers. On the other hand, Tomcat could override the default set of
ciphers when configuring APR at runtime.


***  NOTICE  *
This message is intended for the use of the individual or entity to which 
it is addressed and may contain information that is privileged, 
confidential, and exempt from disclosure under applicable law.  If the 
reader of this message is not the intended recipient or the employee or 
agent responsible for delivering this message to the intended recipient, 
you are hereby notified that any dissemination, distribution, or copying 
of this communication is strictly prohibited.  If you have received this 
communication in error, please notify us immediately by reply or by 
telephone (call us collect at 512-343-9100) and immediately delete this 
message and all its attachments.

RE: Setting Context Path in Tomcat

2009-08-12 Thread carbotex

Sorry, I got too excited. I'm running Tomcat 5.5.27. Thank you Charles for
you quick response.

Caldarale, Charles R wrote:

 From: carbotex [mailto:carbo...@gmail.com]
 Subject: Setting Context Path in Tomcat

 How do one go about setting tomcat in this kind of environment?

 First by telling us what version of Tomcat you're using.  Since you didn't
 bother to do that, I'll base the response on 6.0.20.

 http://www.clienthost.com/group1/app1/index.jsp
 http://www.clienthost.com/group1/app2/index.jsp
 http://www.clienthost.com/group1/app3/index.jsp

 Change the names of the .war files to group1#app1.war, group1#app2.war,
 and group1#app3.war, and place them in the webapps directory.

 I tried to set the Context path to /group1/app1 but 
 it doesn't work either.

 The path attribute for a Context element is not allowed in most
 situations in any reasonably recent version of Tomcat.

  - Chuck

 THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
 MATERIAL and is thus for use only by the intended recipient. If you
 received this in error, please contact the sender and delete the e-mail
 and its attachments from all computers.

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

-- 
View this message in context: 
http://www.nabble.com/Setting-Context-Path-in-Tomcat-tp24927313p24939514.html
Sent from the Tomcat - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Precompiled binaries for APR?

Hi,

Is there any reason why there aren't any precompiled binaries available for 
APR for Linux/Tomcat?  I have the apr package installed (that provides the 
libapr), but it seems as though I need to manually compile libtcnative 
library.  Does that lib exist precompiled anywhere?  Is there a particular 
reason why it does not?

I'm trying to set up stripped down production servers with as few dev tools 
on them as possible.  To compile libtcnative myself would mean setting up a 
new machine just for compilation purposes, and then manually copying over 
the lib.  Any way around that?

Am running Tomcat 6.0.18 on CentOS 5.3 Linux x86_64

Thanks,

Eirc




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Why myApps classpath is tomcat/common

2009-08-12 Thread Lin Chun

hi chris
I've turned to

this.getClass().getClassLoader().getResource()
Thread.currentThread().getClassContext().getResource()

they were all pointed to tomcat/common
finally I uncompressed the jar to /myApps/WEB-INF/classes, that solved the
problem.
i follow the doc of tomcat,  the jars under /WEB-INF/lib are not loaded by
COMMON LOADER,I still don't know why the classpath is in common

Re,

On Wed, Aug 12, 2009 at 4:54 PM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Lin,

 On 8/12/2009 9:43 AM, Lin Chun wrote:
  I have a java class packaged in a jar in  /myApp/WEB-INF/lib
  In this class I have to get a resouce ,
 
  ClassLoader.getSystemResource(CONFIG_FILE_NAME).toURI())

 Note that this uses the system ClassLoader to locate resources. I
 suspect the CLASSPATH for that loader is something like
 /opt/sun-jdk-x-y-z/lib/rt.jar plus a few other things. No Tomcat stuff.
 No webapp libraries or WEB-INF/classes or anything like that.

  I get null of this, when I trace the pb I find that the current path of
  class was tomcat/common but not myApp/WEB-INF/lib

 Do you mean that the current working directory of the JVM process is
 tomcat/common? That's not surprising: Tomcat probably never changes its
 working directory for any reason.

 The CWD is pretty much irrelevant if you want to load things from the
 ClassLoader.

 I don't think you want to use the system ClassLoader, so let me suggest
 an alternative:

 InputStream configFile = this.getClass().getClassLoader()
  .getResourceAsStream(CONFIG_FILE_NAME);

 This will work if your config file is rooted in your webapp's root (like
 webapps/myApp). If your config file is located in
 .../webapps/myApp/WEB-INF/config.xml then you want to set
 CONFIG_FILE_NAME to /WEB-INF/config.xml.

 Remember that the input stream returned from getResourceAsStream can be
 null if the resource is not found (instead of an exception being
 thrown), so you should check the return value before using it.

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

 iEYEARECAAYFAkqC14oACgkQ9CaO5/Lv0PAd6ACdFF4jNr2FUn60Dm25HQgmbESk
 tioAnjFD8a4hHFjphOWV0IV9vmBN/A2c
 =mowI
 -END PGP SIGNATURE-

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org




-- 
-
Lin Chun
Joan Crawfordhttp://www.brainyquote.com/quotes/authors/j/joan_crawford.html
- I, Joan Crawford, I believe in the dollar. Everything I earn, I
spend.

RE: Setting Context Path in Tomcat

 From: carbotex [mailto:carbo...@gmail.com]
 Subject: RE: Setting Context Path in Tomcat

 I'm running Tomcat 5.5.27.

For that level, it's a bit more complicated.  Instead of just renaming the .war 
files, you have to deploy them somewhere *outside* of the Host appBase 
directory, and create a Context element for each in 
conf/Catalina/[host]/[appName].xml.  (In your case, appName would be 
group1#app1, group1#app2, group1#app3.)  Inside each Context element, include 
a docBase attribute that points to the location of the respective .war file.

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Why myApps classpath is tomcat/common

 From: Lin Chun [mailto:franks1...@gmail.com]
 Subject: Re: Why myApps classpath is tomcat/common

 this.getClass().getClassLoader().getResource()
 Thread.currentThread().getClassContext().getResource()

 they were all pointed to tomcat/common

How did you determine that they were all pointed to tomcat/common?  (Please be 
very specific.)

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Setting Context Path in Tomcat

2009-08-12 Thread Konstantin Kolinko

2009/8/12 Caldarale, Charles R chuck.caldar...@unisys.com:
 From: carbotex [mailto:carbo...@gmail.com]
 Subject: RE: Setting Context Path in Tomcat

 I'm running Tomcat 5.5.27.

 For that level, it's a bit more complicated.

Chuck, that feature has already been ported to 5.5. It is mentioned as
44021, 43013: Add support for # to signify multi-level contexts for
directories and wars.
in  http://tomcat.apache.org/tomcat-5.5-doc/changelog.html

  Instead of just renaming the .war files, you have to deploy them somewhere 
 *outside* of the Host appBase directory, and create a Context element for 
 each in conf/Catalina/[host]/[appName].xml.  (In your case, appName would be 
 group1#app1, group1#app2, group1#app3.)  Inside each Context element, 
 include a docBase attribute that points to the location of the respective 
 .war file.

  - Chuck

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Setting Context Path in Tomcat

 From: Konstantin Kolinko [mailto:knst.koli...@gmail.com]
 Subject: Re: Setting Context Path in Tomcat

 Chuck, that feature has already been ported to 5.5. It is mentioned as
 44021, 43013: Add support for # to signify multi-level contexts for
 directories and wars.

Thanks for pointing that out.  I guess Mark has been busy...

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

JSESSIONID cookie permanent?

Is there a way to make the JSESSIONID cookie issued by Tomcat permanent,
or at least significantly longer life than end of session ?

Mitch



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: JSESSIONID cookie permanent?

2009-08-12 Thread Martin Gainty


anyone know if there is a use-case for sessionId surviving end-of-session?

Martin Gainty 
__ 
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
 
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem 
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. 
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung 
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez 
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est 
interdite. Ce message sert à l'information seulement et n'aura pas n'importe 
quel effet légalement obligatoire. Étant donné que les email peuvent facilement 
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité 
pour le contenu fourni.




 Date: Wed, 12 Aug 2009 12:43:11 -0500
 From: mi...@claborn.net
 To: users@tomcat.apache.org
 Subject: JSESSIONID cookie permanent?
 
 Is there a way to make the JSESSIONID cookie issued by Tomcat permanent,
 or at least significantly longer life than end of session ?
 
 Mitch
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 

_
Get back to school stuff for them and cashback for you.
http://www.bing.com/cashback?form=MSHYCBpubl=WLHMTAGcrea=TEXT_MSHYCB_BackToSchool_Cashback_BTSCashback_1x1

Re: JSESSIONID cookie permanent?

My usage is: I store the key to the user's shopping cart in the
session. I'd like the user to be able to come back a few days from now
and still find the items they have placed in their shopping cart. (This
is mostly for anonymous users who don't sign in until checkout.)

Mitch

Martin Gainty wrote:
anyone know if there is a use-case for sessionId surviving end-of-session?

Martin Gainty
__
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich
dem Austausch von Informationen und entfaltet keine rechtliche
Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen
wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci
est interdite. Ce message sert à l'information seulement et n'aura pas
n'importe quel effet légalement obligatoire. Étant donné que les email
peuvent facilement être sujets à la manipulation, nous ne pouvons accepter
aucune responsabilité pour le contenu fourni.

Date: Wed, 12 Aug 2009 12:43:11 -0500
From: mi...@claborn.net
To: users@tomcat.apache.org
Subject: JSESSIONID cookie permanent?

Is there a way to make the JSESSIONID cookie issued by Tomcat permanent,
or at least significantly longer life than end of session ?

Mitch

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

_
Get back to school stuff for them and cashback for you.
http://www.bing.com/cashback?form=MSHYCBpubl=WLHMTAGcrea=TEXT_MSHYCB_BackToSchool_Cashback_BTSCashback_1x1

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: JSESSIONID cookie permanent?

2009-08-12 Thread Hassan Schroeder

On Wed, Aug 12, 2009 at 11:35 AM, Mitch Clabornmi...@claborn.net wrote:
 My usage is:  I store the key to the user's shopping cart in the
 session.

If I understand you correctly, then you would need to serialize the
session when it ended, to be able to resurrect it and retrieve that
key, or have never-expiring sessions (probably *not* a good idea).

  I'd like the user to be able to come back a few days from now
 and still find the items they have placed in their shopping cart.  (This
 is mostly for anonymous users who don't sign in until checkout.)

Why can't you just save the cart key in a persistent cookie?

-- 
Hassan Schroeder  hassan.schroe...@gmail.com
twitter: @hassan

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: JSESSIONID cookie permanent?

2009-08-12 Thread David Smith

Your best bet is to assign your own cookie. Then on new session
creation, look for the cookie and repopulate the new session with
shopping cart data.

--David

Mitch Claborn wrote:
My usage is: I store the key to the user's shopping cart in the
session. I'd like the user to be able to come back a few days from now
and still find the items they have placed in their shopping cart. (This
is mostly for anonymous users who don't sign in until checkout.)

Mitch

Martin Gainty wrote:

anyone know if there is a use-case for sessionId surviving end-of-session?

Martin Gainty
__
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte
Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht
dient lediglich dem Austausch von Informationen und entfaltet keine
rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von
E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
destinataire prévu, nous te demandons avec bonté que pour satisfaire
informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie
de ceci est interdite. Ce message sert à l'information seulement et n'aura
pas n'importe quel effet légalement obligatoire. Étant donné que les email
peuvent facilement être sujets à la manipulation, nous ne pouvons accepter
aucune responsabilité pour le contenu fourni.

Date: Wed, 12 Aug 2009 12:43:11 -0500
From: mi...@claborn.net
To: users@tomcat.apache.org
Subject: JSESSIONID cookie permanent?

Is there a way to make the JSESSIONID cookie issued by Tomcat permanent,
or at least significantly longer life than end of session ?

Mitch

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

_
Get back to school stuff for them and cashback for you.
http://www.bing.com/cashback?form=MSHYCBpubl=WLHMTAGcrea=TEXT_MSHYCB_BackToSchool_Cashback_BTSCashback_1x1

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: JSESSIONID cookie permanent?

I don't have any problem with the session contents (on the tomcat
server).  I'm in a tomcat cluster and the sessions are replicated
between members of the cluster.  As long as at least one member of the
cluster is running, then the sessions survive.  I don't mind if the
sessions on the server expire after a number of days. I'm just wanting
the user to be able to keep his sessionid across browser sessions.

Mitch

Hassan Schroeder wrote:
 On Wed, Aug 12, 2009 at 11:35 AM, Mitch Clabornmi...@claborn.net wrote:
   
 My usage is:  I store the key to the user's shopping cart in the
 session.
 

 If I understand you correctly, then you would need to serialize the
 session when it ended, to be able to resurrect it and retrieve that
 key, or have never-expiring sessions (probably *not* a good idea).

   
  I'd like the user to be able to come back a few days from now
 and still find the items they have placed in their shopping cart.  (This
 is mostly for anonymous users who don't sign in until checkout.)
 

 Why can't you just save the cart key in a persistent cookie?

   

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: JSESSIONID cookie permanent?

If I can't find a another way that's what I'll have to do. I would be
surprised that this need doesn't come up more frequently.

Mitch

David Smith wrote:
Your best bet is to assign your own cookie. Then on new session
creation, look for the cookie and repopulate the new session with
shopping cart data.

--David

Mitch Claborn wrote:

Mitch

Martin Gainty wrote:

anyone know if there is a use-case for sessionId surviving end-of-session?

Martin Gainty
__
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte
Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht
dient lediglich dem Austausch von Informationen und entfaltet keine
rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von
E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
destinataire prévu, nous te demandons avec bonté que pour satisfaire
informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie
de ceci est interdite. Ce message sert à l'information seulement et n'aura
pas n'importe quel effet légalement obligatoire. Étant donné que les email
peuvent facilement être sujets à la manipulation, nous ne pouvons accepter
aucune responsabilité pour le contenu fourni.

Date: Wed, 12 Aug 2009 12:43:11 -0500
From: mi...@claborn.net
To: users@tomcat.apache.org
Subject: JSESSIONID cookie permanent?

Is there a way to make the JSESSIONID cookie issued by Tomcat permanent,
or at least significantly longer life than end of session ?

Mitch

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

_
Get back to school stuff for them and cashback for you.
http://www.bing.com/cashback?form=MSHYCBpubl=WLHMTAGcrea=TEXT_MSHYCB_BackToSchool_Cashback_BTSCashback_1x1

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: JSESSIONID cookie permanent?

2009-08-12 Thread Len Popp

It comes up all the time. The solution is typically to use a separate
cookie and *not* tie the persistent data to the browser session, since
the browser session is transient.
--
Len

On Wed, Aug 12, 2009 at 14:54, Mitch Claborn mi...@claborn.net wrote:

If I can't find a another way that's what I'll have to do. I would be
surprised that this need doesn't come up more frequently.

Mitch

David Smith wrote:
Your best bet is to assign your own cookie. Then on new session
creation, look for the cookie and repopulate the new session with
shopping cart data.

--David

Mitch Claborn wrote:

Mitch

Martin Gainty wrote:

anyone know if there is a use-case for sessionId surviving end-of-session?

Martin Gainty
__
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede
unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese
Nachricht dient lediglich dem Austausch von Informationen und entfaltet
keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit
von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas
le destinataire prévu, nous te demandons avec bonté que pour satisfaire
informez l'expéditeur. N'importe quelle diffusion non autorisée ou la
copie de ceci est interdite. Ce message sert à l'information seulement et
n'aura pas n'importe quel effet légalement obligatoire. Étant donné que
les email peuvent facilement être sujets à la manipulation, nous ne
pouvons accepter aucune responsabilité pour le contenu fourni.

Date: Wed, 12 Aug 2009 12:43:11 -0500
From: mi...@claborn.net
To: users@tomcat.apache.org
Subject: JSESSIONID cookie permanent?

Is there a way to make the JSESSIONID cookie issued by Tomcat permanent,
or at least significantly longer life than end of session ?

Mitch

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

_
Get back to school stuff for them and cashback for you.
http://www.bing.com/cashback?form=MSHYCBpubl=WLHMTAGcrea=TEXT_MSHYCB_BackToSchool_Cashback_BTSCashback_1x1

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 6 shutdown hangs server when using JDK 6.0_15

2009-08-12 Thread Juha Laiho

Dan Denton wrote:
 Hello all.
 
 I'm running an RHEL 4 server on a VMware VM hosting tomcat 6, using JDK 
 6.0_15. When I attempt to shutdown any tomcat instance, the entire server 
 (VM) hangs and has to be rebooted. Even out of the box tomcat installations 
 cause this.
 
 When I use JDK 5.0, this doesn't happen. The tomcat instance logs don't show 
 anything useful. I've attempted to use jstack and pstack to get a trace of 
 the process during shutdown, but the server dies before anything useful is 
 logged. Has this happened to anyone else out there? Google yields lots of 
 tomcat hung hits, but nothing about the OS hanging in response to a 
 shutdown.

Isn't RHEL4 quite old (depending on the update level, of course)?

Also, I saw your message telling that you've managed to do this same
on a non-VM RHEL4.

Especially, if your Tomcat (Java VM) runs as a non-root user id,
I would classify this as an OS issue: a process run as regular user
is able to hang the system. This is a definite no-no, and as such
you should take it up with Red Hat. And even if you did run the
Tomcat as root, this still should not happen at the OS level.

So, my recommendation would be to check that you're up-to-date with
updates published to RHEL4, and if this still occurs, take this up
with Red Hat.
-- 
..Juha

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Precompiled binaries for APR?

Filip Hanik - Dev Lists devli...@hanik.com wrote in message 
news:4a831a14.6040...@hanik.com...
 On 08/12/2009 10:05 AM, Eric B. wrote:
 Hi,

 Is there any reason why there aren't any precompiled binaries available 
 for
 APR for Linux/Tomcat?  I have the apr package installed (that provides 
 the
 libapr), but it seems as though I need to manually compile libtcnative
 library.  Does that lib exist precompiled anywhere?  Is there a 
 particular
 reason why it does not?

 they don't exist.
 simple, resources.
 providing binaries for many platforms is time consuming in time and money

Good enough reason.  :)  I thought it might have something more to do with 
portability.

Thanks for the info.

Eric




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Tomcat 6 shutdown hangs server when using JDK 6.0_15

2009-08-12 Thread Dan Denton

Thanks for the reply Juha. I've gotten some suggestions from a previous 
responder, but I will also give this a shot on RHEL5.3 and see if I can 
reproduce it. I will report the result to the list.

Thanks!

-Original Message-
From: Juha Laiho [mailto:juha.la...@iki.fi] 
Sent: Wednesday, August 12, 2009 2:53 PM
To: Tomcat Users List
Subject: Re: Tomcat 6 shutdown hangs server when using JDK 6.0_15

Dan Denton wrote:
 Hello all.

 I'm running an RHEL 4 server on a VMware VM hosting tomcat 6, using JDK 
 6.0_15. When I attempt to shutdown any tomcat instance, the entire server 
 (VM) hangs and has to be rebooted. Even out of the box tomcat installations 
 cause this.

 When I use JDK 5.0, this doesn't happen. The tomcat instance logs don't show 
 anything useful. I've attempted to use jstack and pstack to get a trace of 
 the process during shutdown, but the server dies before anything useful is 
 logged. Has this happened to anyone else out there? Google yields lots of 
 tomcat hung hits, but nothing about the OS hanging in response to a 
 shutdown.

Isn't RHEL4 quite old (depending on the update level, of course)?

Also, I saw your message telling that you've managed to do this same
on a non-VM RHEL4.

Especially, if your Tomcat (Java VM) runs as a non-root user id,
I would classify this as an OS issue: a process run as regular user
is able to hang the system. This is a definite no-no, and as such
you should take it up with Red Hat. And even if you did run the
Tomcat as root, this still should not happen at the OS level.

So, my recommendation would be to check that you're up-to-date with
updates published to RHEL4, and if this still occurs, take this up
with Red Hat.
-- 
..Juha

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: tomcat connects to eso.apache.org

2009-08-12 Thread Joaquín Rodriguez-Guerra Urcelay

Hello, The connections that liferay/tomcat is doing are the followings:

localhost - 140.211.11.130 (jakarta.apache.org = eso.apache.org)

GET /dtds/validator_1_1_3.dtd HTTP/1.1
User-Agent: Java/1.6.0_15
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive

apache -- localhost

HTTP/1.1 301 Moved Permanently
Date: Wed, 12 Aug 2009 21:05:41 GMT
Server: Apache/2.2.12 (Unix)
Location: http://commons.apache.org/dtds/validator_1_1_3.dtd
Vary: Accept-Encoding
Content-Length: 340
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

!DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN
htmlhead
title301 Moved Permanently/title
/headbody
h1Moved Permanently/h1
pThe document has moved a 
href=http://commons.apache.org/dtds/validator_1_1_3.dtd;here/a./p
hr
addressApache/2.2.12 (Unix) Server at jakarta.apache.org Port 80/address
/body/html


localhost -- apache

GET /dtds/validator_1_1_3.dtd HTTP/1.1
User-Agent: Java/1.6.0_15
Host: commons.apache.org
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive

apache -- localhost

HTTP/1.1 200 OK
Date: Wed, 12 Aug 2009 21:05:41 GMT
Server: Apache/2.2.12 (Unix)
Last-Modified: Sun, 25 Jul 2004 11:55:48 GMT
ETag: b01c68-2b18-3e0098c947900
Accept-Ranges: bytes
Content-Length: 11032
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: application/xml-dtd

!--
DTD for the Validator Rules Configuration File, Version 1.1.3

To allow for XML validation of your rules configuration
file, include the following DOCTYPE element at the beginning (after
the xml declaration):

!DOCTYPE form-validation PUBLIC
 -//Apache Software Foundation//DTD Commons Validator Rules Configuration 
1.1.3//EN
 http://jakarta.apache.org/commons/dtds/validator_1_1_3.dtd;

$Id: validator_1_1_3.dtd,v 1.1.2.2 2004/04/06 22:20:36 rleland Exp $
--



!--
 The form-validation element is the root of the configuration file
 hierarchy, and contains nested elements for all of the other
 configuration settings.
--
...
..
!--
 The java script type, Possible Values [int| string | regexp] 

--
!ELEMENT var-jstype (#PCDATA)

localstho -- apache

GET /commons/dtds/validator_1_1_3.dtd HTTP/1.1
User-Agent: Java/1.6.0_15
Host: jakarta.apache.org
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive

apache -- localhost

HTTP/1.1 301 Moved Permanently
Date: Wed, 12 Aug 2009 21:05:42 GMT
Server: Apache/2.2.12 (Unix)
Location: http://commons.apache.org/dtds/validator_1_1_3.dtd
Vary: Accept-Encoding
Content-Length: 340
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

localhost -- apache

GET /dtds/validator_1_1_3.dtd HTTP/1.1
User-Agent: Java/1.6.0_15
Host: commons.apache.org
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive

apache --localhost

HTTP/1.1 200 OK
Date: Wed, 12 Aug 2009 21:05:43 GMT
Server: Apache/2.2.12 (Unix)
Last-Modified: Sun, 25 Jul 2004 11:55:48 GMT
ETag: b01c68-2b18-3e0098c947900
Accept-Ranges: bytes
Content-Length: 11032
Keep-Alive: timeout=5, max=99
Connection: Keep-Alive
Content-Type: application/xml-dtd


So, do they mean anything to you Mark?who is really asking for these xml 
validtaions? liferay? tomcat? is there a way to tell tomcat not to do these 
connections? Maybe tell tomcat that there is no internet access? Thanks!


De: Mark Thomas [ma...@apache.org]
Enviado el: miércoles, 12 de agosto de 2009 13:45
Para: Tomcat Users List
Asunto: Re: tomcat connects to eso.apache.org

Joaquín Rodriguez-Guerra Urcelay wrote:
 Hello all, I am using tomcat with liferay, and when uploading applications it 
 is taking too much time. After using a sniffer to see the outgoing 
 connections we found out that liferay was trying to access 
 file-01.liferay.com to obtain files, but the firewall was not allowing the 
 connections, whice was mking a delay. We configured liferay to block these 
 connections, and uploading time decrement to the half (from 7 min to 3.5). 
 But now, we are seeing that when uploading applications, there are still 
 connections to eos.apache.org, probably by tomcat, blocked by the firewall, 
 which are producing this delay. Do you know how can we block these 
 connections that tomcat is doing to avoid the delay?? Thank you!

That isn't Tomcat. It is your app or a library your app is using. My
money would be on an XML schema. Since you are sniffing traffic, what
URLs are being requested?

Mark



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


__
Este mensaje, y en su caso, cualquier fichero anexo al mismo,
 puede contener informacion clasificada por su emisor como confidencial
 en el marco de su Sistema de Gestion

Re: JSESSIONID cookie permanent?

I was able to get the cookie permanent with a simple valve, code below.

Question: the new cookie will be ignored if the response has already
been committed (isCommitted()). In my brief testing, the new cookie
is being set, so the response must not be committed. Is it possible
that there might be times when the response IS committed when my valve
is invoked, causing the new cookie to be ignored?

public void invoke(Request request, Response response) throws
IOException, ServletException {
getNext().invoke(request, response);
for (Cookie c : response.getCookies()) {
if (Globals.SESSION_COOKIE_NAME.equals(c.getName())) {
Cookie l_new = (Cookie) c.clone();
l_new.setMaxAge(Integer.MAX_VALUE);
response.addCookie(l_new);
}
}
}

Mitch Claborn
972-954-7341
mi...@claborn.net

Len Popp wrote:
It comes up all the time. The solution is typically to use a separate
cookie and *not* tie the persistent data to the browser session, since
the browser session is transient.
--
Len

On Wed, Aug 12, 2009 at 14:54, Mitch Claborn mi...@claborn.net wrote:

If I can't find a another way that's what I'll have to do. I would be
surprised that this need doesn't come up more frequently.

Mitch

David Smith wrote:

Your best bet is to assign your own cookie. Then on new session
creation, look for the cookie and repopulate the new session with
shopping cart data.

--David

Mitch Claborn wrote:

Mitch

Martin Gainty wrote:

anyone know if there is a use-case for sessionId surviving end-of-session?

Martin Gainty
__
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede
unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese
Nachricht dient lediglich dem Austausch von Informationen und entfaltet
keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit
von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas
le destinataire prévu, nous te demandons avec bonté que pour satisfaire
informez l'expéditeur. N'importe quelle diffusion non autorisée ou la
copie de ceci est interdite. Ce message sert à l'information seulement et
n'aura pas n'importe quel effet légalement obligatoire. Étant donné que
les email peuvent facilement être sujets à la manipulation, nous ne
pouvons accepter aucune responsabilité pour le contenu fourni.

Date: Wed, 12 Aug 2009 12:43:11 -0500
From: mi...@claborn.net
To: users@tomcat.apache.org
Subject: JSESSIONID cookie permanent?

Is there a way to make the JSESSIONID cookie issued by Tomcat permanent,
or at least significantly longer life than end of session ?

Mitch

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

_
Get back to school stuff for them and cashback for you.
http://www.bing.com/cashback?form=MSHYCBpubl=WLHMTAGcrea=TEXT_MSHYCB_BackToSchool_Cashback_BTSCashback_1x1

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: JSESSIONID cookie permanent?