Re: AsyncListener.onError and disconnected client

2013-04-25 Thread Rossen Stoyanchev

- Original Message -
 From: Mark Thomas ma...@apache.org
 To: Tomcat Users List users@tomcat.apache.org
 Sent: Wednesday, April 24, 2013 2:14:53 PM
 Subject: Re: AsyncListener.onError and disconnected client
 
 On 24/04/2013 18:38, Rossen Stoyanchev wrote:
 
  - Original Message -
  From: Mark Thomas ma...@apache.org
  To: Tomcat Users List users@tomcat.apache.org
  Sent: Wednesday, April 24, 2013 12:47:54 PM
  Subject: Re: AsyncListener.onError and disconnected client
 
  On 24/04/2013 16:33, Rossen Stoyanchev wrote:
  Hi,
 
  I've seen various discussions here and on the web but I haven't
  found
  a conclusive answer. Why does an AsyncListener not receive
  onError
  notifications when a client disconnects?
 
  Because the Servlet EG says that is the required behaviour. The EG
  is
  currently revisiting that decision. See
  https://java.net/jira/browse/SERVLET_SPEC-44
 
  Thanks for that reference. Is there something in the spec that
  explicitly makes requires this?
 
 Not that I am aware of which why I said EG rather than
 specification.
 
  The JIRA ticket is about adding a disconnect callback but I can
  imagine in the very least, onComplete can be called. After the
  connection is over.
 
 onComplete should be called once the connection times out.

My understanding is that onComplete is always called regardless of how the 
async request completed, i.e. following onTimeout, or onError. I would expect 
it to be called after a client disconnect as well for consistency. Also I 
wonder if a disconnect method is even needed? The onError method could be 
called indicating that the asynchronous operation has failed to complete 
(from the Javadoc). That's actually what I expected when I first tried.

  To my knowledge there is nothing inherent in NIO and TCP that
  prevents the server from detecting that the client has
  disconnected.
  The WebSocket implementation detects disconnected clients
  immediately
  and other HTTP servers (e.g. node) seem to be able to do this.
  What
  is it about the Servlet async support that prevents it from
  knowing
  when a client has disconnected?
 
  It would mean having to ditch the BIO connector / or not being
  able
  to pass the TCK (assuming the TCK tested this) when using the BIO
  connector.
 
  I guess this goes back to the previous question about whether there
  is an explicit requirement and therefore test. Why would a TCK
  test explicitly check that disconnects are not communicated to
  AsyncListeners? Or is it a more indirect consequence of some other
  requirement?
 
 My point was that if a disconnect event was added to the spec then
 the BIO connector could never be spec compliant.

If I understand correctly, you're saying the BIO connector can not detect a 
client disconnect.

 On reflection, it might not be that bad. The event could be fired
 just not when the client disconnects. It would have to wait until an
 attempt was made to read from / write to the socket.

That's actually not very different from the current situation where I catch any 
exceptions while trying to write to the response and then call 
asyncContext.complete(). I suppose it would make it more clear that a client 
has disconnected (as opposed to some other error), but once writing to the 
response has raised an error, it doesn't make a big difference what the error 
is.


Rossen

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



Re: AsyncListener.onError and disconnected client

2013-04-25 Thread Mark Thomas
On 25/04/2013 13:20, Rossen Stoyanchev wrote:
 
 - Original Message -
 From: Mark Thomas ma...@apache.org
 To: Tomcat Users List users@tomcat.apache.org
 Sent: Wednesday, April 24, 2013 2:14:53 PM
 Subject: Re: AsyncListener.onError and disconnected client

 On 24/04/2013 18:38, Rossen Stoyanchev wrote:

 - Original Message -
 From: Mark Thomas ma...@apache.org
 To: Tomcat Users List users@tomcat.apache.org
 Sent: Wednesday, April 24, 2013 12:47:54 PM
 Subject: Re: AsyncListener.onError and disconnected client

 On 24/04/2013 16:33, Rossen Stoyanchev wrote:
 Hi,

 I've seen various discussions here and on the web but I haven't
 found
 a conclusive answer. Why does an AsyncListener not receive
 onError
 notifications when a client disconnects?

 Because the Servlet EG says that is the required behaviour. The EG
 is
 currently revisiting that decision. See
 https://java.net/jira/browse/SERVLET_SPEC-44

 Thanks for that reference. Is there something in the spec that
 explicitly makes requires this?

 Not that I am aware of which why I said EG rather than
 specification.

 The JIRA ticket is about adding a disconnect callback but I can
 imagine in the very least, onComplete can be called. After the
 connection is over.

 onComplete should be called once the connection times out.
 
 My understanding is that onComplete is always called regardless of how the 
 async request completed, i.e. following onTimeout, or onError. I would expect 
 it to be called after a client disconnect as well for consistency. Also I 
 wonder if a disconnect method is even needed? The onError method could be 
 called indicating that the asynchronous operation has failed to complete 
 (from the Javadoc). That's actually what I expected when I first tried.

It is. The issue is when is happens.

The issue is that there is no event (I am aware of) that the container
can monitor.

BIO - Only know once a read/write fails.

