date:20111011

2011/10/11 Dan Checkoway dchecko...@gmail.com:
 So...

 1. Is it currently possible to do what I'm trying to do?  Per-webapp logging
 control without using WEB-INF/classes/logging.properties?  I could really
 use a working example if this is doable.

No it is not possible.

What Pid wrote about the manager webapp is about applications that use
log methods in Servlet API.  It does not concern those that use proper
logging libraries.


The suggestions that I have:
1. Look at the org.apache.juli.ClassLoaderLogManager class.

That is where configuration loading happens, and its
getProperty(String) method is what is actually used to access
individual values of those properties.

It might be that it were possible to improve it.

You can specify a different LogManager implementation when Tomcat starts.

2. It might be that VirtualWebappLoader class (in o.a.c.loader
package, see its Javadoc) could be used to add an external folder to
webapp classpath, so that logging.properties could be read from there.

I have not tried it though.

3. The logging.properties file in the webapp can use any system
properties. Maybe you can use them to specify system-dependent values.

Best regards,
Konstantin Kolinko

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

Re: parallel webapp initialization

2011-10-11 Thread Felix Schumacher


Hi Alexander,
On Tue, 11 Oct 2011 09:20:29 +0200, Alexander Knöller wrote:

Hi Felix.

Then you are already working on a patch?
I haven't done any tomcat development, yet.
And I am not familiar with the ettiquette for developing patches.
So if you are already working on it, I won't start doing the same, 
right?

Except cuncurrent development is favored?
I attached a patch to 
https://issues.apache.org/bugzilla/show_bug.cgi?id=46264 the bug entry 
Mark pointed at. So you can have a look at it. Feedback is always 
welcome. Stopping contexts in parallel is completely missing at the 
moment for example.


Regards
 Felix


Regards
Alex

Am 10.10.2011 um 19:30 schrieb Felix Schumacher:


Hi,
Am Montag, den 10.10.2011, 10:17 +0200 schrieb Alexander Knöller:

Hi Mark.

I'd like to give it a try.
If I can't find time to do it I'll send an email.

I also took interest in it and have parallel starting of contexts
implemented. But for stopping I couldn't find a central point to
implement parallel undeploys.

Also if I would want to parameterize deployment parallelization on 
per

host-basis I would have to add methods StandardHost and to make life
easier add methods to Host. Would that be acceptable?

Regards
Felix


Regards
Alex

Am 09.10.2011 um 18:32 schrieb Mark Thomas:


On 09/10/2011 13:55, Alexander Knöller wrote:

Hello mailing list.

We use a single tomcat instance (soon switching from 5.5.23 to 
7.x) with 24 webapps. Each webapp is based on spring and hibernate 
doing a lot of I/O during initialization.
Tomcat is often restarted which causes long downtimes.  As far as 
i can see the tomcat initializes its wepapps sequentially. So 
despite the fact, that our tomcat-intance runs on a 8 core linux 
system, tomcat seems to use a single thread to initalize the 
webapps.


Is there a way on tomcat 7 to make it initialize webapps in 
parallel?


Nope.


Or is there a basic obstacle?


Not that I can think of off the top of my head. Just that no-one 
has

felt the need to scratch that particular itch.

Both start and stop needs to be taken care of.

If you want to propose a patch, this might provide a starting 
point:

https://issues.apache.org/bugzilla/show_bug.cgi?id=46264

I've added some review comments to that patch that you may want to
consider when writing a patch.

If you need any help with the patch, just ask here.

Thinking about this has got me interested. If you decide not to 
take a
look at writing a patch for this, I'll probably take a look - 
maybe

later this week.

Mark


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



--
neulandFon   (0421) 380107-30
Buero fuer Informatik  Fax   (0421) 380107-99
Konsul-Smidt-Str. 8g   Mobil (0176) 20674323
28217 Bremen   alexander.knoel...@neuland-bfi.de
  http://www.neuland-bfi.de

Geschäftsführer: Thomas Koch
Registergericht: Amtsgericht Bremen, HRB 23395 HB
Steuer-Nr. 71-582/03051
USt-ID. DE  246585501
_
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte 
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese 
E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den 
Absender und löschen Sie diese Mail. Das unerlaubte Kopieren sowie 
die unbefugte Weitergabe dieser Mail und der darin enthaltenen 
Informationen sind nicht gestattet.
This e-mail may contain confidential and/or privileged information. 
If you are not the intended recipient (or have received this e-mail 
in error) please notify the sender immediately and delete this 
e-mail. Any unauthorized copying, disclosure or distribution of the 
material in this e-mail is strictly forbidden.





-
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



--
neulandFon   (0421) 380107-30
Buero fuer Informatik  Fax   (0421) 380107-99
Konsul-Smidt-Str. 8g   Mobil (0176) 20674323
28217 Bremen   alexander.knoel...@neuland-bfi.de
   http://www.neuland-bfi.de

Geschäftsführer: Thomas Koch
Registergericht: Amtsgericht Bremen, HRB 23395 HB
Steuer-Nr. 71-582/03051
USt-ID. DE  246585501
_
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den
Absender und löschen Sie diese Mail. Das

Path Parameters - Servlet API

2011-10-11 Thread Paul Wilson

Hi there,

I'm trying to understand what has changed w.r.t. Tomcat 6/7 and
returning path parameters from various calls to the HTTPServletRequest
methods. In particular, I'd like to understand which of the four
methods:

 * getServletPath
 * getContextPath
 * getPathInfo
 * getRequestURI

return so-called 'path parameters' across various Tomcat versions. It
appears that something changed around 6.0.33, although I can only find
the following reference in the changelog:

Improve handling of URLs with path parameters and prevent incorrect
404 responses that could occur when path parameters were present.
(kkolinko)

Is there any more formal information about this change? Frameworks
that utilise URL-based resource resolution will break if, for example,
;jsessionid is all-of-a-sudden returned from these calls when
previously they were removed.

Regards,
Paul

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

Re: Path Parameters - Servlet API

2011/10/11 Paul Wilson paulalexwil...@gmail.com:
 Hi there,

 I'm trying to understand what has changed w.r.t. Tomcat 6/7 and
 returning path parameters from various calls to the HTTPServletRequest
 methods. In particular, I'd like to understand which of the four
 methods:

  * getServletPath
  * getContextPath
  * getPathInfo
  * getRequestURI

 return so-called 'path parameters' across various Tomcat versions.

I cannot say about various versions (because it was a bug that was
fixed in 6.0.33).

My understanding is that getServletPath and getContextPath should not
have path parameters, because they reflect mapping upon Servlets, and
this mapping ignores path parameters.

The getPathInfo and getRequestURI methods provide information about
original request and thus have the parameters.