NIO - A current read/write will fail.
  The socket can be explicitly tested (but isn't currently)
  If the socket is in the poller I'd expect an error event
  If the socket was added to the poller I'd expect an error event

APR - A current read/write will fail.
  If the socket is in the poller I'd expect an error event
  If the socket was added to the poller I'd expect an error event
  It might be possible to test the socket but I haven't checked

There are times when a socket is not being used for read/write and is
not in a poller (e.g. when the app is doing some processing that doesn't
require output to the user agent). You won't get a notification of
disconnect in this case until the app has finished.

I wonder (for NIO and APR) if you could always have the socket in the
poller in order to detect a disconnect? You'd need to carefully keep
track of the registered interests for the socket and there are likely to
be threading issues as (currently) the Servlet spec is written on the
basis that there is only every one thread processing a socket at a time
(Tomcat's WebSocket impl violates that assumption - that is the subject
of another discussion).

 To my knowledge there is nothing inherent in NIO and TCP that
 prevents the server from detecting that the client has
 disconnected.
 The WebSocket implementation detects disconnected clients
 immediately
 and other HTTP servers (e.g. node) seem to be able to do this.
 What
 is it about the Servlet async support that prevents it from
 knowing
 when a client has disconnected?

 It would mean having to ditch the BIO connector / or not being
 able
 to pass the TCK (assuming the TCK tested this) when using the BIO
 connector.

 I guess this goes back to the previous question about whether there
 is an explicit requirement and therefore test. Why would a TCK
 test explicitly check that disconnects are not communicated to
 AsyncListeners? Or is it a more indirect consequence of some other
 requirement?

 My point was that if a disconnect event was added to the spec then
 the BIO connector could never be spec compliant.
 
 If I understand correctly, you're saying the BIO connector can not detect a 
 client disconnect.

It can't until you try and read or write from the socket.

 On reflection, it might not be that bad. The event could be fired
 just not when the client disconnects. It would have to wait until an
 attempt was made to read from / write to the socket.
 
 That's actually not very different from the current situation where I catch 
 any exceptions while trying to write to the response and then call 
 asyncContext.complete(). I suppose it would make it more clear that a client 
 has disconnected (as opposed to some other error), but once writing to the 
 response has raised an error, it doesn't make a big difference what the error 
 is.

This really comes down to how the spec has been written. onError is for
errors that happen in the container during dispatch (i.e. at the end of
the async phase) that the app does not have visibility 

Re: AsyncListener.onError and disconnected client

2013-04-25 Thread André Warnier

Mark Thomas wrote:

On 25/04/2013 13:20, Rossen Stoyanchev wrote:

- Original Message -

From: Mark Thomas ma...@apache.org
To: Tomcat Users List users@tomcat.apache.org
Sent: Wednesday, April 24, 2013 2:14:53 PM
Subject: Re: AsyncListener.onError and disconnected client

On 24/04/2013 18:38, Rossen Stoyanchev wrote:

- Original Message -

From: Mark Thomas ma...@apache.org
To: Tomcat Users List users@tomcat.apache.org
Sent: Wednesday, April 24, 2013 12:47:54 PM
Subject: Re: AsyncListener.onError and disconnected client

On 24/04/2013 16:33, Rossen Stoyanchev wrote:

Hi,

I've seen various discussions here and on the web but I haven't
found
a conclusive answer. Why does an AsyncListener not receive
onError
notifications when a client disconnects?

Because the Servlet EG says that is the required behaviour. The EG
is
currently revisiting that decision. See
https://java.net/jira/browse/SERVLET_SPEC-44

Thanks for that reference. Is there something in the spec that
explicitly makes requires this?

Not that I am aware of which why I said EG rather than
specification.


The JIRA ticket is about adding a disconnect callback but I can
imagine in the very least, onComplete can be called. After the
connection is over.

onComplete should be called once the connection times out.

My understanding is that onComplete is always called regardless of how the async request 
completed, i.e. following onTimeout, or onError. I would expect it to be called after a 
client disconnect as well for consistency. Also I wonder if a disconnect method is even 
needed? The onError method could be called indicating that the asynchronous 
operation has failed to complete (from the Javadoc). That's actually what I 
expected when I first tried.


It is. The issue is when is happens.

The issue is that there is no event (I am aware of) that the container
can monitor.

BIO - Only know once a read/write fails.

NIO - A current read/write will fail.
  The socket can be explicitly tested (but isn't currently)
  If the socket is in the poller I'd expect an error event
  If the socket was added to the poller I'd expect an error event

APR - A current read/write will fail.
  If the socket is in the poller I'd expect an error event
  If the socket was added to the poller I'd expect an error event
  It might be possible to test the socket but I haven't checked

There are times when a socket is not being used for read/write and is
not in a poller (e.g. when the app is doing some processing that doesn't
require output to the user agent). You won't get a notification of
disconnect in this case until the app has finished.

I wonder (for NIO and APR) if you could always have the socket in the
poller in order to detect a disconnect? You'd need to carefully keep
track of the registered interests for the socket and there are likely to
be threading issues as (currently) the Servlet spec is written on the
basis that there is only every one thread processing a socket at a time
(Tomcat's WebSocket impl violates that assumption - that is the subject
of another discussion).


To my knowledge there is nothing inherent in NIO and TCP that
prevents the server from detecting that the client has
disconnected.
The WebSocket implementation detects disconnected clients
immediately
and other HTTP servers (e.g. node) seem to be able to do this.
What
is it about the Servlet async support that prevents it from
knowing
when a client has disconnected?

It would mean having to ditch the BIO connector / or not being
able
to pass the TCK (assuming the TCK tested this) when using the BIO
connector.

I guess this goes back to the previous question about whether there
is an explicit requirement and therefore test. Why would a TCK
test explicitly check that disconnects are not communicated to
AsyncListeners? Or is it a more indirect consequence of some other
requirement?

My point was that if a disconnect event was added to the spec then
the BIO connector could never be spec compliant.

If I understand correctly, you're saying the BIO connector can not detect a 
client disconnect.


It can't until you try and read or write from the socket.


On reflection, it might not be that bad. The event could be fired
just not when the client disconnects. It would have to wait until an
attempt was made to read from / write to the socket.

That's actually not very different from the current situation where I catch any 
exceptions while trying to write to the response and then call 
asyncContext.complete(). I suppose it would make it more clear that a client 
has disconnected (as opposed to some other error), but once writing to the 
response has raised an error, it doesn't make a big difference what the error 
is.


This really comes down to how the spec has been written. onError is for
errors that happen in the container during dispatch (i.e. at the end of
the async phase) that the app does not have visibility of. It allows the
container to tell the app 

Re: AsyncListener.onError and disconnected client

2013-04-25 Thread Mark Thomas
On 25/04/2013 14:11, André Warnier wrote:

 Sorry to butt in, but the issue interests me in another context.
 My question : is there any kind of I/O operation that a servlet could do
 to the response stream (even in-between two real data I/O) which would
 be guaranteed to return an error if the client has closed the connection
 in the meantime, no matter which Connector implementation underlies it ?
 It would have to be something which does not really send any real data
 byte, so as not to corrupt a response that may be partially under way. 
 Some kind of ping, to say it otherwise.

With the current Servlet API, no.

With direct access to the socket:
BIO - no
NIO - yes
APR - don't know

Mark


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



Re: AsyncListener.onError and disconnected client

2013-04-25 Thread André Warnier

Mark Thomas wrote:

On 25/04/2013 14:11, André Warnier wrote:


Sorry to butt in, but the issue interests me in another context.
My question : is there any kind of I/O operation that a servlet could do
to the response stream (even in-between two real data I/O) which would
be guaranteed to return an error if the client has closed the connection
in the meantime, no matter which Connector implementation underlies it ?
It would have to be something which does not really send any real data
byte, so as not to corrupt a response that may be partially under way. 
Some kind of ping, to say it otherwise.


With the current Servlet API, no.

With direct access to the socket:
BIO - no
NIO - yes
APR - don't know


Thanks.
Mmm. That's definitely not nice, is it ? It means that there is no real clean way for a 
Java webapp to do this and be portable.


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



Re: Configuring IIS to use the JK ISAPI redirector plugin when URL paths are different

2013-04-25 Thread Rainer Jung
On 24.04.2013 09:02, Rainer Jung wrote:
 On 24.04.2013 06:53, Beavers, Melinda K (Kay) wrote:
 We have installed the IIS-Tomcat redirector (isapi_redirect.dll) on an IIS 6 
 server so that http://iis.company.com/website/myfile.jsp  will correctly 
 redirect according to our 'isapi_redirect.properties', 'workers.properties', 
 and 'uriworkermap.properties ' and serve the JSP page from  
 http://tomcat.company.com/website/myfile.jsp . That appears to be working 
 just fine. But we actually need to have a different IIS URL. What we are 
 trying to figure out is if we can configure it so that 
 http://iis.company.com/apps/cepv/website/myfile.jsp will redirect and serve 
 the JSP content at http://tomcat.company.com/website/myfile.jsp. The path on 
 the IIS server is has two extra levels (/apps/cepv) in the URL path and does 
 not match the path on the tomcat server where the JSP content is. We have to 
 have those two extra levels in the IIS URL path for other technical reasons 
 and we cannot match or include those two extra levels on the tomcat side. 

 We have tried the following but cannot get it to work.   

  website.worker=website_ajp13 
  /apps/cepv/website/*.jsp=$(website.worker) 

 Is there anything we can do to map this correctly?   
 
 Have a look at
 
 https://tomcat.apache.org/connectors-doc/generic_howto/proxy.html#URL%20Rewriting
 
 starting from If you are using Microsoft IIS as a web server

The OP reported via PM that it now works after upgrading from an
outdated version to a recent one.

Regards,

Rainer


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



Re: Policy files

2013-04-25 Thread Shanti Suresh
Hi Christian,


On Wed, Apr 24, 2013 at 11:25 PM, Christian Beikov 
christian.bei...@gmail.com wrote:



 I just don't want to have these applications running on my computer not
 knowing what they actually do. To be honest I couldn't think of any
 permission I would give a student application. The libraries that can be
 used are predefined, so I give these jar files the permissions for
 reflection or whatever they need to work properly.

 Am I simplifying the whole thing and is what I want much harder to achive
 than I think?



 Have you considered running Tomcat in a chroot jail?

http://oreilly.com/catalog/tomcat/chapter/ch06.pdf  - Security Manager +
Chroot combination

A more dated link -
http://radioae6rt.wordpress.com/2006/04/22/chrooting-tomcat/

Thanks.

-Shanti


SSL configuration on Tomcat7.

2013-04-25 Thread Shahid Tamboli
Hello Everyone,
   I am Shahid Tamboli and working at Mobimedia
Technologies, Pune, India. We are stuck up with configuring our server with
SSL. We have taken an Ubuntu instance on Amazon. We have installed Tomcat
on the server. The Tomcat version is Tomcat 7 We are facing issues of
configuring SSL certificates on my Tomcat server
We have followed the following steps of deploying the certificate.
http://www.networksolutions.com/support/installation-for-java-based-webservers-e-g-tomcat-using-keytool/http://prolinks.rediffmailpro.com/cgi-bin/prored.cgi?red=http%3A%2F%2Fwww%2Enetworksolutions%2Ecom%2Fsupport%2Finstallation%2Dfor%2Djava%2Dbased%2Dwebservers%2De%2Dg%2Dtomcat%2Dusing%2Dkeytool%2FisImage=0BlockImage=0rediffng=0

On following the above steps we are getting error of certificate not
trusted and on contacting the Certificate Provider they told us to check
our installation again. Thus if anyone can help us on this issue
Thank You
-- 
Cheers Shahid!!!


static cluster

2013-04-25 Thread vicky
Very frequently i am oberving below static cluster messages are getting logged 
in the catalina.out. 
+++
INFO: Received member 
disappeared:org.apache.catalina.tribes.membership.MemberImpl\
  [tcp://10.0.0.222:2333,10.0.0.222,2333, alive=0,id={0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 },\
  payload={}, command={}, domain={}, ]

INFO: Replication member added:org.apache.catalina.tribes.membership.MemberImpl\
  [tcp://10.0.0.222:2333,10.0.0.222,2333, alive=0,id={0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 },\
  payload={}, command={}, domain={}, ]
+++ 
The question is why other tomcat instances are getting disconnected in between 
b y thenselves, what i need to so in oder to resolve this.Please suggest
do i need to increase threads? currently the requests are getting forwarded 
from apache to tomcat over ajp port which is configured with 200 threads.
 
I am using tomcat 6.0.35  Below is my static cluster configuration 
 
+++
 Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster
   channelSendOptions=6 channelStartOptions=3
    Manager className=org.apache.catalina.ha.session.DeltaManager
 expireSessionsOnShutdown=false 
notifyListenersOnReplication=true /
    Channel className=org.apache.catalina.tribes.group.GroupChannel
  Receiver 
className=org.apache.catalina.tribes.transport.nio.NioReceiver
    autoBind=0 selectorTimeout=5000 maxThreads=6
    address=10.0.0.111 port=2333
  /
  Sender 
className=org.apache.catalina.tribes.transport.ReplicationTransmitter
    Transport 
className=org.apache.catalina.tribes.transport.nio.PooledParallelSender /
  /Sender
  Interceptor 
className=org.apache.catalina.tribes.group.interceptors.TcpPingInterceptor /
  Interceptor 
className=org.apache.catalina.tribes.group.interceptors.TcpFailureDetector /
  Interceptor 
className=org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor
 /
  Interceptor 
className=org.apache.catalina.tribes.group.interceptors.StaticMembershipInterceptor
    Member 
className=org.apache.catalina.tribes.membership.StaticMember securePort=-1
    host=10.0.0.222 port=2333
    /

 
+++

RE: SSL configuration on Tomcat7.

2013-04-25 Thread Carrillo, Dan
You didn't provide very much information. But one thing to check is that the 
domain name of your site matches what you specified for the certificate.  

-Original Message-
From: Shahid Tamboli [mailto:shahid1...@gmail.com] 
Sent: Thursday, April 25, 2013 8:10 AM
To: users@tomcat.apache.org
Subject: SSL configuration on Tomcat7.

Hello Everyone,
   I am Shahid Tamboli and working at Mobimedia 
Technologies, Pune, India. We are stuck up with configuring our server with 
SSL. We have taken an Ubuntu instance on Amazon. We have installed Tomcat on 
the server. The Tomcat version is Tomcat 7 We are facing issues of configuring 
SSL certificates on my Tomcat server We have followed the following steps of 
deploying the certificate.
http://www.networksolutions.com/support/installation-for-java-based-webservers-e-g-tomcat-using-keytool/http://prolinks.rediffmailpro.com/cgi-bin/prored.cgi?red=http%3A%2F%2Fwww%2Enetworksolutions%2Ecom%2Fsupport%2Finstallation%2Dfor%2Djava%2Dbased%2Dwebservers%2De%2Dg%2Dtomcat%2Dusing%2Dkeytool%2FisImage=0BlockImage=0rediffng=0

On following the above steps we are getting error of certificate not trusted 
and on contacting the Certificate Provider they told us to check our 
installation again. Thus if anyone can help us on this issue Thank You
--
Cheers Shahid!!!


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



TcpFailureDetector memberDisappeared

2013-04-25 Thread Tim Bennett
Hi everybody..

 

Hope you can help with this..

 

Were running Tomcat 6.0 in cluster, its been running now maybe 2yrs
without problems.. then this..

 

We've checked and renewed all network components (cables, hubs 
switches) checked all machines 

Including monitoring with Wireshark  tcpdump...

 

Best regards

 

Tim

 

25.04.2013 17:17:14
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
memberDisappeared

INFO: Verification complete. Member still
alive[org.apache.catalina.tribes.membership.MemberImpl[tcp://{-6

4, -88, 6, 19}:4000,{-64, -88, 6, 19},4000, alive=2260923,id={-10 1 -21
124 -22 1 79 68 -85 47 27 -30 -97

54 55 92 }, payload={}, command={}, domain={}, ]]

2013-04-25 17:17:18,525 DEBUG (HotelFewoDetails.java:223) - mapAvailable

2013-04-25 17:17:18,526 DEBUG (HotelFewoDetails.java:141) - image

25.04.2013 17:17:31
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
memberDisappeared

INFO: Received
memberDisappeared[org.apache.catalina.tribes.membership.MemberImpl[tcp:/
/{-64, -88, 6, 19}:

4000,{-64, -88, 6, 19},4000, alive=2277935,id={-10 1 -21 124 -22 1 79 68
-85 47 27 -30 -97 54 55 92 }, pay

load={}, command={}, domain={}, ]] message. Will verify.

25.04.2013 17:17:31
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
memberDisappeared

INFO: Verification complete. Member still
alive[org.apache.catalina.tribes.membership.MemberImpl[tcp://{-6

4, -88, 6, 19}:4000,{-64, -88, 6, 19},4000, alive=2277935,id={-10 1 -21
124 -22 1 79 68 -85 47 27 -30 -97

54 55 92 }, payload={}, command={}, domain={}, ]]

25.04.2013 17:17:48
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
memberDisappeared

INFO: Received
memberDisappeared[org.apache.catalina.tribes.membership.MemberImpl[tcp:/
/{-64, -88, 6, 19}:

4000,{-64, -88, 6, 19},4000, alive=2294751,id={-10 1 -21 124 -22 1 79 68
-85 47 27 -30 -97 54 55 92 }, pay

load={}, command={}, domain={}, ]] message. Will verify.

25.04.2013 17:17:48
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
memberDisappeared

INFO: Verification complete. Member still
alive[org.apache.catalina.tribes.membership.MemberImpl[tcp://{-6

4, -88, 6, 19}:4000,{-64, -88, 6, 19},4000, alive=2294751,id={-10 1 -21
124 -22 1 79 68 -85 47 27 -30 -97

54 55 92 }, payload={}, command={}, domain={}, ]]

25.04.2013 17:17:54
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
memberDisappeared

INFO: Received
memberDisappeared[org.apache.catalina.tribes.membership.MemberImpl[tcp:/
/{-64, -88, 6, 19}:

4000,{-64, -88, 6, 19},4000, alive=2301120,id={-10 1 -21 124 -22 1 79 68
-85 47 27 -30 -97 54 55 92 }, pay

load={}, command={}, domain={}, ]] message. Will verify.

25.04.2013 17:17:54
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
memberDisappeared

INFO: Verification complete. Member still
alive[org.apache.catalina.tribes.membership.MemberImpl[tcp://{-6

4, -88, 6, 19}:4000,{-64, -88, 6, 19},4000, alive=2301120,id={-10 1 -21
124 -22 1 79 68 -85 47 27 -30 -97

54 55 92 }, payload={}, command={}, domain={}, ]]

25.04.2013 17:19:34
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
memberDisappeared

INFO: Received
memberDisappeared[org.apache.catalina.tribes.membership.MemberImpl[tcp:/
/{-64, -88, 6, 19}:

4000,{-64, -88, 6, 19},4000, alive=2400766,id={-10 1 -21 124 -22 1 79 68
-85 47 27 -30 -97 54 55 92 }, pay

load={}, command={}, domain={}, ]] message. Will verify.

25.04.2013 17:19:34
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
memberDisappeared

INFO: Verification complete. Member still
alive[org.apache.catalina.tribes.membership.MemberImpl[tcp://{-6

4, -88, 6, 19}:4000,{-64, -88, 6, 19},4000, alive=2400766,id={-10 1 -21
124 -22 1 79 68 -85 47 27 -30 -97

54 55 92 }, payload={}, command={}, domain={}, ]]

25.04.2013 17:20:58
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
memberDisappeared

INFO: Received
memberDisappeared[org.apache.catalina.tribes.membership.MemberImpl[tcp:/
/{-64, -88, 6, 19}:

4000,{-64, -88, 6, 19},4000, alive=2479368,id={-10 1 -21 124 -22 1 79 68
-85 47 27 -30 -97 54 55 92 }, pay

load={}, command={}, domain={}, ]] message. Will verify.

25.04.2013 17:20:58
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
memberDisappeared

INFO: Verification complete. Member still
alive[org.apache.catalina.tribes.membership.MemberImpl[tcp://{-6

4, -88, 6, 19}:4000,{-64, -88, 6, 19},4000, alive=2479368,id={-10 1 -21
124 -22 1 79 68 -85 47 27 -30 -97

54 55 92 }, payload={}, command={}, domain={}, ]]

25.04.2013 17:21:46
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
memberDisappeared

INFO: Received
memberDisappeared[org.apache.catalina.tribes.membership.MemberImpl[tcp:/
/{-64, -88, 6, 19}:

4000,{-64, -88, 6, 19},4000, alive=2533416,id={-10 1 -21 124 -22 1 79 68
-85 47 27 -30 -97 54 55 92 }, pay

load={}, command={}, domain={}, ]] message. Will verify.

25.04.2013 17:21:46

Re: Question on servlet determination

2013-04-25 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Konstantin,

On 4/24/13 4:46 PM, Konstantin Kolinko wrote:
 No. With the following pattern requesting the ../foo/bar URI
 above results in 404 for me. (In current 7.0.x, should not be
 different from 7.0.39). 
 url-pattern/servlets/servlet/RequestInfoExample/url-pattern
 
 Adding an extra / works correctly.
 
 My adding here is adding to request URI in web browser, . 
 http://localhost:8080/examples/servlets/servlet/RequestInfoExample 
 http://localhost:8080/examples/servlets/servlet/RequestInfoExample/

With
 
clean 7.0.39:

http://localhost:8080/examples/servlets/servlet/RequestInfoExample

I get the example page with pathInfo=null

http://localhost:8217/examples/servlets/servlet/RequestInfoExample/

I also get the example page with pathInfo=/

My question is why the top url (with no trailing /) is getting the
request at all, given the url-pattern in web.xml:

servlet-mapping
servlet-nameRequestInfoExample/servlet-name
url-pattern/servlets/servlet/RequestInfoExample/*/url-pattern
/servlet-mapping

The way I read that, the trailing /* is being interpreted as *.

Am I missing something? Why does /servlets/servlet/RequestInfoExample
not require a trailing / to be dispatched to that servlet?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJReVzNAAoJEBzwKT+lPKRYJM4P/1ZW3zOJMm5qLXWgFCIMZLKt
4h3176dZSPtBnvup0b8IRImLTJhMpHLyFGEbAh9ZCE4AaTbb0o7EiwwpE++oIu9M
SKzaF0EdZhA9h7/3MpVw6jF5K9Jf7weBbEHC7VhDXYoBMmfH0WRQ6n+wFsT+H3+W
k0oXlvC42BRkT+bOGCm5g9gd7XIflqtZ9kCG6bpL7dlvL614b4HTWARNVpFRJrZ9
VvC/sCo2WiJd+cbG2XURRQCHhdfVeaL6ndaL6qYVvVheNFslXWw997EcKxwFpd88
UtjPvDiBNjB1l9TqFVU/Qntrv0j+NMVlQzIh13lsqLgpm+MWZ2tBbP72ZzY5tSWg
QIV4+qYhL5YTrN8+Y7aLrr0qovjvXQMZCtxTxYJWJ1fuNswHeArO66vJUIvxce1O
fePVIGI3PpWjzakmBPUJKyp5yiRRlGT9Cw7cqBV9wtMufyYLMBtebVoq+nntAN9q
UfTQh13++XYjDFYqkDNdaXbbS7ebaL2a/Q2017GYLvxmrNOswUFbLDZvPuV4AJY6
5GvbNWAC8LnK0tDskp/3N4R7fqSpoi05xd72SCr45ud6Sbz893/r2W1cEPSl7Fpw
LEUw1euiWh2yzTHILOuCfDvuPa0XU4qmACh1wnJlfqAzvrlV6Od+Vixa8bO+quQx
mS4RmVAYKOfyWgYKUDBX
=qAan
-END PGP SIGNATURE-

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



Re: Policy files

2013-04-25 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Christian,

On 4/24/13 11:25 PM, Christian Beikov wrote:
 Well I understand that there is only one SecurityManager per JVM,
 but as you mentioned I can restrict actions for specific CodeBases.
 This is what I am actually trying to do. I want the student web
 applications to have only a hand full of permissions defined in a
 policy file.

I'm curious as to what permissions you want them to have while
restricting others. Can you give some examples?

 I think I explained my self wrong earlier. The policy file I am
 speaking of, the one I want to apply to student projects, is more
 like a set of permissions that I want to give the web applications.
 I mainly want my testsuite and everything packaged with it to have
 all permissions. Generally the student projects should have no
 permissions. I want to give these applications only a minimal set
 of permissions, only the ones they actually would need to fullfil
 their tasks.

I understand what you are saying, but examples would certainly help.

 The WebappClassLoader supports the method
 addPermission(Permission) which is nice somehow, but I don't want
 to hard code the permissions but rather have them in a policy file
 or so.

I actually had no idea that WebappClassLoader had a set of
addPermission methods. I'll have to read more about those they
seem to give access to the parent classes (URLClassLoader,
SecureClassLoader)'s permissions lists. Cool if it works.

I honestly had no idea that some ClassLoaders maintain their own
permissions lists.

 The reason for having the permissions in a policy file is mainly
 because I thought I can configure something in context.xml so that
 the policy file gets picked up by tomcat.

If you want this, then you'll have to do a couple of things:

1. Make sure the context.xml always has the stuff you want (and isn't
under control of the student, for instance -- otherwise they can just
give themselves whatever permissions they want)

2. Create a ServletContextListener that runs on startup

3. Your listener needs to parse your policy and apply it to the
WebappClassLoader. I wouldn't be surprised if the webapp itself is not
permitted to add permissions to the WebappClassLoader. You might have
to put your ServletContextListener higher-up in the ClassLoader
hierarchy in order to be allowed to call that method.

4. Figure out how to parse a policy file.

Note that #4 just means /your/ policy file. It doesn't have to be a
classic Java Policy File. You could have a simple policy file like this:

java.io.File.read=/path/to/some/data
java.io.File.write=/dev/null

Then you can parse it any way you like. Use XML if it's more convenient.

 I just don't want to have these applications running on my computer
 not knowing what they actually do. To be honest I couldn't think of
 any permission I would give a student application. The libraries
 that can be used are predefined, so I give these jar files the
 permissions for reflection or whatever they need to work properly.

If you don't know what permissions they would need, maybe you should
wait until you actually need to give those permissions before you
spend a lot of time building infrastructure to support granting them.

 Am I simplifying the whole thing and is what I want much harder to 
 achive than I think?

If it were me, I'd look at a particular project and imagine any
privileges you'd need to give to a webapp in order for it to function.
For instance, if you have a webapp that is just a Hello World then
you don't need any permissions.

If you need to access a database, then you'll need to give them access
to that, too. If everyone needs access to the same database, maybe
just make it a top-level permission that all code can access
localhost:1234 or whatever in order to contact the database.

I think you'll find that lots of what you want can be configured at
the global level without worrying too much about assigning permissions
to individual webapps. Instead, all webapps will likely need the same
permissions (e.g. reflection) and you can simply give *all* code in
the JVM permissions to do that.

Then you have much less code to write.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJReWOHAAoJEBzwKT+lPKRYDjIP+wY5GP++U4B9sTRbQLCjpOKZ
wCkg4QnaKP6/eWikJa2HpuQ0re2428utIxv+nXSRdACWXgIx/lQbD2oTF8OfNC86
1ltP8kDXA5kUDT5y4nbpGeWzl0wUuEM4Ce/wmq8mkyKTqvLj2vMDiXrUNSjfgrBS
UVUm/P3kn0E0oJubyRZ19IJITC8Iv7rnnppOSEPOz+hj1/zVbblkHK91UEqmLy4+
6kcdZ8Xxvq33vHWfCjsmosJuvIljh5SYl8CLTtEDv+gr/x/YweJoVA9m1tNXp97u
QgZrzrCBz5L+RBnplz1vZFae/eqhm2FPjVZL9p3Kw8utqZa03rj/ugwBZO1/WP7L
zv46CQaN0cRuM6RMik9rkwKjIIz8VPgr62zvfApkDamYpej07/HIG0lIVpSc6fa4
O9U4KjRTfCOCG2zZyE1eQq+Qzxg/MMlrik4uNQV/KNMM7WASFjOv1+c/Q7M9oeJm
c5dgInU3mTU6o+LW/b1By3sRxkadR5/Vhx3X+7aFGya+VBonkQrpFB9qV494bzvi

Re: SSL configuration on Tomcat7.

2013-04-25 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Shahid,

On 4/25/13 11:10 AM, Shahid Tamboli wrote:
 Hello Everyone, I am Shahid Tamboli and working at Mobimedia 
 Technologies, Pune, India. We are stuck up with configuring our
 server with SSL. We have taken an Ubuntu instance on Amazon. We
 have installed Tomcat on the server. The Tomcat version is Tomcat 7
 We are facing issues of configuring SSL certificates on my Tomcat
 server We have followed the following steps of deploying the
 certificate. 
 http://www.networksolutions.com/support/installation-for-java-based-webservers-e-g-tomcat-using-keytool/http://prolinks.rediffmailpro.com/cgi-bin/prored.cgi?red=http%3A%2F%2Fwww%2Enetworksolutions%2Ecom%2Fsupport%2Finstallation%2Dfor%2Djava%2Dbased%2Dwebservers%2De%2Dg%2Dtomcat%2Dusing%2Dkeytool%2FisImage=0BlockImage=0rediffng=0

  On following the above steps we are getting error of certificate
 not trusted and on contacting the Certificate Provider they told us
 to check our installation again. Thus if anyone can help us on this
 issue

Please tell us exactly what steps you took. I know you were following
an online howto, but please start over again (e.g. delete your
keystore), and tell us how you went from a clean installation of
Tomcat to where you are today. You are likely missing a step (or 2).

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJReWRcAAoJEBzwKT+lPKRYRwsQAKICvLmY0lOyDEc9MVgIDY4f
suloGbVGQCC9g5GfVs9qmMnac6Ruz6WCqrjyDGRdcGwZxhwfkouoRK0cbiHJgLIn
5w5h8y+otFMaq1tzrBRPBp13wilPravSOkSFEREKuTj6he+vc5lN1ANnOi8NGk1h
Mk/ETbie6QH4XUfzg8HpR9GfTq9eItluPnFWwQKzpdtg0DIlEwZzMGe0zYr0Rhjo
bU2wA9IoTVXPKprlWsXI4imMiCs9YEyE7qmbWQl6nwL1j0zomzJXuyeyqPKM8G+J
ZPBh3udF7p3PUx2LhZMWpakI+9tqOBXynxr+RMhdcb0ogXA99xv0c8lKixbTR5D0
vtEPxVP9YcJzaS4MimCQeZfAeAh9EF19RqI57n8TN0POAPXnRgJaGdUqBcs9Jx34
4k5kjrQMMNCBVk/DGKKR0TwaoeOap7vL8TFVTcrYqcfQ1DMyeC5t0kRDH0z2m0pp
1AMiLcdgEsr5xyuyIAG4EQXAtFzsJn4MNkvo051JCrQkfmEEKutZp0sZdpRGHtOk
WPXlctMEI2UEd3Or4CYC0BtZ8BzU/hlJPmo/8g47jXcqtqUiu1P0KRRIvciNbFLI
i2GHz99pGJpxVg0fo6gF+5NFIyujziClqcYCmkpkEicGXJi1zyTBvToZvNIZwnRT
JlC3o06nDSVeVgsCSnpG
=xcyh
-END PGP SIGNATURE-

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



RE: Question on servlet determination

2013-04-25 Thread Caldarale, Charles R
 From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
 Subject: Re: Question on servlet determination

 http://localhost:8080/examples/servlets/servlet/RequestInfoExample
 I get the example page with pathInfo=null

 http://localhost:8217/examples/servlets/servlet/RequestInfoExample/
 I also get the example page with pathInfo=/

 My question is why the top url (with no trailing /) is getting the
 request at all, given the url-pattern in web.xml:

 servlet-mapping
 servlet-nameRequestInfoExample/servlet-name
 url-pattern/servlets/servlet/RequestInfoExample/*/url-pattern
 /servlet-mapping

Likely because of these clauses in the spec:

The container will recursively try to match the longest path-prefix.
This is done by stepping down the path tree a directory at a time, 
using the '/' character as a path separator. The longest match 
determines the servlet selected.

A string beginning with a '/' character and ending with a '/*' suffix
is used for path mapping.

(The above is from 3.0, section 12.1, rule 2, and section 12.2, first bullet.)

But I haven't looked at the code to see how it's actually implemented.

 - 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: SSL configuration on Tomcat7.

2013-04-25 Thread Ognjen Blagojevic

Shahid,
Chris,

On 25.4.2013 19:14, Christopher Schultz wrote:

On 4/25/13 11:10 AM, Shahid Tamboli wrote:

Hello Everyone, I am Shahid Tamboli and working at Mobimedia
Technologies, Pune, India. We are stuck up with configuring our
server with SSL. We have taken an Ubuntu instance on Amazon. We
have installed Tomcat on the server. The Tomcat version is Tomcat 7
We are facing issues of configuring SSL certificates on my Tomcat
server We have followed the following steps of deploying the
certificate.
http://www.networksolutions.com/support/installation-for-java-based-webservers-e-g-tomcat-using-keytool/http://prolinks.rediffmailpro.com/cgi-bin/prored.cgi?red=http%3A%2F%2Fwww%2Enetworksolutions%2Ecom%2Fsupport%2Finstallation%2Dfor%2Djava%2Dbased%2Dwebservers%2De%2Dg%2Dtomcat%2Dusing%2Dkeytool%2FisImage=0BlockImage=0rediffng=0

  On following the above steps we are getting error of certificate
not trusted and on contacting the Certificate Provider they told us
to check our installation again. Thus if anyone can help us on this
issue


Please tell us exactly what steps you took. I know you were following
an online howto, but please start over again (e.g. delete your
keystore), and tell us how you went from a clean installation of
Tomcat to where you are today. You are likely missing a step (or 2).


No, no, no... do not delete keystore. That may be the only place where 
your private key is. If you delete your private key, you will have to 
generate new private key, and purchase new certificate.


I guess Chris missed to notice that you gave us URL from commercial CA.

So, I propose that you just locate your keystore and run

  keytool -list -keystore /path/to/my_keystore.jks

And send us the results here. Also send us your server.xml with comments 
and passwords removed.


-Ognjen

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



Re: SSL configuration on Tomcat7.

2013-04-25 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ognjen,

On 4/25/13 4:47 PM, Ognjen Blagojevic wrote:
 Shahid, Chris,
 
 On 25.4.2013 19:14, Christopher Schultz wrote:
 On 4/25/13 11:10 AM, Shahid Tamboli wrote:
 Hello Everyone, I am Shahid Tamboli and working at Mobimedia 
 Technologies, Pune, India. We are stuck up with configuring
 our server with SSL. We have taken an Ubuntu instance on
 Amazon. We have installed Tomcat on the server. The Tomcat
 version is Tomcat 7 We are facing issues of configuring SSL
 certificates on my Tomcat server We have followed the following
 steps of deploying the certificate. 
 http://www.networksolutions.com/support/installation-for-java-based-webservers-e-g-tomcat-using-keytool/http://prolinks.rediffmailpro.com/cgi-bin/prored.cgi?red=http%3A%2F%2Fwww%2Enetworksolutions%2Ecom%2Fsupport%2Finstallation%2Dfor%2Djava%2Dbased%2Dwebservers%2De%2Dg%2Dtomcat%2Dusing%2Dkeytool%2FisImage=0BlockImage=0rediffng=0



 
On following the above steps we are getting error of certificate
 not trusted and on contacting the Certificate Provider they
 told us to check our installation again. Thus if anyone can
 help us on this issue
 
 Please tell us exactly what steps you took. I know you were
 following an online howto, but please start over again (e.g.
 delete your keystore), and tell us how you went from a clean
 installation of Tomcat to where you are today. You are likely
 missing a step (or 2).
 
 No, no, no... do not delete keystore. That may be the only place
 where your private key is.

Erp... sorry! You are absolutely right. I keep forgetting how
astoundingly stupi... er, efficient! ... Java keystores are.

 If you delete your private key, you will have to generate new
 private key, and purchase new certificate.

This is true. I hope the OP reads this before blowing that file away.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJRed7tAAoJEBzwKT+lPKRYJwIP/RFIaEw65anffhuE9KRcQ75K
AY89quXsNKfu5L3lFRyjHM9VfZx4S6qD86ntmF94r0gM22Ka0LS0Lih8E6/lVe0j
fDEbU3pm0dgb/3gYrxJ7dDVoFOR2oqS1l5aNScKCwtPlad6bs3quJvLSjqVRermk
SyQ9iypv63/08QfMflkwUgzzkvWFrZ39Qd6fSi0vAkl/M1S8CbgLBGZnTMH6NZxh
+Xj3/2B8sTvzLrS/Nc0ez4vBbFQ8wmeQyGM6t5x7GIh128UEAK0AuIOHLNjd960i
yQOdFDDpIv29eoJlMvjvEsVVZk4h2fUK9LB0XnG2w+Eqr77AyEatMbE5F7BHpzFr
i3JThXgV7/ufhH0jIGWvGK4dwBD/zjz/e22E8/464j2dHLt38L6BuEXNMGMUcnK7
RCcmkWLtBgG6aTyjEDED7EpkYGpJJh1GmFM1BmefkSLDTJ0HWSPy1n14d7z4tv3L
KgxPcEQjG8lXw9US+GHJRO2yqUfSomh5fBxQyl/+kUJ8bJF+Fk+MGxYURevgR3PE
5LhCraNNT2HZzd7c3Y62F1tgpyXr18VzELYmFouYOQrYtpSEJzQnxXr3I5TkjcMo
+u4vcVjq3HZFFYJP7cKSXwXStm2GZWE2l2cTz5rd3tAmPiORNARM4sor0/4E3MKu
SCgPv5ofcL+7sGbzoSrr
=qx5U
-END PGP SIGNATURE-

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