The fact that getPathInfo and getRequestURI do return path parameters
is explicitly mentioned in Servlet specification - see chapter SRV.3.1
in servlet-2_5-mrel2-spec.pdf.


 It appears that something changed around 6.0.33, although I can only find
 the following reference in the changelog:

 Improve handling of URLs with path parameters and prevent incorrect
 404 responses that could occur when path parameters were present.
 (kkolinko)

 Is there any more formal information about this change?

The change itself - see svn or commit message in dev@ archives. There
was also some discussion on dev@ before it.

http://svn.apache.org/viewvc?view=revisionrevision=1149220

 Frameworks
 that utilise URL-based resource resolution will break if, for example,
 ;jsessionid is all-of-a-sudden returned from these calls when
 previously they were removed.

That is essentially their fault. They will break as well when used in
other Servlet containers. In certain scenarios that can even lead to
security issues, like

http://www.springsource.com/security/cve-2010-3700

Workarounds are possible, by using a Filter or Valve to rewrite the URL.

Best regards,
Konstantin Kolinko

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

Re: Path Parameters - Servlet API

2011-10-11 Thread Paul Wilson

On 11 October 2011 10:43, Konstantin Kolinko knst.koli...@gmail.com wrote:
 I cannot say about various versions (because it was a bug that was
 fixed in 6.0.33).

Was the fixed made available in Tomcat 7 too? (Can't see it in the changelog).

 My understanding is that getServletPath and getContextPath should not
 have path parameters, because they reflect mapping upon Servlets, and
 this mapping ignores path parameters.

 The getPathInfo and getRequestURI methods provide information about
 original request and thus have the parameters.

And the fix affected both these methods, or just getRequestURI?

 The fact that getPathInfo and getRequestURI do return path parameters
 is explicitly mentioned in Servlet specification - see chapter SRV.3.1
 in servlet-2_5-mrel2-spec.pdf.

Strange that it mentions GET explicitly. :-/

Thanks for your quick response (as always ;-))
Paul

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

Re: Path Parameters - Servlet API

2011/10/11 Paul Wilson paulalexwil...@gmail.com:
 On 11 October 2011 10:43, Konstantin Kolinko knst.koli...@gmail.com wrote:
 I cannot say about various versions (because it was a bug that was
 fixed in 6.0.33).

 Was the fixed made available in Tomcat 7 too? (Can't see it in the changelog).


I think it was a part of
http://svn.apache.org/viewvc?view=revisionrevision=944920

 My understanding is that getServletPath and getContextPath should not
 have path parameters, because they reflect mapping upon Servlets, and
 this mapping ignores path parameters.

 The getPathInfo and getRequestURI methods provide information about
 original request and thus have the parameters.

 And the fix affected both these methods, or just getRequestURI?


Hm...

There are RequestInfoExample servlet and snoop.jsp in the sample webapp.

Testing them apparently getPathInfo() still does not return path parameters.

http://localhost:8080/examples/jsp/snp;x=y/snoop.jsp
http://localhost:8080/examples/servlets/servlet;foo=bar/RequestInfoExample/baz;y=z/d

The second one prints:
Path Info:  /baz/d

both in trunk and in current 6.0.


 The fact that getPathInfo and getRequestURI do return path parameters
 is explicitly mentioned in Servlet specification - see chapter SRV.3.1
 in servlet-2_5-mrel2-spec.pdf.

 Strange that it mentions GET explicitly. :-/


Best regards,
Konstantin Kolinko

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

Re: Path Parameters - Servlet API

2011-10-11 Thread Paul Wilson

On 11 October 2011 12:08, Konstantin Kolinko knst.koli...@gmail.com wrote:
 Hm...

 There are RequestInfoExample servlet and snoop.jsp in the sample webapp.

 Testing them apparently getPathInfo() still does not return path parameters.

 http://localhost:8080/examples/jsp/snp;x=y/snoop.jsp
 http://localhost:8080/examples/servlets/servlet;foo=bar/RequestInfoExample/baz;y=z/d

 The second one prints:
 Path Info:      /baz/d

 both in trunk and in current 6.0.

Thanks for the information.
Paul

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

Re: How to externalize a webapp's logging.properties?

2011-10-11 Thread Dan Checkoway

Konstantin,

Thanks very much for the tips.  VirtualWebappLoader worked perfectly.  For
the record, here's what worked for me:

META-INF/context.xml:
?xml version=1.0 encoding=UTF-8?
Context
  Loader className=org.apache.catalina.loader.VirtualWebappLoader
  virtualClasspath=${catalina.base}/virtualcp/my-webapp /
/Context

Put logging.properties in
$TOMCAT_HOME/virtualcp/my-webapp/logging.properties.

Works like a charm.  Thanks again!

Dan

On Tue, Oct 11, 2011 at 9:08 AM, Konstantin Kolinko
knst.koli...@gmail.comwrote:

 2011/10/11 Dan Checkoway dchecko...@gmail.com:
  So...
 
  1. Is it currently possible to do what I'm trying to do?  Per-webapp
 logging
  control without using WEB-INF/classes/logging.properties?  I could really
  use a working example if this is doable.

 No it is not possible.

 What Pid wrote about the manager webapp is about applications that use
 log methods in Servlet API.  It does not concern those that use proper
 logging libraries.


 The suggestions that I have:
 1. Look at the org.apache.juli.ClassLoaderLogManager class.

 That is where configuration loading happens, and its
 getProperty(String) method is what is actually used to access
 individual values of those properties.

 It might be that it were possible to improve it.

 You can specify a different LogManager implementation when Tomcat starts.

 2. It might be that VirtualWebappLoader class (in o.a.c.loader
 package, see its Javadoc) could be used to add an external folder to
 webapp classpath, so that logging.properties could be read from there.

 I have not tried it though.

 3. The logging.properties file in the webapp can use any system
 properties. Maybe you can use them to specify system-dependent values.

 Best regards,
 Konstantin Kolinko

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

Re: Path Parameters - Servlet API

On 11/10/2011 12:13, Paul Wilson wrote:
 On 11 October 2011 12:08, Konstantin Kolinko knst.koli...@gmail.com wrote:
 Hm...

 There are RequestInfoExample servlet and snoop.jsp in the sample webapp.

 Testing them apparently getPathInfo() still does not return path parameters.

 http://localhost:8080/examples/jsp/snp;x=y/snoop.jsp
 http://localhost:8080/examples/servlets/servlet;foo=bar/RequestInfoExample/baz;y=z/d

 The second one prints:
 Path Info:  /baz/d

 both in trunk and in current 6.0.
 
 Thanks for the information.

There was a clarification from the EG (that never made it into the
specification) that path parameters should not be included in getPathInfo()
https://issues.apache.org/bugzilla/show_bug.cgi?id=25015

I have raised this again as
http://java.net/jira/browse/SERVLET_SPEC-18
along with a bunch of related issues.

Mark

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

Re: Loading Super Classes with ClassLoader in Tomcat

2011-10-11 Thread Peter Lavin



Hi Christopher, Pid, Filippo, thanks for your help. I have got this
working as required on my Tomcat server. Here is the code that works.

public class MyCustomClassLoader extends ClassLoader {

public MyCustomClassLoader(ClassLoader contextClassLoader) {
super(contextClassLoader);
}

public synchronized Class? arrayToClass(String name, byte[] ct,
boolean resolve) {
Class? c = defineClass(name, ct, 0, ct.length);
try {
this.loadClass(c.getName());
} catch (ClassNotFoundException e) {
e.printStackTrace();
}

if (resolve)
System.out.println(Resolving Class in  + 
this.getClass());
resolveClass(c);

return c;
}
} // end class

// This is called by...
MyCustomClassLoader cl = new 
MyCustomClassLoader(Thread.currentThread().getContextClassLoader());

Class? sp = cl.arrayToClass(null, byArray, True);
// use the now loaded class sp for something here


So passing the parent ClassLoader to the constructor was the key.

I'm curious to know what the class
org.apache.catalina.loader.WebappClassLoader is intended for?

I was trying to do...
MyCustomClassLoader extends org.apache.catalina.loader.WebappClassLoader{

and had to add tomcat-catalina-7.0.0.jar to my dependencies in Eclipse.
This works in the IDE but I get the following error when attempting to
deploy the subsequent war in Tomcat (as the jar ended up in the WAR file
too)...

Oct 11, 2011 10:42:30 AM org.apache.tomcat.util.digester.Digester endElement
SEVERE: End event threw exception
java.lang.NoSuchMethodException: org.apache.catalina.deploy.WebXml
addServlet

What is the class WebappClassLoader intended for? It looks like what
Christopher's question is valid :-)

I have a question, though, since the default parent ClassLoader of
any ClassLoader /should/ be the current thread's context ClassLoader,
so none of the above code should be necessary.


but the default ClassLoader used does not appear to be the one of the 
Webapp in question.


thanks again,
regards,
Peter



Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1

Pid,

On 10/10/2011 2:23 PM, Pid wrote:

On 10/10/2011 18:51, Peter Lavin wrote:

Hi Filippo, tks for your reply.

I'm not actually specifying any ClassLoader, perhaps I should? 
How should I specify a ClassLoader to use when dynamically 
loading a class?

You can pass one into the Constructor of your own classloader:

public CustomClassloader(ClassLoader parent) { super(parent); }


And to be perfectly explicit, OP should be doing this when 
constructing their CustomClassLoader (presumably in a 
ServletContextListener):


CustomClassLoader cl = new 
CustomClassLoader(Thread.currentThread().getContextClassLoader());


This should allow Peter's ClassLoader to find superclass definitions 
from the webapp's ClassLoader.


I have a question, though, since the default parent ClassLoader of
any ClassLoader /should/ be the current thread's context ClassLoader,
so none of the above code should be necessary.

Perhaps the CustomClassLoader is being initialized in a weird way
that does not make the above connection.

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

iEYEARECAAYFAk6TWHwACgkQ9CaO5/Lv0PD//gCgthcJU6rJ5pVjkJt3AOgEHqGq 
EeYAnjq+VkKl/Ojx0QbP2lXPh5062bR6 =3mOs -END PGP SIGNATURE-


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



--
with best regards,
Peter Lavin,
PhD Candidate,
Computer Architecture  Grid Research Group,
Lloyd Institute, 005,
Trinity College Dublin, Ireland.
+353 1 8961536

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

Re: Loading Super Classes with ClassLoader in Tomcat

2011-10-11 Thread Pid

On 11/10/2011 12:59, Peter Lavin wrote:
 
 Hi Christopher, Pid, Filippo, thanks for your help. I have got this
 working as required on my Tomcat server. Here is the code that works.
 
 public class MyCustomClassLoader extends ClassLoader {
 
 public MyCustomClassLoader(ClassLoader contextClassLoader) {
 super(contextClassLoader);
 }
 
 public synchronized Class? arrayToClass(String name, byte[] ct,
 boolean resolve) {
 Class? c = defineClass(name, ct, 0, ct.length);
 try {
 this.loadClass(c.getName());
 } catch (ClassNotFoundException e) {
 e.printStackTrace();
 }
 
 if (resolve)
 System.out.println(Resolving Class in  + this.getClass());
 resolveClass(c);
 
 return c;
 }
 } // end class
 
 // This is called by...
 MyCustomClassLoader cl = new
 MyCustomClassLoader(Thread.currentThread().getContextClassLoader());
 Class? sp = cl.arrayToClass(null, byArray, True);
 // use the now loaded class sp for something here
 
 
 So passing the parent ClassLoader to the constructor was the key.
 
 I'm curious to know what the class
 org.apache.catalina.loader.WebappClassLoader is intended for?
 
 I was trying to do...
 MyCustomClassLoader extends org.apache.catalina.loader.WebappClassLoader{

It's the classloader the webapp uses.  Extending it doesn't mean you
inherit the relationships it holds, you still have to pass in a parent
classloader in the constructor.



p


 and had to add tomcat-catalina-7.0.0.jar to my dependencies in Eclipse.
 This works in the IDE but I get the following error when attempting to
 deploy the subsequent war in Tomcat (as the jar ended up in the WAR file
 too)...
 
 Oct 11, 2011 10:42:30 AM org.apache.tomcat.util.digester.Digester
 endElement
 SEVERE: End event threw exception
 java.lang.NoSuchMethodException: org.apache.catalina.deploy.WebXml
 addServlet
 
 What is the class WebappClassLoader intended for? It looks like what
 Christopher's question is valid :-)
 I have a question, though, since the default parent ClassLoader of
 any ClassLoader /should/ be the current thread's context ClassLoader,
 so none of the above code should be necessary.
 
 but the default ClassLoader used does not appear to be the one of the
 Webapp in question.
 
 thanks again,
 regards,
 Peter
 
 
 
 Christopher Schultz wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1

 Pid,

 On 10/10/2011 2:23 PM, Pid wrote:
 On 10/10/2011 18:51, Peter Lavin wrote:
 Hi Filippo, tks for your reply.

 I'm not actually specifying any ClassLoader, perhaps I should? How
 should I specify a ClassLoader to use when dynamically loading a class?
 You can pass one into the Constructor of your own classloader:

 public CustomClassloader(ClassLoader parent) { super(parent); }

 And to be perfectly explicit, OP should be doing this when
 constructing their CustomClassLoader (presumably in a
 ServletContextListener):

 CustomClassLoader cl = new
 CustomClassLoader(Thread.currentThread().getContextClassLoader());

 This should allow Peter's ClassLoader to find superclass definitions
 from the webapp's ClassLoader.

 I have a question, though, since the default parent ClassLoader of
 any ClassLoader /should/ be the current thread's context ClassLoader,
 so none of the above code should be necessary.

 Perhaps the CustomClassLoader is being initialized in a weird way
 that does not make the above connection.

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

 iEYEARECAAYFAk6TWHwACgkQ9CaO5/Lv0PD//gCgthcJU6rJ5pVjkJt3AOgEHqGq
 EeYAnjq+VkKl/Ojx0QbP2lXPh5062bR6 =3mOs -END PGP SIGNATURE-

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

 




signature.asc
Description: OpenPGP digital signature

ssl handshake problem

2011-10-11 Thread Edward Quick

Hi,

I have an ssl handshake issue with an application running on tomcat that talks 
to an ssl site. This site renewed their ssl certificate recently, however it 
was signed with the G5 and G3 intermediate verisign CA certificates which are 
imported into the java truststore that my tomcat uses.

If I run a short java program from the command line to connect to the site 
using tomcat's truststore it works fine. I'm just wondering if tomcat needs a 
restart to pick the new certificate up from this site? Or is there an mbean 
operation I can invoke to clear this out? Obviously I'm speculating, but I'm a 
bit stuck on this and as it's running a live service, it's not easy to restart.

Thanks for any help.

Ed.


The information contained in this email is strictly confidential and for the 
use of the addressee only, unless otherwise indicated. If you are not the 
intended recipient, please do not read, copy, use or disclose to others this 
message or any attachment. Please also notify the sender by replying to this 
email or by telephone (+44 (0)20 7896 0011) and then delete the email and any 
copies of it. Opinions, conclusions (etc) that do not relate to the official 
business of this company shall be understood as neither given nor endorsed by 
it. IG Group Holdings plc is a company registered in England and Wales under 
number 01190902. VAT registration number 761 2978 07. Registered Office: Cannon 
Bridge House, 25 Dowgate Hill, London EC4R 2YA. Authorised and regulated by the 
Financial Services Authority. FSA Register number 114059.

Re: parallel webapp initialization

On 11/10/2011 10:02, Felix Schumacher wrote:
 Hi Alexander,
 On Tue, 11 Oct 2011 09:20:29 +0200, Alexander Knöller wrote:
 Hi Felix.

 Then you are already working on a patch?
 I haven't done any tomcat development, yet.
 And I am not familiar with the ettiquette for developing patches.
 So if you are already working on it, I won't start doing the same, right?
 Except cuncurrent development is favored?
 I attached a patch to
 https://issues.apache.org/bugzilla/show_bug.cgi?id=46264 the bug entry
 Mark pointed at. So you can have a look at it. Feedback is always
 welcome. Stopping contexts in parallel is completely missing at the
 moment for example.

I have added a patch based on the previous patches that adds:
- threaded start/stop for Contexts
- threaded start/stop for Hosts
- threaded deployment

Control over the number of threads is via server.xml and/or JMX. This
can be changed dynamically.

Review, feedback, testing etc. welcome.

With 4 threads rather than the current 1 (on a 8-core machine), I saw a
20-25% improvement in start time with a large number of Contexts that
all start quickly. I'd expect to see better results in situations where
1 few Contexts start slowly but most are quick.

Mark

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

SingleSignonValve and webapp session timeout

2011-10-11 Thread Brian Burch

I am using tomcat 6.0.28 (actually the 6.0.28-10ubuntu2 package) as a 
standalone web server. I am getting timeout behaviour that sort-of makes 
sense, but doesn't agree with the way I read the servlet spec.


I have associated the org.apache.catalina.authenticator.SingleSignOn 
Valve with my Engine, within the Host definition. It seems to work fine.


1. conf/web.xml sets session-timeout to 30 minutes. (I believe this 
will be the default used by webapps that do not explicitly define a 
value within their individual web.xml files.)


2. My root welcome page does an html redirect to a small webapp called 
static, which has its own web.xml. The redirect is to a page which is 
protected by a security contraint which requires a FORM-based login 
(this server only has an SSL Connector defined). The static web.xml 
defines its session-timeout to be 20 minutes.


3. Once the user has authenticated to the static webapp, the client sees 
an html page generated by a jsp which provides a menu based on the roles 
defined for the individual user.


4. The menu offers url's to other webapps within the same Host and 
Realm, therefore within the control of the SSO Valve.


5. When a user navigates to one of these other webapps, it apparently 
works fine. However, this second webapp has a web.xml that sets 
session-timeout to be 120 minutes.


6. The user tries to refresh the second webapp's page after about 25 
minutes, but the GET fails with 403 status and the explanation access 
to resource has been denied. Apparently, the user's session has been 
timed out and so he or she is no longer authorised to access the resource.


7. When I attach a debugger to the source code in my second webapp, I 
can stop execution and display context variables:
*** HttpServletRequest.StandardSession.maxInactiveInterval has the value 
7200 (i.e. 120 minutes),

which is the time defined in the webapp's own xml.


These observations suggest the session is being timed out based on the 
value for the webapp first encountered by SSO, possibly associated with 
the entire SSO Realm, and is not being modified by the individual 
webapps within the Realm.


I can see some relevant logic within the source code of 
SingleSignOn.sessionEvent(SessionEvent), but I don't know which session 
instance it will be working with:


  // Look up the single session id associated with this session (if any)
  Session session = event.getSession();

Regardless of my open question, **something** has been waiting for a 
timer to pop. The timer must have been set to 20 minutes at the time it 
was scheduled, and the session has already been timed-out.


I can see that a SingleSignOnEntry cache entry has an array to carry 
multiple Session instances. I wonder whether the wrong Session 
instance (i.e. not the one currently in conversation with the client) 
has been used to establish the timer?


I have read the explanation for the
org.apache.catalina.STRICT_SERVLET_COMPLIANCE property, but it doesn't 
really make a lot of sense to me and I'm not sure whether it is relevant 
to my problem.


Does my description make sense? I'm not sure whether I am looking at a 
bug, or simply a case of how it is intended to work. Does anyone have 
any helpful suggestions about how to achieve my desired behaviour?


(puzzled)

Brian Burch


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

Re: SingleSignonValve and webapp session timeout

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Brian,

On 10/11/2011 10:09 AM, Brian Burch wrote:
 6. The user tries to refresh the second webapp's page after about
 25 minutes, but the GET fails with 403 status and the explanation
 access to resource has been denied. Apparently, the user's
 session has been timed out and so he or she is no longer authorised
 to access the resource.

This sounds like expected behavior to me: sessions are distinct
between webapps, even when SSO is being used. That means that the
user's session in the static webapp will expire 20 minutes after
their last request to static, regardless of activity in other
webapps. When that session times-out, the requirements of SSO are that
all webapps participating in the SSO session are terminated.

http://tomcat.apache.org/tomcat-7.0-doc/config/host.html#Single%20Sign%20On

 These observations suggest the session is being timed out based on
 the value for the webapp first encountered by SSO, possibly
 associated with the entire SSO Realm, and is not being modified by
 the individual webapps within the Realm.

I think the thing you're missing is that it's not a single session,
it's a single sign-on. The sessions themselves are distinct.

 Regardless of my open question, **something** has been waiting for
 a timer to pop. The timer must have been set to 20 minutes at the
 time it was scheduled, and the session has already been timed-out.
 
 I can see that a SingleSignOnEntry cache entry has an array to
 carry multiple Session instances. I wonder whether the wrong
 Session instance (i.e. not the one currently in conversation with
 the client) has been used to establish the timer?
 
 I have read the explanation for the 
 org.apache.catalina.STRICT_SERVLET_COMPLIANCE property, but it
 doesn't really make a lot of sense to me and I'm not sure whether
 it is relevant to my problem.

I don't believe it's relevant.

 Does my description make sense? I'm not sure whether I am looking
 at a bug, or simply a case of how it is intended to work. Does
 anyone have any helpful suggestions about how to achieve my desired
 behaviour?

I think you have two options:

1. Configure your session timeouts differently

2. Have each webapp ping the others periodically, or whenever a
   request comes in for a particular session

The difficult part about #1 is that a user could use a webapp for 4
hours and that's an unreasonable timeout for a session. You could wait
for authentication, then increase the timeout, but you still have the
same problem for legitimate users.

#2 requires that you have webapps communicate with each other and
masquerade as the user in question. There may be performance and
security issues that you'll want to sort-out before you decide to do
this kind of thing.

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

iEYEARECAAYFAk6UYHAACgkQ9CaO5/Lv0PDB6wCfX3pAFtu4Dhvd1I4ObIa7bR6v
s30An1lMjyuEkth0R97atkiyGm1JNALe
=9m7N
-END PGP SIGNATURE-

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

Re: ssl handshake problem

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Edward,

On 10/11/2011 9:21 AM, Edward Quick wrote:
 I have an ssl handshake issue with an application running on
 tomcat that talks to an ssl site. This site renewed their ssl
 certificate recently, however it was signed with the G5 and G3
 intermediate verisign CA certificates which are imported into the
 java truststore that my tomcat uses.
 
 If I run a short java program from the command line to connect to
 the site using tomcat's truststore it works fine. I'm just
 wondering if tomcat needs a restart to pick the new certificate up
 from this site? Or is there an mbean operation I can invoke to
 clear this out? Obviously I'm speculating, but I'm a bit stuck on
 this and as it's running a live service, it's not easy to restart.

So, if the service is restarted, you're confident that the handshake
will work? If that's the case, I believe a Tomcat restart is your only
option at this point.

Another option would be to manage your own trust store for your
outgoing communications instead of relying on Tomcat's trust store. Of
course, that requires you to modify your webapp which might not be
terribly convenient.

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

iEYEARECAAYFAk6UYPUACgkQ9CaO5/Lv0PAGsgCfc9ORPVz7v9GlwhQZFRhVJZRr
jhoAn1r/Sl+KR57wfi8UwRTjkOMD5TTQ
=9b/8
-END PGP SIGNATURE-

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

Re: Loading Super Classes with ClassLoader in Tomcat

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

All,

On 10/10/2011 4:41 PM, Christopher Schultz wrote:
 I have a question, though, since the default parent ClassLoader of
 any ClassLoader /should/ be the current thread's context
 ClassLoader, so none of the above code should be necessary.

I was wrong. ClassLoader Javadoc says:

protected ClassLoader()
  Creates a new class loader using the ClassLoader returned by
the method getSystemClassLoader() as the parent class loader.

So, default is system ClassLoader, not the current Thread's context
ClassLoader.

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

iEYEARECAAYFAk6UYaEACgkQ9CaO5/Lv0PA0pgCfVWYnjvB2LCcK0sCYmuGJ34ZN
f+oAoMCIXTl5zWLmaHXqIePxWmEeFMij
=70Ez
-END PGP SIGNATURE-

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

Re: Fwd: SessionListener.sessionDestroyed is not called when stopping web application

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chuck,

On 10/11/2011 1:49 AM, Caldarale, Charles R wrote:
 From: Violeta Georgieva [mailto:miles...@gmail.com] Subject: Re:
 Fwd: SessionListener.sessionDestroyed is not called when stopping
 web application
 
 I can confirm that in all three scenarios sessionDestroyed method
  is not invoked and session.expire(false) is invoked.
 
 This may be because the sessions are not actually destroyed.
 Tomcat normally persists sessions in the work directory under the
 name Catalina/[host]/[appName]/SESSIONS.ser when it stops so that
 the sessions can be recovered when it restarts.

This is exactly why I was asking about undeploy versus stop. Stopping
a webapp should (by default) persist sessions to SESSIONS.ser, but
undeploying a webapp should kill the sessions.

That the sessions are not killed during a webapp undeploy is confusing
to me, but that may have been done to avoid wiping-out a cluster when
one node is taken out of service.

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

iEYEARECAAYFAk6UY0kACgkQ9CaO5/Lv0PAg9gCfVK6+/FAc7Bk87zldhDnQcheO
WlsAn2Knl7318lFPJW97L6Mak1gwZGRz
=jUiQ
-END PGP SIGNATURE-

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

Re: parallel webapp initialization

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Pid,

On 10/11/2011 12:58 AM, Pid * wrote:
 On 10 Oct 2011, at 23:36, Christopher Schultz 
 ch...@christopherschultz.net wrote:
 limit to X number, and negative integers mean all available 
 processors minus X.
 
 My first instinct was to say that's crazy, fool! but I'm starting
 to like it.

:)

Having written a multi-threaded job processor (runs hundreds of
JasperReports in parallel and emails them to people) in the past, I've
had time to think about it. Sometimes you want as much as you can get,
and sometimes you want to make sure that the system has some CPUs free
to do other things (like run the database, for instance) :)

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

iEYEARECAAYFAk6UY8kACgkQ9CaO5/Lv0PCGeQCfby2b0j57r3nHoodrvqnYMKpw
xP4AniWr+X7Fmbqbpf/CofXR0HcydkiV
=fty+
-END PGP SIGNATURE-

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

Re: SingleSignonValve and webapp session timeout

2011-10-11 Thread Brian Burch


On 11/10/11 16:27, Christopher Schultz wrote:

Thanks very much for your speedy and informative reply, Christopher.

While my question is fresh in your mind, I hope you will not mind too 
much if I ask a couple of relevant questions to clarify your answers below.



-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Brian,

On 10/11/2011 10:09 AM, Brian Burch wrote:

6. The user tries to refresh the second webapp's page after about
25 minutes, but the GET fails with 403 status and the explanation
access to resource has been denied. Apparently, the user's
session has been timed out and so he or she is no longer authorised
to access the resource.


This sounds like expected behavior to me: sessions are distinct
between webapps, even when SSO is being used. That means that the
user's session in the static webapp will expire 20 minutes after
their last request to static, regardless of activity in other
webapps. When that session times-out, the requirements of SSO are that
all webapps participating in the SSO session are terminated.

http://tomcat.apache.org/tomcat-7.0-doc/config/host.html#Single%20Sign%20On


These observations suggest the session is being timed out based on
the value for the webapp first encountered by SSO, possibly
associated with the entire SSO Realm, and is not being modified by
the individual webapps within the Realm.


I think the thing you're missing is that it's not a single session,
it's a single sign-on. The sessions themselves are distinct.


OK, I think I understand the distinction you are making, which is 
consistent with there being a Session array (rather than a simple field) 
in the SingleSignOnEntry class.


But I am having trouble understanding the life cycle of a Session. If 
the browser has navigated away from my static webapp container, into a 
completely different webapp container, why does it still have an 
associated Session? I can understand how the browser would retain two 
Sessions if it held two tabs open, one to each webapp. I guess in my 
situation (not everyone's), my static webapp is the only thing that 
knows anything about the state of the browser, so the Host and/or Valve 
don't know whether the browser/user will ever interact with my static 
webapp again and so feel obliged to keep the Session alive just in case.


I suppose what I really need is two levels of timeout logic:
a) each individual webapp already has its own session-timeout defined 
within its web.xml. However, when it expires, ONLY THAT INDIVIDUAL 
Session should be invalidated.
b) SSO should only invalidate the single sign-on instance/entry when 
THE FINAL webapp Session is expired or otherwise invalidated (and the 
Session array is empty).


Is it possible for my menu.jsp to invalidate its own Session, without 
logging the user off, when it knows the browser will be sending on a 
one-way trip to another webapp? My feeling is no because that would 
leave the SSO instance without any active Sessions until the new webapp 
starts serving the client.


Do I need to start researching LifeCycleListeners to achieve my 
objective, or would that be a pointless approach?



Regardless of my open question, **something** has been waiting for
a timer to pop. The timer must have been set to 20 minutes at the
time it was scheduled, and the session has already been timed-out.

I can see that a SingleSignOnEntry cache entry has an array to
carry multiple Session instances. I wonder whether the wrong
Session instance (i.e. not the one currently in conversation with
the client) has been used to establish the timer?

I have read the explanation for the
org.apache.catalina.STRICT_SERVLET_COMPLIANCE property, but it
doesn't really make a lot of sense to me and I'm not sure whether
it is relevant to my problem.


I don't believe it's relevant.


Does my description make sense? I'm not sure whether I am looking
at a bug, or simply a case of how it is intended to work. Does
anyone have any helpful suggestions about how to achieve my desired
behaviour?


I think you have two options:

1. Configure your session timeouts differently

2. Have each webapp ping the others periodically, or whenever a
request comes in for a particular session

The difficult part about #1 is that a user could use a webapp for 4
hours and that's an unreasonable timeout for a session. You could wait
for authentication, then increase the timeout, but you still have the
same problem for legitimate users.

#2 requires that you have webapps communicate with each other and
masquerade as the user in question. There may be performance and
security issues that you'll want to sort-out before you decide to do
this kind of thing.

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

iEYEARECAAYFAk6UYHAACgkQ9CaO5/Lv0PDB6wCfX3pAFtu4Dhvd1I4ObIa7bR6v
s30An1lMjyuEkth0R97atkiyGm1JNALe
=9m7N
-END PGP SIGNATURE-

Need help on SSL problem on new server after move from existing server

2011-10-11 Thread Rob Tanner

Hi,

After moving to a new server, I am getting the error: SSL received a record 
that exceeded the maximum permissible length.

I installed Tomcat 6.0.29 on a new machine and copied over the webapps folder 
and the keystore from the old 5.5.23 machine.  Then I modified server.xml to 
include the various contexts from the old server as well as the port 80 and 
port 443 connectors and also changed the keystore path  for the port 443 SSL 
connector so it was pointing to the keystore.

As far as I know, all the SSL configuration on the server is contained within 
the connector definition, included below:

Connector port=443 address=10.171.10.119 debug=4
maxHttpHeaderSize=8192 enableLookups=false tcpNoDelay=true
maxThreads=150 minSpareThreads=25 maxSpareThreads=75
acceptCount=100 connectionTimeout=2 disableUploadTimeout=true
keystoreFile=/usr/local/java/keystore2010 keystorePass=xx
scheme=https secure=true clientAuth=false sslProtocol=TLS /

This connector works perfectly with Tomcat 5.5.23.  Are there changes need for 
6.0.29?  Any ideas about what's going on?

Thanks,

Rob Tanner
Linfield College

Tomcat 7.0.22 maven repository

2011-10-11 Thread charlesk40


Hi,

Can we get the the 7.0.22 up on the Maven repository?
I think the latest one I see is 7.0.21.
http://mvnrepository.com/artifact/org.apache.tomcat.extras/tomcat-extras-juli
Thank you.

-- 
View this message in context: 
http://old.nabble.com/Tomcat-7.0.22-maven-repository-tp32629315p32629315.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: Need help on SSL problem on new server after move from existing server

On 11/10/2011 18:23, Rob Tanner wrote:
 Hi,
 
 After moving to a new server, I am getting the error: SSL received a record 
 that exceeded the maximum permissible length.
 
 I installed Tomcat 6.0.29 on a new machine and copied over the webapps folder 
 and the keystore from the old 5.5.23 machine.  Then I modified server.xml to 
 include the various contexts from the old server as well as the port 80 and 
 port 443 connectors and also changed the keystore path  for the port 443 SSL 
 connector so it was pointing to the keystore.
 
 As far as I know, all the SSL configuration on the server is contained within 
 the connector definition, included below:
 
 Connector port=443 address=10.171.10.119 debug=4
 maxHttpHeaderSize=8192 enableLookups=false tcpNoDelay=true
 maxThreads=150 minSpareThreads=25 maxSpareThreads=75
 acceptCount=100 connectionTimeout=2 
 disableUploadTimeout=true
 keystoreFile=/usr/local/java/keystore2010 keystorePass=xx
 scheme=https secure=true clientAuth=false sslProtocol=TLS /
 
 This connector works perfectly with Tomcat 5.5.23.  Are there changes need 
 for 6.0.29?

Yes.

  Any ideas about what's going on?

http://tomcat.apache.org/migration.html#Migrating_from_5.5.x_to_6.0.x

Mark

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

Re: Tomcat 7.0.22 maven repository

On 11/10/2011 18:29, charlesk40 wrote:
 
 Hi,
 
 Can we get the the 7.0.22 up on the Maven repository?

Already done.

 I think the latest one I see is 7.0.21.

The repository you are looking at hasn't sync'd yet.

 http://mvnrepository.com/artifact/org.apache.tomcat.extras/tomcat-extras-juli

Try:
http://repo2.maven.org/maven2/org/apache/tomcat/tomcat-catalina/7.0.22/

Mark

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

Re: Need help on SSL problem on new server after move from existing server

2011-10-11 Thread Rob Tanner

That was a simple enough fix.  Thank you.

~ Rob

On 10/11/11 10:31 AM, Mark Thomas ma...@apache.org wrote:

On 11/10/2011 18:23, Rob Tanner wrote:
 Hi,
 
 After moving to a new server, I am getting the error: SSL received a
record that exceeded the maximum permissible length.
 
 I installed Tomcat 6.0.29 on a new machine and copied over the webapps
folder and the keystore from the old 5.5.23 machine.  Then I modified
server.xml to include the various contexts from the old server as well
as the port 80 and port 443 connectors and also changed the keystore
path  for the port 443 SSL connector so it was pointing to the keystore.
 
 As far as I know, all the SSL configuration on the server is contained
within the connector definition, included below:
 
 Connector port=443 address=10.171.10.119 debug=4
 maxHttpHeaderSize=8192 enableLookups=false tcpNoDelay=true
 maxThreads=150 minSpareThreads=25 maxSpareThreads=75
 acceptCount=100 connectionTimeout=2
disableUploadTimeout=true
 keystoreFile=/usr/local/java/keystore2010
keystorePass=xx
 scheme=https secure=true clientAuth=false
sslProtocol=TLS /
 
 This connector works perfectly with Tomcat 5.5.23.  Are there changes
need for 6.0.29?

Yes.

  Any ideas about what's going on?

http://tomcat.apache.org/migration.html#Migrating_from_5.5.x_to_6.0.x

Mark

-
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: SingleSignonValve and webapp session timeout

2011-10-11 Thread André Warnier

Brian Burch wrote:
...

But I am having trouble understanding the life cycle of a Session. If
the browser has navigated away from my static webapp container, into a
completely different webapp container, why does it still have an
associated Session?

Probably because the first webapp has no idea that the browser has navigated
away.
How would it know ? When the browser navigates away, it does not send any information
to the webapp it navigated away from, saying hey, I am navigating away from you.
It just does not send anything anymore to that webapp, and sends something to another
webapp instead (or to www.google.com).
But for the first webapp, that is the same situation as if the browser stayed on the same
page, and the user went away for lunch for half an hour (or in my country, more like two
and a half hours).

I can understand how the browser would retain two
Sessions if it held two tabs open, one to each webapp.

The browser does not retain sessions. What is retaining sessions, is the
server.
The browser may just keep some token received from the server (be it a cookie, or a
session-id embedded in links contained in the currently displayed page), but that's it.
When (and if) the browser ever accesses that same server again (and the same path on the
server), it may send this token along with the new request. When the server receives a
request with such a token, it /may/ be able to use the information in the token, to
reconnect this request with some session information that it has kept until then, and thus
retrieve the session's state, and process the request knowing that it is the
continuation of a session (instead of back from zero).

...

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

Re: SingleSignonValve and webapp session timeout

2011/10/11 Brian Burch br...@pingtoo.com:

 2. My root welcome page does an html redirect to a small webapp called
 static, which has its own web.xml. The redirect is to a page which is
 protected by a security contraint which requires a FORM-based login (this
 server only has an SSL Connector defined). The static web.xml defines its
 session-timeout to be 20 minutes.

(...)
 6. The user tries to refresh the second webapp's page after about 25
 minutes, but the GET fails with 403 status and the explanation access to
 resource has been denied. Apparently, the user's session has been timed out
 and so he or she is no longer authorised to access the resource.

 7. When I attach a debugger to the source code in my second webapp, I can
 stop execution and display context variables:
 *** HttpServletRequest.StandardSession.maxInactiveInterval has the value
 7200 (i.e. 120 minutes),
 which is the time defined in the webapp's own xml.


 These observations suggest the session is being timed out based on the value
 for the webapp first encountered by SSO, possibly associated with the entire
 SSO Realm, and is not being modified by the individual webapps within the
 Realm.

 I can see some relevant logic within the source code of
 SingleSignOn.sessionEvent(SessionEvent), but I don't know which session
 instance it will be working with:


Sessions in each of webapps are independent from each other. That is
what Servet specification requires.

The org.apache.catalina.authenticator.SingleSignOn valve
invalidates the SSO session when session is explicitly invalidated
(that is what you usually do on logout: session.invalidate())

It tries to differentiate between explicit session invalidation and it
timing out. Timed out sessions are just removed, and invalidation
happens when the last session for the same sso id has been removed.

Maybe something goes wrong in SingleSignOn#sessionEvent(...) - you may
try to debug it (see Wiki) or at least enable debug logging for that
class.

http://wiki.apache.org/tomcat/FAQ/Developing#Debugging

Best regards,
Konstantin Kolinko

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

Re: SingleSignonValve and webapp session timeout

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Brian,

On 10/11/2011 12:35 PM, Brian Burch wrote:
 OK, I think I understand the distinction you are making, which is 
 consistent with there being a Session array (rather than a simple
 field) in the SingleSignOnEntry class.

I haven't looked at the implementation, but it sounds plausible that a
SingleSignOnEntry object would contain references (or ids) for each of
the sessions that are involved in the SSO session.

 But I am having trouble understanding the life cycle of a Session.
 If the browser has navigated away from my static webapp
 container, into a completely different webapp container, why does
 it still have an associated Session?

I'm not an expert at SSO, nor have I ever used it on any of my
projects. All my answers should be considered suspicious :)

When the browser navigates away from a webapp, the webapp usually
doesn't know, because HTTP clients generally don't ping-back pages and
say I'm leaving, now. That's why session timeouts exist. So, your
client leaves the static webapp and 20 minutes later, the session
timeout there kills the session, which takes-down the whole SSO session.

 I can understand how the browser would retain two Sessions if it
 held two tabs open, one to each webapp.

This happens regardless of whether the windows are still open or have
been closed.

 I guess in my situation (not everyone's), my static webapp is the
 only thing that knows anything about the state of the browser, so
 the Host and/or Valve don't know whether the browser/user will ever
 interact with my static webapp again and so feel obliged to keep
 the Session alive just in case.

Exactly. I don't believe the SSO Valve pings the various participating
webapps just to keep their sessions alive anytime you hit a webapp
that's part of the SSO session (note that I keep saying session in
quotes for the SSO session because it's not an HttpSession, but
there is something concrete and cohesive about all of the requests
that come from the client that participate in that SSO).

 I suppose what I really need is two levels of timeout logic: a)
 each individual webapp already has its own session-timeout defined 
 within its web.xml. However, when it expires, ONLY THAT INDIVIDUAL 
 Session should be invalidated.

You're right: see below. Evidently, I was wrong about how this stuff
is supposed to work.

 b) SSO should only invalidate the single sign-on instance/entry
 when THE FINAL webapp Session is expired or otherwise invalidated
 (and the Session array is empty).

Sorry, that's against the rules:


* As soon as the user logs out of one web application (for example, by
invalidating the corresponding session if form based login is used),
the user's sessions in all web applications will be invalidated. Any
subsequent attempt to access a protected resource in any application
will require the user to authenticate himself or herself again.


It doesn't specifically say so, but HttpSession timeouts in a single
webapp does not count as [logging] out of a web application.

 Is it possible for my menu.jsp to invalidate its own Session,
 without logging the user off, when it knows the browser will be
 sending on a one-way trip to another webapp?

If you are using FORM authentication, then session==login. If you kill
the session, the login expires. Also, killing the session would
take-down the SSO session without that helpful timeout that gets you
the 20 minutes you already have :)

 Do I need to start researching LifeCycleListeners to achieve my 
 objective, or would that be a pointless approach?

Hmm... authenticator/SingleSignOn.java has this code and comment in
the session event handler:

// Was the session destroyed as the result of a timeout?
// If so, we'll just remove the expired session from the
// SSO.  If the session was logged out, we'll log out
// of all session associated with the SSO.
if (((session.getMaxInactiveInterval()  0)
 (System.currentTimeMillis() -
session.getThisAccessedTimeInternal() =
session.getMaxInactiveInterval() * 1000))
||
(Session.SESSION_PASSIVATED_EVENT.equals(event.getType( {
removeSession(ssoId, session);
} else {
// The session was logged out.
// Deregister this single session id, invalidating
// associated sessions
deregister(ssoId);
}

So, it looks like the Valve should *not* be expiring your SSO when the
static webapp's session expires. Can you confirm that you really are
suffering a timeout? Are there other reasons a session could be
invalidated in any one of your webapps? The static one seems like
the most likely candidate, but one of the others could be doing it.

Can you enable debug logging for
org.apache.catalina.authenticator.SingleSignOn? It looks like there
should be lots of good logging emitted in there for you to check.

- -chris
-BEGIN PGP SIGNATURE-
Version:

Re: Need help on SSL problem on new server after move from existing server

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Rob,

Goad to see you got your new server working. I do have some further
comments if you're still around:

On 10/11/2011 1:23 PM, Rob Tanner wrote:
 I installed Tomcat 6.0.29

If you were upgrading from 5.5 to something else, why not go up to
6.0.33, which is the latest? Or, even better, why not upgrade all the
way to 7.0.22?

 Then I modified server.xml to include the various contexts from the
 old server

If possible, you should take your Context elements from server.xml
and put them into the individual webapps' META-INF/context.xml files.
This will make deploying and undeploying webapps much easier.

If you want to override the META-INF/context.xml file packaged with a
webapp (say, because you have to add local configuration that your
developers don't know about), you can do so by putting the correct
file into $CATALINA_BASE/conf/[engine]/[host]/[webapp].xml and it will
override the descriptor from the webapp.

 As far as I know, all the SSL configuration on the server is 
 contained within the connector definition, included below:
 
 Connector port=443 address=10.171.10.119 debug=4

There is no debug attribute on the Connector element any longer.
You should remove it.

 maxHttpHeaderSize=8192 enableLookups=false tcpNoDelay=true 
 maxThreads=150 minSpareThreads=25 maxSpareThreads=75

You might want to consider using an Executor: they are more
flexible, and the thread pools can be shared across Connectors if
you want to do that (and you probably do if you have multiple connectors).

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

iEYEARECAAYFAk6UthcACgkQ9CaO5/Lv0PCerwCeMzVLB2CRlkfRHnO1Z42Pt1gQ
QaAAoLUEFMVqYBy2Vd65YERFxav5xSnU
=Lpx8
-END PGP SIGNATURE-

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

Rsecurity breach on tomcat 6.0.26

2011-10-11 Thread zach Li


Hi, 
 
we are using tomcat 6.0.26 to host a java application. but recently we are 
experiencing security breach once or twice a week. the issue we are facing is: 
one user screen(or input) totallly showing up on the different user screen. 
Those screens have customer sensetive information. 
 
Anyone has similiar experience? how should i trace and fix it?
 
thanks for you help.
 
zach.

RE: Rsecurity breach on tomcat 6.0.26

2011-10-11 Thread Caldarale, Charles R

 From: zach Li [mailto:zach...@hotmail.com] 
 Subject: Rsecurity breach on tomcat 6.0.26

 one user screen(or input) totallly showing up on the different user screen.

Your webapp is most likely storing references to the request or response 
objects in static or instance fields of a servlet (or possibly JSP), or less 
likely in thread-local variables.  Since a servlet or JSP can be handling many 
requests concurrently, this is a serious - but typical - logic error.  You'll 
need to examine your code.

 - 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: Need help on SSL problem on new server after move from existing server

2011-10-11 Thread Caldarale, Charles R

 From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
 Subject: Re: Need help on SSL problem on new server after move from existing 
 server

  Connector port=443 address=10.171.10.119 debug=4

 There is no debug attribute on the Connector element
 any longer.

Nor was it there in Tomcat 5.5, so that makes me suspicious of the whole 
server.xml...  Yet another case of blind upgrading without reading the doc for 
the target level.

  maxHttpHeaderSize=8192

That's the default setting, so it could be removed.

  tcpNoDelay=true 

That's also the default.

  minSpareThreads=25 maxSpareThreads=75

 You might want to consider using an Executor

Not might, must: those attributes do not exist in the 6.0 or later Connector, 
but are available with an Executor.

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

Re: Need help on SSL problem on new server after move from existing server