Re: Application Deployment in Tomcat 7.X

2014-04-22 Thread Mark Thomas
On 23/04/2014 04:40, Nitin Kumar wrote:
> Hi,
> 
> We are using tomcat 7.X for our project. So far we deploy only one
> application in tomcat.
> 
> Now we are planning to deploy one more application with existing one.
> 
> There is requirement that failure of deployment of new application should
> not affect existing application deployment and tomcat startup. As per my
> understanding, If any application deployment fails, Tomcat startup will
> fail.

You understanding is not correct.

> Please let us know if there is any way to start the tomcat in case of
> failure of one application deployment also.

That is the default behaviour.

Mark


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



Application Deployment in Tomcat 7.X

2014-04-22 Thread Nitin Kumar
Hi,

We are using tomcat 7.X for our project. So far we deploy only one
application in tomcat.

Now we are planning to deploy one more application with existing one.

There is requirement that failure of deployment of new application should
not affect existing application deployment and tomcat startup. As per my
understanding, If any application deployment fails, Tomcat startup will
fail.

Please let us know if there is any way to start the tomcat in case of
failure of one application deployment also.

With Regards,
 Nitin Kumar


Re: Stateless application is very slow using LDAP authentication

2014-04-22 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Frédéric,

On 4/22/14, 4:15 PM, Frédéric Poliquin wrote:
>> When you say that you put a reverse proxy in front of Tomcat...
>> do you mean that you pushed the authentication out to the proxy
>> layer?
> 
> Yes, I'm delegating everything to HTTPD using an AJP connector.
> 
>> This means that if the user changes their password or the
>> group-membership changes on the LDAP side, httpd won't know about
>> those changes and therefore old credentials are still valid, old
>> group-based authentication checks will yield invalid
>> authentication decisions based upon the canonical LDAP service's
>> view of the world.
> 
> So does session caching!

No. I tried to make this clear: nothing about the client is cached.
It's only the result of a particular check that is cached. httpd keeps
the value of "is the X password for user Y?" cached and can then check
it as a read-through cache. There is no session. The client has no
identity, here. It's just a simply "I'm going to ask LDAP something.
Have I asked it recently the same question?".

> Actually HTTPD have a better control because it allows you to
> choose the appropriate TTL instead of assuming the same credentials
> for the whole session.

That's correct: if you used Tomcat's "alwaysUseSession" setting, you
wouldn't end up re-authenticating the user until the session needed to
be created again (expired session, server fail-over, etc.).

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTVs7DAAoJEBzwKT+lPKRY5b8QAKeXOlFK2ILckjbXP9JaeN+I
l1bbu0Osgb/ehsiSMgdkDlrl7Are5fq+BHvACsmmYX3jjU6SBxiy0+VoqZ3EXKCX
26t8tqedhpdyem13uX+TwXd6BggjR+ycBji6ZGQ0qkQeA0SgSOmVq/rr0hse48UO
VcYdxNLVFXCU5OdxDnef8X7qT+AroMRtug6qZwnPuWnJNReCr36Y10uEPjbMR6QE
GJFyc7JToK23WGNBqgRnv00LL8/R7+iLDaUoiNRXcIT55fOzBgFD5Soj7k8WjLCM
++Wb6cAydI5n08F2/Kvt60h2aojEPqjNJOnZWi542GHRMhZpUrDWDpkuH3XRZUgn
blCQxHJofjYwJ3rI+L9oE2bapbsm0xI+pJGcxWnOGkqI/ct8NLHZDvUgJT5RXM5W
Trw7eoTT6y0M3QGcoyzgBJPW+BHxQWbsEQFwQ68p6R+6dKs7vjNF6hKZRbmYbfYa
uPYUxKH5Tq+Z5LCwQ4ggyOIliAQ3w+xUhGS08W9vg4i/N9AFZvexu8h0b6mzKNEE
Et5JXE3xY2rVrlEWulT5IMPRlEuzInkXSlNBg2cVRFXChlPbsd1aSSYme4Aa0oHA
JTgsoUPRdqZSOym4JBiGKSMUga6CWTOqq3KZmjQCThez91DnATZ4ITHFvrJUa7o3
uHC/QcDMewRjkZSzx8NZ
=gkQ9
-END PGP SIGNATURE-

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



RE: Stateless application is very slow using LDAP authentication

2014-04-22 Thread Frédéric Poliquin
> When you say that you put a reverse proxy in front of Tomcat... do you mean 
> that you pushed the authentication out to the proxy layer?

Yes, I'm delegating everything to HTTPD using an AJP connector.

> This means that if the user changes their password or the group-membership 
> changes on the LDAP side, httpd won't know about those changes and therefore 
> old credentials are still valid, old group-based authentication checks will 
> yield invalid authentication decisions based upon the canonical LDAP 
> service's view of the world.

So does session caching! Actually HTTPD have a better control because it allows 
you to choose the appropriate TTL instead of assuming the same credentials for 
the whole session.

Frédéric.

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



Re: Stateless application is very slow using LDAP authentication

2014-04-22 Thread Mark Eggers

On 4/22/2014 12:16 PM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Frédéric,

On 4/22/14, 12:38 PM, Frédéric Poliquin wrote:

Passwords are protected using standard SSL. Eventually, the plan
is to move towards OAuth 2.0 with a cookie/security token but until
then I needed a quick solution...

For the other question, Apache httpd has an authentication cache
which prevents going to Active Directory every time which is not
linked to any session. It is documented here:
http://httpd.apache.org/docs/current/mod/mod_ldap.html#cache


For those readers who don't feel like reading/understanding the
documentation, what Frédéric is leaving unsaid is that mod_ldap caches
the results of various lookups. It's somewhat important to note that
the authentication information itself is not cached: there is no LDAP
token or anything like that that survives across individual requests
from a client. Instead, the result of a particular lookup are cached.

This means that if the user changes their password or the
group-membership changes on the LDAP side, httpd won't know about
those changes and therefore old credentials are still valid, old
group-based authentication checks will yield invalid authentication
decisions based upon the canonical LDAP service's view of the world.



http://httpd.apache.org/docs/current/mod/mod_ldap.html#ldapopcachettl

Balancing liveliness versus performance versus accuracy is an exercise 
left for the reader.



This may not be a big deal to you, but it's important to note that it
is a side-effect of such caching.

- -chris



. . . . just my two cents
/mde/

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



Re: Stateless application is very slow using LDAP authentication

2014-04-22 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Frédéric,

On 4/22/14, 12:38 PM, Frédéric Poliquin wrote:
> Passwords are protected using standard SSL. Eventually, the plan
> is to move towards OAuth 2.0 with a cookie/security token but until
> then I needed a quick solution...
> 
> For the other question, Apache httpd has an authentication cache 
> which prevents going to Active Directory every time which is not 
> linked to any session. It is documented here: 
> http://httpd.apache.org/docs/current/mod/mod_ldap.html#cache

For those readers who don't feel like reading/understanding the
documentation, what Frédéric is leaving unsaid is that mod_ldap caches
the results of various lookups. It's somewhat important to note that
the authentication information itself is not cached: there is no LDAP
token or anything like that that survives across individual requests
from a client. Instead, the result of a particular lookup are cached.

This means that if the user changes their password or the
group-membership changes on the LDAP side, httpd won't know about
those changes and therefore old credentials are still valid, old
group-based authentication checks will yield invalid authentication
decisions based upon the canonical LDAP service's view of the world.

This may not be a big deal to you, but it's important to note that it
is a side-effect of such caching.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTVsAqAAoJEBzwKT+lPKRYdL8QAMJMVxPYeL3+DZjrAw+hfynM
IJEeJyWipE1yQOMi5L4m7E3Kt1F5z4MmkacRfr8FPddZ/bsJ7xphChzZxcGcHm2I
4TnIVYyjzBnI+3fdtPLhAMY9X8awlWiurAKSpm4iOpY2f3GTor2ypLCoU5csy0lp
E6QFMuGfsYVNCVcMkBo9LtlgViTJ9ov3pFw+PF6KhyA7x/pyUetrD7Qe7fNKlkq3
F9Z/a+GgkHGhNt6/f5zoD41QVml7P0fWjA4h0xELdO/hdgaQhl8UEoC37EIzIQMk
ZvqrqusBcopWbYghj1TZERsdISDVZnYVewOwqyCXU8x/GaYyEBCJt6BSnJh1LwK+
z7tOA5ho5NLZjUM0mKSfOuWE74ceAQGiVIZrgql8Oae2a4vLHO8/WHwhgkOmEWHN
ZiIzf/4qttq7grzXDGi/0Rqqa+Xh2SIpSETh95dd8lP+E9YnJw4WocbA75hecckK
1FI7KM9e59BP6Tm+jfDwGu9nO2jCDUvaZhqthljevXhmE9ICaxmnXmfxQPzQhakl
c7BNWLUiDjyXUHu09M/biVZ3eF9eQ8HwqPxLTDvtpaVoFZouZXYt3Dz8dxVZN3+t
rLSv2H7kGr5xXcoo1VXEseFQgB77OSzj28X/Ugt3vwwcdYz/nnV9LxT+OfAKyXws
BOLoKK1fI7/Fu6KWhk/4
=YV7b
-END PGP SIGNATURE-

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



Re: Stateless application is very slow using LDAP authentication

2014-04-22 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Frédéric,

On 4/22/14, 11:33 AM, Frédéric Poliquin wrote:
> << What if you disable authentication entirely as a test... do
> things speed-up?>> Answer is YES << Do you have a problem only
> under load or also when you are testing a single-user?>> Single
> user
> 
> What I did is to put Tomcat behind an Apache Server which solved
> my problem. Maybe it could be a good new feature to add in future 
> releases...

What would be a good new feature? When you say that you put a reverse
proxy in front of Tomcat... do you mean that you pushed the
authentication out to the proxy layer?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTVr7NAAoJEBzwKT+lPKRYBLUP/AlTqdS9wtTgWj3iOhnVsAQH
R0GiJ9GQesMlbxRD6LsUHcwgzjNASGE1Eyei6LwJlZjWLuKSsGv/06bFSn3F9N7j
ZNM+ekKXrIYfwdCJhEQxa2rUDEA0KWgd2+4X/Vb9DOR6yNlj8iZgTyo2KWPRaYM1
h/vRV5MUSpqaGBwLh5xpPUYUUnyeHVrvykBFb1opBxmxIQjEqFo6wbdCs1eWoc6Y
oh9CzP52kX7rjAK1nH9uefOCLTPHIfrW4oTbviU4l7oVd5kCuAI0jhPTUC7CWN6k
Ag4Z5zsxiSFmKu5fYsXiWJneiwSKN6Z9BgFjAA0iXDJjP7qfMVqIXwZ6hfLYEBv3
ThyKVuQr2q4eKXVythJMaguekzBTx11TV1Q1FZ8mHQc7cnRHLmGmbUyHudiO96Ii
A4CQ/TyQnq+SNG0h9XjcFRsStbHz8dK2H6j/awWNbQws9zyjakVgmMmcqqd0q0i9
ycnCKcQSi/OZjmJN8TVLUmgXZJQhVU870zYsUuTDow74NGa6rE7IzfR+C2RxMDDq
BJzsyjV+IiXJf9PbCl27ghlXBvgSc7pi2MMQxgkuRNQKiejitEbuETObiN7oIpYm
9tLBLbD+OFFbhFEWqFg8R02wtssipUjmHiyjT+QvsGoShFsmhHoBl90azBT7Q/6/
UDRpURvSe6ll1AIjXamj
=e6ZU
-END PGP SIGNATURE-

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



Re: CORS issue with Tomcat and Android Webview

2014-04-22 Thread Jose María Zaragoza
-- Forwarded message --
From: Terence M. Bandoian 
Date: 2014-04-22 20:12 GMT+02:00
Subject: Re: CORS issue with Tomcat and Android Webview
To: Tomcat Users List 


On 4/22/2014 11:03 AM, Ankit Singhal wrote:
>
> Also we tried to give the same call from Android App to some different Node
> server and things worked fine. So it seems some problem with Tomcat only.
>


A silly question:

What does it have to do Tomcat's CORS support with W3C Widget Access
specification ?

I have no idea about Phonegap but it looks like that it prefers to
follow that specification for managing requests to different domains ,
right ?

>
> On Tue, Apr 22, 2014 at 9:22 PM, Ankit Singhal wrote:
>
>> Hi All
>>
>>
>>
>> I am facing a strange problem with Tomcat 8 and CORS. I am developing a
>> Hybrid web app using ionicframework, AngularJS, Cordova as front end and
>> Tomcat 8 and Spring 3 as back-end.
>>
>>
>>
>> For easy development I am testing the functionality in chrome , where
>> things are working fine. I added CORS filter with standard configuration to
>> allow CROSS ORIGIN requests from browser.
>>
>>
>>
>> Today I converted my app into Android App and started making AJAX calls to
>> tomcat server. To my surprise things stopped working . I debugged further
>> and anomalies in the headers of browser and Android webview.
>>
>>
>>
>> Browser sends 2 requests for same call OPTION and POST. But Android
>> Webview only send POST request.
>>
>>
>>
>> Browser Request Headers:
>>
>>
>>
>> OPTION:
>>
>> Remote Address:54.254.159.166:80
>>
>> Request URL:http://medistreet.in/auth2
>>
>> Request Method:OPTIONS
>>
>> Status Code:200 OK
>>
>> Request Headers
>>
>> OPTIONS /auth2 HTTP/1.1
>>
>> Host: medistreet.in
>>
>> Connection: keep-alive
>>
>> Access-Control-Request-Method: POST
>>
>> Origin: http://localhost
>>
>> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML,
>> like Gecko) Chrome/34.0.1847.116 Safari/537.36
>>
>> Access-Control-Request-Headers: accept, content-type
>>
>> Accept: */*
>>
>> Referer: http://localhost/
>>
>> Accept-Encoding: gzip,deflate,sdch
>>
>> Accept-Language: en-US,en;q=0.8
>>
>>
>>
>>
>>
>> POST:
>>
>>
>>
>> Remote Address:54.254.159.166:80
>>
>> Request URL:http://medistreet.in/auth2
>>
>> Request Method:POST
>>
>> Status Code:200 OK
>>
>>
>>
>> Request Headers
>>
>> Accept:application/json, text/plain, */*
>>
>> Accept-Encoding:gzip,deflate,sdch
>>
>> Accept-Language:en-US,en;q=0.8
>>
>> Connection:keep-alive
>>
>> Content-Length:39
>>
>> Content-Type:application/json;charset=UTF-8
>>
>> Host:medistreet.in
>>
>> Origin:http://localhost
>>
>> Referer:http://localhost/
>>
>> User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML,
>> like Gecko) Chrome/34.0.1847.116 Safari/537.36
>>
>>
>>
>>
>>
>> Android Request Headers:
>>
>>
>>
>> Request URL:http://medistreet.in/auth2
>>
>> Request Method:POST
>>
>> Status Code:403 Forbidden
>>
>> Request Headers
>>
>> POST http://medistreet.in/auth2 
>> HTTP/1.1
>>
>> Accept: application/json, text/plain, */*
>>
>> Origin: file://
>>
>> User-Agent: Mozilla/5.0 (Linux; Android 4.4.2; XT1033 Build/KXB20.25-1.31)
>> AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/30.0.0.0 Mobile
>> Safari/537.36
>>
>> Content-Type: application/json;charset=UTF-8
>>
>>
>>
>>
>>
>> The difference here I see is with Number of headers and specially Origin
>> Header  which contains "file://". To overcome this I added  more option
>> is CORS filter:
>>
>>
>>
>> 
>>
>> CorsFilter
>>
>> org.apache.catalina.filters.CorsFilter
>>
>> 
>>
>> cors.allowed.origins
>>
>> *
>>
>> 
>>
>> 
>>
>> 
>>
>> CorsFilter
>>
>> /*
>>
>> 
>>
>>
>>
>> Another strange thing is that when we send the same Android request
>> Headers from POSTMAN (chrome REST plugin) request is successful.
>>
>>
>>
>> POSTMAN Headers:
>>
>>
>>
>> Remote Address:54.254.159.166:80
>>
>> Request URL:http://medistreet.in/auth2
>>
>> Request Method:POST
>>
>> Status Code:200 OK
>>
>> Request Headers
>>
>> Accept:application/json, text/plain, */*
>>
>> Accept-Encoding:gzip,deflate,sdch
>>
>> Accept-Language:en-US,en;q=0.8
>>
>> Cache-Control:no-cache
>>
>> Connection:keep-alive
>>
>> Content-Length:39
>>
>> Content-Type:application/json;charset=UTF-8
>>
>> Cookie:fbm_464284963672217=base_domain=.medistreet.in;
>> JSESSIONID=87435755F03D7B045DD6E33D1D16AC51;
>> fbsr_464284963672217=dUjASqF-nWquTFPk_-5wAtI0jTImBNkVxglUT-gHNSw.eyJhbGdvcml0aG0iOiJITUFDLVNIQTI1NiIsImNvZGUiOiJBUUQ0UEZZVXE4eDFIa3V6OW9RV3RlVzE4clQ3SmtVRjBzU1VVcXhfV1BENG8tV1BZYjZuTVdDdDJGMmw4TjJUeUxLSzhIYUU1TUc2MkY5cXZOaXRMN3NGdklNZkhySmluYkdjMWs1THAyZnZYa2Zpa1lLVGJ0OWlZeXVvRDNWUDhTblp4czJCeTQ4RTlYY1ZjUmhGWGJsNnFMeG5YcWxxQ0d3b0hRM1ctRWhlLU02ejVITnhhakJtaVFRVk9PanFBVUtMSlk4Y3pLa0RtejFSY3RjTEFRaW16X1lkLUFkUngxUGwzajVNczdWOFdiMW9xeC05QjA0T2xraXktVU9ZalpSRUJsZjhibnZjQXQ2aUZTc1d2QTA3TjVUYnFIekVxQ0JIYjJNRG4tSUJhajl6TEMwQlVpckM0YzJXbC1GVDNhcyIsImlzc3VlZF9hdCI6MTM5ODE4MDg2NCwidXNlcl9pZCI6Ij

Re: CORS issue with Tomcat and Android Webview

2014-04-22 Thread Terence M. Bandoian

On 4/22/2014 11:03 AM, Ankit Singhal wrote:

Also we tried to give the same call from Android App to some different Node
server and things worked fine. So it seems some problem with Tomcat only.


On Tue, Apr 22, 2014 at 9:22 PM, Ankit Singhal wrote:


Hi All



I am facing a strange problem with Tomcat 8 and CORS. I am developing a
Hybrid web app using ionicframework, AngularJS, Cordova as front end and
Tomcat 8 and Spring 3 as back-end.



For easy development I am testing the functionality in chrome , where
things are working fine. I added CORS filter with standard configuration to
allow CROSS ORIGIN requests from browser.



Today I converted my app into Android App and started making AJAX calls to
tomcat server. To my surprise things stopped working . I debugged further
and anomalies in the headers of browser and Android webview.



Browser sends 2 requests for same call OPTION and POST. But Android
Webview only send POST request.



Browser Request Headers:



OPTION:

Remote Address:54.254.159.166:80

Request URL:http://medistreet.in/auth2

Request Method:OPTIONS

Status Code:200 OK

Request Headers

OPTIONS /auth2 HTTP/1.1

Host: medistreet.in

Connection: keep-alive

Access-Control-Request-Method: POST

Origin: http://localhost

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/34.0.1847.116 Safari/537.36

Access-Control-Request-Headers: accept, content-type

Accept: */*

Referer: http://localhost/

Accept-Encoding: gzip,deflate,sdch

Accept-Language: en-US,en;q=0.8





POST:



Remote Address:54.254.159.166:80

Request URL:http://medistreet.in/auth2

Request Method:POST

Status Code:200 OK



Request Headers

Accept:application/json, text/plain, */*

Accept-Encoding:gzip,deflate,sdch

Accept-Language:en-US,en;q=0.8

Connection:keep-alive

Content-Length:39

Content-Type:application/json;charset=UTF-8

Host:medistreet.in

Origin:http://localhost

Referer:http://localhost/

User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/34.0.1847.116 Safari/537.36





Android Request Headers:



Request URL:http://medistreet.in/auth2

Request Method:POST

Status Code:403 Forbidden

Request Headers

POST http://medistreet.in/auth2 HTTP/1.1

Accept: application/json, text/plain, */*

Origin: file://

User-Agent: Mozilla/5.0 (Linux; Android 4.4.2; XT1033 Build/KXB20.25-1.31)
AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/30.0.0.0 Mobile
Safari/537.36

Content-Type: application/json;charset=UTF-8





The difference here I see is with Number of headers and specially Origin
Header  which contains "file://". To overcome this I added  more option
is CORS filter:





CorsFilter

org.apache.catalina.filters.CorsFilter



cors.allowed.origins

*







CorsFilter

/*





Another strange thing is that when we send the same Android request
Headers from POSTMAN (chrome REST plugin) request is successful.



POSTMAN Headers:



Remote Address:54.254.159.166:80

Request URL:http://medistreet.in/auth2

Request Method:POST

Status Code:200 OK

Request Headers

Accept:application/json, text/plain, */*

Accept-Encoding:gzip,deflate,sdch

Accept-Language:en-US,en;q=0.8

Cache-Control:no-cache

Connection:keep-alive

Content-Length:39

Content-Type:application/json;charset=UTF-8

Cookie:fbm_464284963672217=base_domain=.medistreet.in;
JSESSIONID=87435755F03D7B045DD6E33D1D16AC51;
fbsr_464284963672217=dUjASqF-nWquTFPk_-5wAtI0jTImBNkVxglUT-gHNSw.eyJhbGdvcml0aG0iOiJITUFDLVNIQTI1NiIsImNvZGUiOiJBUUQ0UEZZVXE4eDFIa3V6OW9RV3RlVzE4clQ3SmtVRjBzU1VVcXhfV1BENG8tV1BZYjZuTVdDdDJGMmw4TjJUeUxLSzhIYUU1TUc2MkY5cXZOaXRMN3NGdklNZkhySmluYkdjMWs1THAyZnZYa2Zpa1lLVGJ0OWlZeXVvRDNWUDhTblp4czJCeTQ4RTlYY1ZjUmhGWGJsNnFMeG5YcWxxQ0d3b0hRM1ctRWhlLU02ejVITnhhakJtaVFRVk9PanFBVUtMSlk4Y3pLa0RtejFSY3RjTEFRaW16X1lkLUFkUngxUGwzajVNczdWOFdiMW9xeC05QjA0T2xraXktVU9ZalpSRUJsZjhibnZjQXQ2aUZTc1d2QTA3TjVUYnFIekVxQ0JIYjJNRG4tSUJhajl6TEMwQlVpckM0YzJXbC1GVDNhcyIsImlzc3VlZF9hdCI6MTM5ODE4MDg2NCwidXNlcl9pZCI6IjU3NjI1MjI2MiJ9

Host:medistreet.in

Origin:chrome-extension://fdmmgilgnpjigdojojpjoooidkmcomcm

User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/34.0.1847.116 Safari/537.36





After this also there is no solution to the problem .  I suspect that
Android Webview is not sending something which Tomcat is rejecting.



Any help will highly be appreciated.


Regards

Ankit



Hi, Ankit-

I would double-check the documentation for the Tomcat CORS filter and 
the Cordova whitelist implementation:


https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CORS_Filter
http://docs.phonegap.com/en/3.4.0/guide_appdev_whitelist_index.md.html

Hope that helps.

-Terence Bandoian


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



Re: Stateless application is very slow using LDAP authentication

2014-04-22 Thread André Warnier

Leo Donahue wrote:

On Tue, Apr 22, 2014 at 8:48 AM, André Warnier  wrote:


Frédéric Poliquin wrote:


<< What if you disable authentication entirely as a test... do things
speed-up?>> Answer is YES
<< Do you have a problem only under load or also when you are testing a
single-user?>> Single user

What I did is to put Tomcat behind an Apache Server which solved my
problem. Maybe it could be a good new feature to add in future releases...



Can you explain how this solved your problem ?

If you are using Basic Authentication, without sessions, even httpd would
need to re-authenticate to AD/LDAP with every request, no ?


(I stand corrected, with the documentation Frédéric points to in a later post :
http://httpd.apache.org/docs/current/mod/mod_ldap.html#cache
httpd does cache the LDAP authentication information, independently of 
sessions).
So that probably answers the performance difference question also.

And I do also now understand his suggestion for an enhancement to the Tomcat JNDIRealm, to 
do the same kind of thing, if it doesn't already.







I'm somewhat more concerned for the OP if he is using Basic Authentication
and LDAP.  Passwords going over the network unprotected.  Am I the only one
seeing this?



Well, all things considered, over the last 2 years that has been a rather more secure 
method than HTTPS, no ? At least, all they could steal was your password.

;-)


P.S. I am jesting of course, and your concern is justified, particularly since Frédéric is 
talking about using an AD/LDAP system as the back-end.  Unless that AD system is only used 
for this application, that would be a concern.


(But by the way, Frédéric never said this was pure HTTP; it could all be going 
over HTTPS)


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



RE: Stateless application is very slow using LDAP authentication

2014-04-22 Thread Frédéric Poliquin
Passwords are protected using standard SSL. Eventually, the plan is to move 
towards OAuth 2.0 with a cookie/security token but until then I needed a quick 
solution...

For the other question, Apache httpd has an authentication cache which prevents 
going to Active Directory every time which is not linked to any session. It is 
documented here: http://httpd.apache.org/docs/current/mod/mod_ldap.html#cache


__ 
Frédéric Poliquin 
Conseiller en architecture de système, DTI 
frederic.poliq...@dti.ulaval.ca 
Tél. : (418) 656-2131 #5875


-Message d'origine-
De : Leo Donahue [mailto:donahu...@gmail.com] 
Envoyé : 22 avril 2014 12:01
À : Tomcat Users List
Objet : Re: Stateless application is very slow using LDAP authentication

On Tue, Apr 22, 2014 at 8:48 AM, André Warnier  wrote:

> Frédéric Poliquin wrote:
>
>> << What if you disable authentication entirely as a test... do things 
>> speed-up?>> Answer is YES << Do you have a problem only under load or 
>> also when you are testing a single-user?>> Single user
>>
>> What I did is to put Tomcat behind an Apache Server which solved my 
>> problem. Maybe it could be a good new feature to add in future releases...
>>
>>
> Can you explain how this solved your problem ?
>
> If you are using Basic Authentication, without sessions, even httpd 
> would need to re-authenticate to AD/LDAP with every request, no ?
>
>
>
I'm somewhat more concerned for the OP if he is using Basic Authentication and 
LDAP.  Passwords going over the network unprotected.  Am I the only one seeing 
this?

Leo


Re: CORS issue with Tomcat and Android Webview

2014-04-22 Thread Ankit Singhal
Also we tried to give the same call from Android App to some different Node
server and things worked fine. So it seems some problem with Tomcat only.


On Tue, Apr 22, 2014 at 9:22 PM, Ankit Singhal wrote:

> Hi All
>
>
>
> I am facing a strange problem with Tomcat 8 and CORS. I am developing a
> Hybrid web app using ionicframework, AngularJS, Cordova as front end and
> Tomcat 8 and Spring 3 as back-end.
>
>
>
> For easy development I am testing the functionality in chrome , where
> things are working fine. I added CORS filter with standard configuration to
> allow CROSS ORIGIN requests from browser.
>
>
>
> Today I converted my app into Android App and started making AJAX calls to
> tomcat server. To my surprise things stopped working . I debugged further
> and anomalies in the headers of browser and Android webview.
>
>
>
> Browser sends 2 requests for same call OPTION and POST. But Android
> Webview only send POST request.
>
>
>
> Browser Request Headers:
>
>
>
> OPTION:
>
> Remote Address:54.254.159.166:80
>
> Request URL:http://medistreet.in/auth2
>
> Request Method:OPTIONS
>
> Status Code:200 OK
>
> Request Headers
>
> OPTIONS /auth2 HTTP/1.1
>
> Host: medistreet.in
>
> Connection: keep-alive
>
> Access-Control-Request-Method: POST
>
> Origin: http://localhost
>
> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML,
> like Gecko) Chrome/34.0.1847.116 Safari/537.36
>
> Access-Control-Request-Headers: accept, content-type
>
> Accept: */*
>
> Referer: http://localhost/
>
> Accept-Encoding: gzip,deflate,sdch
>
> Accept-Language: en-US,en;q=0.8
>
>
>
>
>
> POST:
>
>
>
> Remote Address:54.254.159.166:80
>
> Request URL:http://medistreet.in/auth2
>
> Request Method:POST
>
> Status Code:200 OK
>
>
>
> Request Headers
>
> Accept:application/json, text/plain, */*
>
> Accept-Encoding:gzip,deflate,sdch
>
> Accept-Language:en-US,en;q=0.8
>
> Connection:keep-alive
>
> Content-Length:39
>
> Content-Type:application/json;charset=UTF-8
>
> Host:medistreet.in
>
> Origin:http://localhost
>
> Referer:http://localhost/
>
> User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML,
> like Gecko) Chrome/34.0.1847.116 Safari/537.36
>
>
>
>
>
> Android Request Headers:
>
>
>
> Request URL:http://medistreet.in/auth2
>
> Request Method:POST
>
> Status Code:403 Forbidden
>
> Request Headers
>
> POST http://medistreet.in/auth2 
> HTTP/1.1
>
> Accept: application/json, text/plain, */*
>
> Origin: file://
>
> User-Agent: Mozilla/5.0 (Linux; Android 4.4.2; XT1033 Build/KXB20.25-1.31)
> AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/30.0.0.0 Mobile
> Safari/537.36
>
> Content-Type: application/json;charset=UTF-8
>
>
>
>
>
> The difference here I see is with Number of headers and specially Origin
> Header  which contains "file://". To overcome this I added  more option
> is CORS filter:
>
>
>
> 
>
> CorsFilter
>
> org.apache.catalina.filters.CorsFilter
>
> 
>
> cors.allowed.origins
>
> *
>
> 
>
> 
>
> 
>
> CorsFilter
>
> /*
>
> 
>
>
>
> Another strange thing is that when we send the same Android request
> Headers from POSTMAN (chrome REST plugin) request is successful.
>
>
>
> POSTMAN Headers:
>
>
>
> Remote Address:54.254.159.166:80
>
> Request URL:http://medistreet.in/auth2
>
> Request Method:POST
>
> Status Code:200 OK
>
> Request Headers
>
> Accept:application/json, text/plain, */*
>
> Accept-Encoding:gzip,deflate,sdch
>
> Accept-Language:en-US,en;q=0.8
>
> Cache-Control:no-cache
>
> Connection:keep-alive
>
> Content-Length:39
>
> Content-Type:application/json;charset=UTF-8
>
> Cookie:fbm_464284963672217=base_domain=.medistreet.in;
> JSESSIONID=87435755F03D7B045DD6E33D1D16AC51;
> fbsr_464284963672217=dUjASqF-nWquTFPk_-5wAtI0jTImBNkVxglUT-gHNSw.eyJhbGdvcml0aG0iOiJITUFDLVNIQTI1NiIsImNvZGUiOiJBUUQ0UEZZVXE4eDFIa3V6OW9RV3RlVzE4clQ3SmtVRjBzU1VVcXhfV1BENG8tV1BZYjZuTVdDdDJGMmw4TjJUeUxLSzhIYUU1TUc2MkY5cXZOaXRMN3NGdklNZkhySmluYkdjMWs1THAyZnZYa2Zpa1lLVGJ0OWlZeXVvRDNWUDhTblp4czJCeTQ4RTlYY1ZjUmhGWGJsNnFMeG5YcWxxQ0d3b0hRM1ctRWhlLU02ejVITnhhakJtaVFRVk9PanFBVUtMSlk4Y3pLa0RtejFSY3RjTEFRaW16X1lkLUFkUngxUGwzajVNczdWOFdiMW9xeC05QjA0T2xraXktVU9ZalpSRUJsZjhibnZjQXQ2aUZTc1d2QTA3TjVUYnFIekVxQ0JIYjJNRG4tSUJhajl6TEMwQlVpckM0YzJXbC1GVDNhcyIsImlzc3VlZF9hdCI6MTM5ODE4MDg2NCwidXNlcl9pZCI6IjU3NjI1MjI2MiJ9
>
> Host:medistreet.in
>
> Origin:chrome-extension://fdmmgilgnpjigdojojpjoooidkmcomcm
>
> User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML,
> like Gecko) Chrome/34.0.1847.116 Safari/537.36
>
>
>
>
>
> After this also there is no solution to the problem .  I suspect that
> Android Webview is not sending something which Tomcat is rejecting.
>
>
>
> Any help will highly be appreciated.
>
>
> Regards
>
> Ankit
>
>
>


Re: Stateless application is very slow using LDAP authentication

2014-04-22 Thread Leo Donahue
On Tue, Apr 22, 2014 at 8:48 AM, André Warnier  wrote:

> Frédéric Poliquin wrote:
>
>> << What if you disable authentication entirely as a test... do things
>> speed-up?>> Answer is YES
>> << Do you have a problem only under load or also when you are testing a
>> single-user?>> Single user
>>
>> What I did is to put Tomcat behind an Apache Server which solved my
>> problem. Maybe it could be a good new feature to add in future releases...
>>
>>
> Can you explain how this solved your problem ?
>
> If you are using Basic Authentication, without sessions, even httpd would
> need to re-authenticate to AD/LDAP with every request, no ?
>
>
>
I'm somewhat more concerned for the OP if he is using Basic Authentication
and LDAP.  Passwords going over the network unprotected.  Am I the only one
seeing this?

Leo


CORS issue with Tomcat and Android Webview

2014-04-22 Thread Ankit Singhal
Hi All



I am facing a strange problem with Tomcat 8 and CORS. I am developing a
Hybrid web app using ionicframework, AngularJS, Cordova as front end and
Tomcat 8 and Spring 3 as back-end.



For easy development I am testing the functionality in chrome , where
things are working fine. I added CORS filter with standard configuration to
allow CROSS ORIGIN requests from browser.



Today I converted my app into Android App and started making AJAX calls to
tomcat server. To my surprise things stopped working . I debugged further
and anomalies in the headers of browser and Android webview.



Browser sends 2 requests for same call OPTION and POST. But Android Webview
only send POST request.



Browser Request Headers:



OPTION:

Remote Address:54.254.159.166:80

Request URL:http://medistreet.in/auth2

Request Method:OPTIONS

Status Code:200 OK

Request Headers

OPTIONS /auth2 HTTP/1.1

Host: medistreet.in

Connection: keep-alive

Access-Control-Request-Method: POST

Origin: http://localhost

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/34.0.1847.116 Safari/537.36

Access-Control-Request-Headers: accept, content-type

Accept: */*

Referer: http://localhost/

Accept-Encoding: gzip,deflate,sdch

Accept-Language: en-US,en;q=0.8





POST:



Remote Address:54.254.159.166:80

Request URL:http://medistreet.in/auth2

Request Method:POST

Status Code:200 OK



Request Headers

Accept:application/json, text/plain, */*

Accept-Encoding:gzip,deflate,sdch

Accept-Language:en-US,en;q=0.8

Connection:keep-alive

Content-Length:39

Content-Type:application/json;charset=UTF-8

Host:medistreet.in

Origin:http://localhost

Referer:http://localhost/

User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/34.0.1847.116 Safari/537.36





Android Request Headers:



Request URL:http://medistreet.in/auth2

Request Method:POST

Status Code:403 Forbidden

Request Headers

POST http://medistreet.in/auth2 HTTP/1.1

Accept: application/json, text/plain, */*

Origin: file:// 

User-Agent: Mozilla/5.0 (Linux; Android 4.4.2; XT1033 Build/KXB20.25-1.31)
AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/30.0.0.0 Mobile
Safari/537.36

Content-Type: application/json;charset=UTF-8





The difference here I see is with Number of headers and specially Origin
Header  which contains "file:// ". To overcome this I added
more option is CORS filter:





CorsFilter

org.apache.catalina.filters.CorsFilter



cors.allowed.origins

*







CorsFilter

/*





Another strange thing is that when we send the same Android request Headers
from POSTMAN (chrome REST plugin) request is successful.



POSTMAN Headers:



Remote Address:54.254.159.166:80

Request URL:http://medistreet.in/auth2

Request Method:POST

Status Code:200 OK

Request Headers

Accept:application/json, text/plain, */*

Accept-Encoding:gzip,deflate,sdch

Accept-Language:en-US,en;q=0.8

Cache-Control:no-cache

Connection:keep-alive

Content-Length:39

Content-Type:application/json;charset=UTF-8

Cookie:fbm_464284963672217=base_domain=.medistreet.in;
JSESSIONID=87435755F03D7B045DD6E33D1D16AC51;
fbsr_464284963672217=dUjASqF-nWquTFPk_-5wAtI0jTImBNkVxglUT-gHNSw.eyJhbGdvcml0aG0iOiJITUFDLVNIQTI1NiIsImNvZGUiOiJBUUQ0UEZZVXE4eDFIa3V6OW9RV3RlVzE4clQ3SmtVRjBzU1VVcXhfV1BENG8tV1BZYjZuTVdDdDJGMmw4TjJUeUxLSzhIYUU1TUc2MkY5cXZOaXRMN3NGdklNZkhySmluYkdjMWs1THAyZnZYa2Zpa1lLVGJ0OWlZeXVvRDNWUDhTblp4czJCeTQ4RTlYY1ZjUmhGWGJsNnFMeG5YcWxxQ0d3b0hRM1ctRWhlLU02ejVITnhhakJtaVFRVk9PanFBVUtMSlk4Y3pLa0RtejFSY3RjTEFRaW16X1lkLUFkUngxUGwzajVNczdWOFdiMW9xeC05QjA0T2xraXktVU9ZalpSRUJsZjhibnZjQXQ2aUZTc1d2QTA3TjVUYnFIekVxQ0JIYjJNRG4tSUJhajl6TEMwQlVpckM0YzJXbC1GVDNhcyIsImlzc3VlZF9hdCI6MTM5ODE4MDg2NCwidXNlcl9pZCI6IjU3NjI1MjI2MiJ9

Host:medistreet.in

Origin:chrome-extension://fdmmgilgnpjigdojojpjoooidkmcomcm

User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/34.0.1847.116 Safari/537.36





After this also there is no solution to the problem .  I suspect that
Android Webview is not sending something which Tomcat is rejecting.



Any help will highly be appreciated.


Regards

Ankit


Re: Include of external entity to web.xml is stopped working on 7.0.52

2014-04-22 Thread Konstantin Kolinko
2014-04-22 19:42 GMT+04:00 Viktor Gamov :
> Hello tomcat users,
> Before I can submit formal bug to the issue tracker, I want to ask here.
> I have web.xml and I include some text file in it using !ENTITY tag:
>

As I already answered about a week a go,  you have to enable this
feature in Context configuration.
See "xmlBlockExternal" attribute of Context.

> 
>  PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
> "http://java.sun.com/dtd/web-app_2_3.dtd"; [
>   **
> ]>
> 
> 
>  MyServlet
>
> com.example.MyServlet
>  
> application.classes
>  
>&remoteClasses;
>  
> 
> 
> 
>
> It worked fine until version 7.0.52. With 7.0.52, I'm getting following
> error during application deployment
>
> https://gist.github.com/gAmUssA/11183618
> 
>

If you are not citing the error message,
how to you expect others to find this discussion in the mailing list archives?

> *p.s.* Doesn't work with v8 as well.
>
> Please, advise.
>
> Thanks
>
> --
> With Best Regards,
> Vik Gamov

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



Re: Include of external entity to web.xml is stopped working on 7.0.52

2014-04-22 Thread Mark Thomas
On 22/04/2014 16:42, Viktor Gamov wrote:



> It worked fine until version 7.0.52. With 7.0.52, I'm getting following
> error during application deployment

Read this:
http://tomcat.apache.org/tomcat-7.0-doc/config/context.html

Look for this:
xmlBlockExternal

The default changed in 7.0.52.

Mark


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



Re: Stateless application is very slow using LDAP authentication

2014-04-22 Thread André Warnier

Frédéric Poliquin wrote:

<< What if you disable authentication entirely as a test... do things 
speed-up?>> Answer is YES
<< Do you have a problem only under load or also when you are testing a 
single-user?>> Single user

What I did is to put Tomcat behind an Apache Server which solved my problem. 
Maybe it could be a good new feature to add in future releases...



Can you explain how this solved your problem ?

If you are using Basic Authentication, without sessions, even httpd would need to 
re-authenticate to AD/LDAP with every request, no ?


Maybe the AD/LDAP authentication code within httpd is faster than the one in JNDIRealm, 
but you may still be issuing many more authentication requests to the AD/LDAP server than 
you would do with a better solution.  That may not be very scalable, and come back to hurt 
you when you scale up your application.



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



Include of external entity to web.xml is stopped working on 7.0.52

2014-04-22 Thread Viktor Gamov
Hello tomcat users,
Before I can submit formal bug to the issue tracker, I want to ask here.
I have web.xml and I include some text file in it using !ENTITY tag:


http://java.sun.com/dtd/web-app_2_3.dtd"; [
  **
]>


 MyServlet

com.example.MyServlet
 
application.classes
 
   &remoteClasses;
 




It worked fine until version 7.0.52. With 7.0.52, I'm getting following
error during application deployment

https://gist.github.com/gAmUssA/11183618


*p.s.* Doesn't work with v8 as well.

Please, advise.

​Thanks​

-- 
With Best Regards,
Vik Gamov


Re: [OT] catalina.out is 13G

2014-04-22 Thread André Warnier

Randhir Singh wrote:

Thanks for your quick revert.


Randir, I think that you are using the word "revert" wrongly, and it is creating some 
confusion.

"revert" means essentially "return to the previous situation" (or location, or 
belief).
The correct word here would be "response" or "reply".



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



RE: Stateless application is very slow using LDAP authentication

2014-04-22 Thread Frédéric Poliquin
<< What if you disable authentication entirely as a test... do things 
speed-up?>> Answer is YES
<< Do you have a problem only under load or also when you are testing a 
single-user?>> Single user

What I did is to put Tomcat behind an Apache Server which solved my problem. 
Maybe it could be a good new feature to add in future releases...

Thank you for your help.

Frédéric.


Re: mod_jk warning about "OPTIONS *" requests

2014-04-22 Thread André Warnier

Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

André,

On 4/22/14, 5:09 AM, André Warnier wrote:

Christopher,

Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256

All,

I'm running some load tests in a dev environment, and I'm seeing
acess log messages like these:

::1 - - [21/Apr/2014:14:15:03 +] "OPTIONS * HTTP/1.0" 200 -
"-" "Apache/2.4.9 (Amazon) OpenSSL/1.0.1g-fips PHP/5.5.10
mod_jk/1.2.40 (internal dummy connection)"

Paired with mod_jk errors like these:

[Mon Apr 21 14:15:03.359 2014] [23925:3072505728] [warn] 
map_uri_to_worker_ext::jk_uri_worker_map.c (1096): Uri * is

invalid. Uri must start with /

This happens to be running Apache httpd 2.4.9 with mod_jk 1.2.40,
but I can see similar messages in an otherwise
identically-configured server running httpd 2.2.23 and mod_jk
1.2.37:

==> access.log <== ::1 - - [21/Apr/2014:14:20:24 +] "OPTIONS
* HTTP/1.0" 200 - "-" "Apache/2 (internal dummy connection)"

==> mod_jk.log <== [Mon Apr 21 14:20:24.159 2014]
[12384:3072042880] [warn] 
map_uri_to_worker_ext::jk_uri_worker_map.c (1057): Uri * is

invalid. Uri must start with /

In my httpd 2.4 environment, I seem to be seeing them much more 
regularly (once every second or two) than in my httpd 2.2

environment (maybe every minute or two). If possible, I'd like to
minimize the amount of stuff that goes into my mod_jk.log file,
and since this is logged at the WARN level, it's tough to justify
disabling it.

Now, I realize that the OPTIONS * messages are httpd's internal 
monitoring queries to see if workers are serviceable, so that's

not my question. My question is why mod_jk complains about them.
Perhaps a URI of "*" itself is invalid, but since httpd is known
to issue internal queries like this, why doesn't mod_jk simply
ignore them?


Just to "keep the church in the middle of the village", as they say
in my part of the world :


[OT] I'm not sure I can interpret the meaning of that. What does it mean?


1) "OPTIONS *" is a valid HTTP request. [...]


Yep, I get all this. My real question is why mod_jk is complaining
about the URI. It shouldn't.

Here's what happens in mod_jk:

httpd
- -> mod_jk.c::jk_handler
- -> jk_uri_worker_map.c::map_uri_to_worker_ext

Here's the code for map_uri_to_worker_ext, around the interesting part:

jk_uri_worker_map.c::map_uri_to_worker_ext
1056if (*uri != '/') {
1057jk_log(l, JK_LOG_WARNING,
1058"Uri %s is invalid. Uri must start with /", uri);
1059JK_TRACE_EXIT(l);
1060return NULL;
1061}

When this happens, jk_handler ultimately returns DECLINED. So,
everything works the way it should work (except possibly a bug where
Tomcat can't receive requests for "OPTIONS *")


exactly; that is most probably a bug.

 except that mod_jk

complains about a URI that it should not complain about.

I'm wondering if there's a particular reason to complain about this
URI, 


Maybe it just simplifies the code after that, which compares the mod_jk URI-mappings to 
the received request URI.


especially given that httpd (to which mod_jk is rather tightly

bound) uses these requests internally for legitimate reasons. To me,
it just seems like this message should be suppressed entirely.


The real basic issue here seems to be that mod_jk /misinterprets/
these OPTIONS requests : it takes itself the decision to reject it
and log an error, because it misinterprets the fact that, for
OPTIONS, "*" is a valid "path".


All correct, except that mod_jk returns DECLINED instead of ERROR.


I don't think it should do that.


+1


That it then logs an error is a side-effect of this
misinterpretation. Stopping mod_jk from logging this "error" would
just hide the underlying issue.


No. It would just shut it up and everything would still work fine.

It would be mildly interesting, in comparison, to know how the 
mod_proxy_ajp developers handle this case.


(*) For example, if you used a  section with a 
"SetHandler jakarta-servlet", and in that , excluded the 
OPTIONS requests (via a filter?). Or if you used mod_rewrite to set

the "no-jk" httpd env value for OPTIONS requests. Unfortunately, I
think that there is no corresponding "JkUnMount" syntax which
allows to exclude some requests based on the HTTP request Verb.


I believe that to be correct. I exclusively use JkMount, so the
"OPTIONS *" should never have mod_jk explicitly set as a request
handler... httpd is just apparently consulting mod_jk for all
requests. That's a bit unexpected, honestly (I thought mod_jk could
"register" itself as a request handler for certain URIs, but in
retrospect that would be pretty chaotic), but the situation is fairly
clear.

I would simply like to remove the warning, or maybe place it at a
lower logging level. It would be nice if "OPTIONS *" requests could be
forwarded-through to Tomcat, but it appears that it not possible with
the current mod_jk version. "OPTIONS /" would certainly work, but not
"OPTIONS *".

Re: [OT] mod_jk warning about "OPTIONS *" requests

2014-04-22 Thread André Warnier

Christopher Schultz wrote:
...




Just to "keep the church in the middle of the village", as they say
in my part of the world :


[OT] I'm not sure I can interpret the meaning of that. What does it mean?



It is a Belgian/French expression, meaning roughly "to keep things in perspective" or "not 
to go to extremes, one way or the other" or even, "in front of conflicting interests, 
choose a middle way", that kind of thing.  Like many such "cultural" things, it has a 
number of interpretations depending on the circumstances.  But you get the gist now, I guess.
Despite its seemingly religious connotations, it means the exact opposite of religious 
fanaticism.





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



Re: How to monitor performance of tomcat

2014-04-22 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Randhir,

No need to reply to me directly: I get all messages posted to the list.

There is also no need to post multiple threads on the same topic.
Stick to one thread and you'll get better replies.

I'll answer this one here, but let's stick to one of the other ones
you have posted under a better subject line.

I won't reply to this thread after this message unless you want to
pick-up your original discussion about monitoring your Tomcat and JVM.

On 4/22/14, 10:52 AM, Randhir Singh wrote:
> Thanks for your answer. The disk space is an issue as it is 99%
> right now. The mountpoint /opt is 40G and catalina.out is occupying
> 13G.

What is logging so much to that file?

> We have log rotated files being made like catalina.2014-04-16.log, 
> host-manager.2014-04-14.log, localhost.2014-04-14.log.

Good. These seem to be properly configured to rotate, then.

> I can reply to you immediately if you could specify what details
> you need about the logging configuration, the text from the files
> you require.

If you just need to rotate catalina.out, then you'll have to use
something like chronolog. logrotate isn't great for this kind of thing.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTVoNoAAoJEBzwKT+lPKRY6BoP/ijOsINxC/CPdYgDZwI2Gdss
MHHXTjdsCixrBPOLer+oE5af1920aufIqkHAw3Zv2SvA3nVZcTxp+KhQ0L0A9T4A
OiQcECl+SC/tdvncREvtESzp/kzkiR8Bw5uLJZ6DvPz5X6ui4cHg3IB4GTrhFzEv
DJFvl8xl2BhsPJRASaDghIFy/8ujbxjahHpNiTEw/3Tn6521dM3hXfKYBeKACg62
tq521JsAApcsUXpdqHF1cgDEtM3RNRagE6qlDGUQayAj2vTbF7uMvL28fTFc7I1U
1LufXQThQaKokd/6IDm+I+PLAo/raqb9MEMnbAMIv7Z5rVZu0+bjh/9nyh6SKhKF
iKbB1rzEj5MWh1zp+xG8MIpAjy8/KZO1pIKtX1BMPp6OtOxO35Zmt7Wpgs53QTUi
xlEx6s1XBoJyJR/quEA054luctrPFQnDua9qT0gM1HAx46QW9thXlxVyNY30XOhJ
BeOb2ySNA+Aj1aZDAzv1I6Apiyfwww2/iZT0avKXc0NGIPeYlg73bEjlOehf2r7+
2iq8JhqWhUZGe8fq8RO6QWgIQtXXlVJAMN+D1Z8Kf2OL+eHm4vMcj+9azAWGfpC9
F7IBWgDx/5JrSYnKUwjE3CQZRUbsp7vxoSdl5asx4uXZ7KJBAHeC//7rVg+vSvU1
I9S8JqfG3xk5bgX6c42w
=Et0Z
-END PGP SIGNATURE-

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



Re: catalina.out is 13G

2014-04-22 Thread David kerber

On 4/22/2014 10:48 AM, Randhir Singh wrote:

Thanks for your quick revert. Is it possible to rotate it without a log
rotation program like rotatelogs or cronolog? Also, how to check if
rotatelogs or cronolog is installed on the system or not.

I can revert with any details on the configuration if you need it.


I think the word you're looking for here is "reply" as in "reply to my 
question", not "revert".  In a programming forum, "revert" means to 
change a program back to a previous version, which is why several people 
asked "revert what?".






Regards

-Original Message-
From: Filip Hanik [mailto:fi...@hanik.com]
Sent: Tuesday, April 22, 2014 7:52 PM
To: Tomcat Users List
Subject: Re: catalina.out is 13G

http://www.tomcatexpert.com/knowledge-base/rotating-catalinaout-log-files


On Tue, Apr 22, 2014 at 8:20 AM, Randhir Singh
wrote:


Hi,

I have a immediate concern as the mount point on which Tomcat is
placed is 99% and on checking I found that catalina.out is 13GB. I
wanted to implement a solution for this but am not sure, can I take a
backup of catalina.out and truncate catalina.out on the running
application?

Humbly requesting a revert on an immediate basis on whether I can
truncate catalina.out after taking a backup on a running tomcat
application.

Regards

--

*STL Disclaimer:*
The content of this message may be legally privileged and confidential
and are for the use of the intended recipient(s) only. It should not
be read, copied and used by anyone other than the intended
recipient(s). If you have received this message in error, please
immediately notify the sender, preserve its confidentiality and delete
it. Before opening any attachments please check them for viruses and
defects. No employee or agent is authorised to conclude any binding
agreement on behalf of Sterlite Technologies Limited with another
party by email without express written confirmation by authorised
person. Visit us at www.sterlitetechnologies.com  Please consider
environment before printing this email !










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



RE: How to monitor performance of tomcat

2014-04-22 Thread Randhir Singh
Thanks for your answer. The disk space is an issue as it is 99% right now.
The mountpoint /opt is 40G and catalina.out is occupying 13G.

We have log rotated files being made like catalina.2014-04-16.log,
host-manager.2014-04-14.log, localhost.2014-04-14.log.

I can reply to you immediately if you could specify what details you need
about the logging configuration, the text from the files you require.

Regards

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Tuesday, April 22, 2014 8:07 PM
To: Tomcat Users List
Subject: Re: How to monitor performance of tomcat

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Randhir,

On 4/22/14, 10:03 AM, Randhir Singh wrote:
> I have come across a point which could be a reason, the catalina.out
> file has become 13G which came to notice when we were analysing space
> crunch on the mount point in which tomcat is located.

Does low-disk-space cause performance problems for you?

> Further to this, there is some log rotation which is happening.
> But, what should be the steps to check or to introduce log rotation
> otherwise.

Tomcat will rotate logs as directed. You will need to tell us about your
logging if you want help with this.

> Request you to please revert as it is urgent. I would be waiting for a
> revert.

Revert what?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTVn6UAAoJEBzwKT+lPKRYFFoP/0BVzRhfpAf1gUyhKqq5jvIk
yp7n4a01EW+rUx9fIIKIIbe25Zwgz/WEpmDoNFWJX4/QdzadK8T37K1aipxu/ogT
kFQrlI20sV57ZX6t1aA/9upNgoyRCZe4NmABZczTY1I5fbxLzSH48h6oX74Nq3FZ
/PIqpzwPtRoZFy2iFb8v5t1KAf61sNwWowhjEa74yTRLWwAzQLC7rvsfzZpjdh12
qiL+MM2pVxwrjOS65TDVrRvjxCdV23RmSiHjXL6uT+JCDYO843sQsyBe/L9Cv+SH
89iYJwlDfBTnWBzqOLFmSaEwES0WXGVzBunoHJQkQGo64p7zqQZdy1s0I7E+3maq
Edafs50rA/2P+IZVidKq830royrFmvYDef0GPHQCkK4SJDF8MbFEN0irBnAUoilH
mrI9h6t3HFOVcR2cgNdnIeWADDLktAe+3c3XmLLUk1CQ79hBK+M1iG+cRRhIv2Q3
dxpm+nzTELlQapuZ8JfnY6Uod64G3NwHaxWf/iQrCINtcclH0xhm8ve+Bx8A1fW6
mhHYnycEaD5BKfrYrgFR6ZWyo4lQYaya4aZKBCt3EKsOzDpiOgUWCgxMZmbjtXUF
Chmej6H3hhBRKEOKySs6ot6B3HVvBqdc1aAb1aUq025Pv+0ybJ7q2pdAL2U20pcA
PSafYNhPnC3NlfjvDFNF
=ixaA
-END PGP SIGNATURE-

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

-- 

*STL Disclaimer:*
The content of this message may be legally privileged and confidential and 
are for the use of the intended recipient(s) only. It should not be read, 
copied and used by anyone other than the intended recipient(s). If you have 
received this message in error, please immediately notify the sender, 
preserve its confidentiality and delete it. Before opening any attachments 
please check them for viruses and defects. No employee or agent is 
authorised to conclude any binding agreement on behalf of Sterlite 
Technologies Limited with another party by email without express written 
confirmation by authorised person. Visit us at www.sterlitetechnologies.com 
 Please consider environment before printing this email !





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



RE: catalina.out is 13G

2014-04-22 Thread Randhir Singh
Thanks for your quick revert. Is it possible to rotate it without a log
rotation program like rotatelogs or cronolog? Also, how to check if
rotatelogs or cronolog is installed on the system or not.

I can revert with any details on the configuration if you need it.

Regards

-Original Message-
From: Filip Hanik [mailto:fi...@hanik.com]
Sent: Tuesday, April 22, 2014 7:52 PM
To: Tomcat Users List
Subject: Re: catalina.out is 13G

http://www.tomcatexpert.com/knowledge-base/rotating-catalinaout-log-files


On Tue, Apr 22, 2014 at 8:20 AM, Randhir Singh
wrote:

> Hi,
>
> I have a immediate concern as the mount point on which Tomcat is
> placed is 99% and on checking I found that catalina.out is 13GB. I
> wanted to implement a solution for this but am not sure, can I take a
> backup of catalina.out and truncate catalina.out on the running
> application?
>
> Humbly requesting a revert on an immediate basis on whether I can
> truncate catalina.out after taking a backup on a running tomcat
> application.
>
> Regards
>
> --
>
> *STL Disclaimer:*
> The content of this message may be legally privileged and confidential
> and are for the use of the intended recipient(s) only. It should not
> be read, copied and used by anyone other than the intended
> recipient(s). If you have received this message in error, please
> immediately notify the sender, preserve its confidentiality and delete
> it. Before opening any attachments please check them for viruses and
> defects. No employee or agent is authorised to conclude any binding
> agreement on behalf of Sterlite Technologies Limited with another
> party by email without express written confirmation by authorised
> person. Visit us at www.sterlitetechnologies.com  Please consider
> environment before printing this email !
>
>
>
>
>

-- 

*STL Disclaimer:*
The content of this message may be legally privileged and confidential and 
are for the use of the intended recipient(s) only. It should not be read, 
copied and used by anyone other than the intended recipient(s). If you have 
received this message in error, please immediately notify the sender, 
preserve its confidentiality and delete it. Before opening any attachments 
please check them for viruses and defects. No employee or agent is 
authorised to conclude any binding agreement on behalf of Sterlite 
Technologies Limited with another party by email without express written 
confirmation by authorised person. Visit us at www.sterlitetechnologies.com 
 Please consider environment before printing this email !





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



Re: catalina.out is 13G

2014-04-22 Thread Ognjen Blagojevic

On 22.4.2014 16:22, Filip Hanik wrote:

http://www.tomcatexpert.com/knowledge-base/rotating-catalinaout-log-files


Also, there is a related issue in Bugzilla, to make things easier to 
configure:


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

-Ognjen


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



Re: catalina.out is 13G

2014-04-22 Thread Filip Hanik
check out /usr/bin/truncate

truncate --size 0 /path/to/fil



On Tue, Apr 22, 2014 at 8:28 AM, Randhir Singh
wrote:

> Thanks for your answer Leon. The space should be freed immediately on the
> system, can the catalina.out be truncated on an running system?
>
> Regards
>
> -Original Message-
> From: Leon Rosenberg [mailto:rosenberg.l...@gmail.com]
> Sent: Tuesday, April 22, 2014 7:55 PM
> To: Tomcat Users List
> Subject: Re: catalina.out is 13G
>
> Hello Randhir,
>
> whatever revert means.
> However, if you remove the file the place will be occupied on most *'nix
> system until a process restart. You will probably have to restart your
> server to free this mount point's storage anyway.
>
> regards
> Leon
>
>
> On Tue, Apr 22, 2014 at 4:20 PM, Randhir Singh
> wrote:
>
> > Hi,
> >
> > I have a immediate concern as the mount point on which Tomcat is
> > placed is 99% and on checking I found that catalina.out is 13GB. I
> > wanted to implement a solution for this but am not sure, can I take a
> > backup of catalina.out and truncate catalina.out on the running
> > application?
> >
> > Humbly requesting a revert on an immediate basis on whether I can
> > truncate catalina.out after taking a backup on a running tomcat
> > application.
> >
> > Regards
> >
> > --
> >
> > *STL Disclaimer:*
> > The content of this message may be legally privileged and confidential
> > and are for the use of the intended recipient(s) only. It should not
> > be read, copied and used by anyone other than the intended
> > recipient(s). If you have received this message in error, please
> > immediately notify the sender, preserve its confidentiality and delete
> > it. Before opening any attachments please check them for viruses and
> > defects. No employee or agent is authorised to conclude any binding
> > agreement on behalf of Sterlite Technologies Limited with another
> > party by email without express written confirmation by authorised
> > person. Visit us at www.sterlitetechnologies.com  Please consider
> > environment before printing this email !
> >
> >
> >
> >
> >
>
> --
>
> *STL Disclaimer:*
> The content of this message may be legally privileged and confidential and
> are for the use of the intended recipient(s) only. It should not be read,
> copied and used by anyone other than the intended recipient(s). If you have
> received this message in error, please immediately notify the sender,
> preserve its confidentiality and delete it. Before opening any attachments
> please check them for viruses and defects. No employee or agent is
> authorised to conclude any binding agreement on behalf of Sterlite
> Technologies Limited with another party by email without express written
> confirmation by authorised person. Visit us at
> www.sterlitetechnologies.com
>  Please consider environment before printing this email !
>
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


Re: How to specify log rotation in Tomcat 6

2014-04-22 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Randhir,

On 4/22/14, 10:15 AM, Randhir Singh wrote:
> I want to know how to specify log rotation in Tomcat 6. I tried
> searching for information but I could not find anything
> substantial. The mount point on which Tomcat is placed is 99% and I
> wanted to understand the log rotation.

http://tomcat.apache.org/tomcat-6.0-doc/logging.html
??

> Humbly requesting a revert on this as it a immediate problem.

Revert what?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTVn7BAAoJEBzwKT+lPKRYjWgP/RYnZ4IVGy3FfenvMDRJCOsU
8trdUQyxw1qg8v1KIU49wFdq/C2+dtzYH/q2HHbtvAVKl6rVkjj4Kahba9TN76sS
NLS/aol2NHyk8TSN9pmoNyiCGsN/xi55OoM1y7MAYtWXtfzGEofV5HvqBUhbwUOr
q90+0FH5SuRWpLzjNtKegHWYc9ulguz20CvwQVn/lruwKU6pfM4e1bZbMkcIVRZC
XnqKgY9EzZ/LPPxpwNZbknx57hYtMgLIo+sQ5+slJ+OUloDoTWQVbbRToQu6MzFO
609zMS+YociuecUt9Ma5hwoW+F7/aCB8Vr9jvP3coVz2+qut/PzK4Zo7JzLXia9W
lTtQtA7hRknOBPMsn60fiqcvh1V5JnYRLE6YwlPKyDMIXq7StyplyW69OzniW32Y
b24aGMlzM4O5GrYrAKCJ+e18G41eLFtw17l7887Q7boyNnwNdUf+naUdsFNyQEHi
rcuADt8aBDj97F6dfVJYj7wzruSMQsiOV5GVoOVQlHmXboV/PUz0Rq+Vr++kr7VQ
ud+s0z3D3hc6+kBCIsERW69UBBPh6uyNO+/mPkFcWJ4f/4tx6GbfYvP8a/kVxnBK
r/GROPXeX/wbyLhGV1SgZXOZyNf8/3AgNqOojts/H3UVeiZFcb0YCmFzJ4DlAbQP
0VLRkQJagbn3w3/quKA5
=PMTj
-END PGP SIGNATURE-

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



Re: catalina.out is 13G

2014-04-22 Thread Frederik Nosi

On 04/22/2014 04:28 PM, Randhir Singh wrote:

Thanks for your answer Leon. The space should be freed immediately on the
system, can the catalina.out be truncated on an running system?


On Uniux the classic trick is:

: > catalina.out


This command empties the file, you get free space on your filesystem but 
you'l lose all content in catalina.out



As another option, you can use cronolog for catalina.out


Bye,
Frederik



Regards

-Original Message-
From: Leon Rosenberg [mailto:rosenberg.l...@gmail.com]
Sent: Tuesday, April 22, 2014 7:55 PM
To: Tomcat Users List
Subject: Re: catalina.out is 13G

Hello Randhir,

whatever revert means.
However, if you remove the file the place will be occupied on most *'nix
system until a process restart. You will probably have to restart your
server to free this mount point's storage anyway.

regards
Leon


On Tue, Apr 22, 2014 at 4:20 PM, Randhir Singh
wrote:


Hi,

I have a immediate concern as the mount point on which Tomcat is
placed is 99% and on checking I found that catalina.out is 13GB. I
wanted to implement a solution for this but am not sure, can I take a
backup of catalina.out and truncate catalina.out on the running
application?

Humbly requesting a revert on an immediate basis on whether I can
truncate catalina.out after taking a backup on a running tomcat
application.

Regards

--

*STL Disclaimer:*
The content of this message may be legally privileged and confidential
and are for the use of the intended recipient(s) only. It should not
be read, copied and used by anyone other than the intended
recipient(s). If you have received this message in error, please
immediately notify the sender, preserve its confidentiality and delete
it. Before opening any attachments please check them for viruses and
defects. No employee or agent is authorised to conclude any binding
agreement on behalf of Sterlite Technologies Limited with another
party by email without express written confirmation by authorised
person. Visit us at www.sterlitetechnologies.com  Please consider
environment before printing this email !








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



Re: How to monitor performance of tomcat

2014-04-22 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Randhir,

On 4/22/14, 10:03 AM, Randhir Singh wrote:
> I have come across a point which could be a reason, the
> catalina.out file has become 13G which came to notice when we were
> analysing space crunch on the mount point in which tomcat is
> located.

Does low-disk-space cause performance problems for you?

> Further to this, there is some log rotation which is happening.
> But, what should be the steps to check or to introduce log rotation
> otherwise.

Tomcat will rotate logs as directed. You will need to tell us about
your logging if you want help with this.

> Request you to please revert as it is urgent. I would be waiting
> for a revert.

Revert what?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTVn6UAAoJEBzwKT+lPKRYFFoP/0BVzRhfpAf1gUyhKqq5jvIk
yp7n4a01EW+rUx9fIIKIIbe25Zwgz/WEpmDoNFWJX4/QdzadK8T37K1aipxu/ogT
kFQrlI20sV57ZX6t1aA/9upNgoyRCZe4NmABZczTY1I5fbxLzSH48h6oX74Nq3FZ
/PIqpzwPtRoZFy2iFb8v5t1KAf61sNwWowhjEa74yTRLWwAzQLC7rvsfzZpjdh12
qiL+MM2pVxwrjOS65TDVrRvjxCdV23RmSiHjXL6uT+JCDYO843sQsyBe/L9Cv+SH
89iYJwlDfBTnWBzqOLFmSaEwES0WXGVzBunoHJQkQGo64p7zqQZdy1s0I7E+3maq
Edafs50rA/2P+IZVidKq830royrFmvYDef0GPHQCkK4SJDF8MbFEN0irBnAUoilH
mrI9h6t3HFOVcR2cgNdnIeWADDLktAe+3c3XmLLUk1CQ79hBK+M1iG+cRRhIv2Q3
dxpm+nzTELlQapuZ8JfnY6Uod64G3NwHaxWf/iQrCINtcclH0xhm8ve+Bx8A1fW6
mhHYnycEaD5BKfrYrgFR6ZWyo4lQYaya4aZKBCt3EKsOzDpiOgUWCgxMZmbjtXUF
Chmej6H3hhBRKEOKySs6ot6B3HVvBqdc1aAb1aUq025Pv+0ybJ7q2pdAL2U20pcA
PSafYNhPnC3NlfjvDFNF
=ixaA
-END PGP SIGNATURE-

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



Re: Stateless application is very slow using LDAP authentication

2014-04-22 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Frédéric,

On 4/22/14, 9:29 AM, Frédéric Poliquin wrote:
> Hi,
> 
> I'm working on a stateless application which does not create an
> http session. This application has a standard security constraint 
> requesting basic authentication on all resources.
> 
> Tomcat is configured using a standard JNDIRealm to authenticate 
> against Active Directory. Authentication and authorisation are 
> working fine but with this configuration, the application is very 
> slow; we even get timeouts from requirejs. The documentation says:
> 
> "Once a user has been authenticated, the user (and his or her 
> associated roles) are cached within Tomcat for the duration of the 
> user's login. (For FORM-based authentication, that means until the 
> session times out or is invalidated; for BASIC authentication,
> that means until the user closes their browser). The cached user is
> not saved and restored across sessions serialisations. Any changes
> to the directory information for an already authenticated user will
> not be reflected until the next time that user logs on again."
> 
> Does Tomcat have a cache outside the http session? Is there a 
> workaround to get one? Does Tomcat can be used as a simple file 
> server with LDAP authentication?
> 
> We are using Tomcat 7.0.53 with JDK  1.7.0_55 on Windows Server
> 2008 R2.

Have you used a profiler or crude thread dumps to determine the reason
for the slowness? What if you disable authentication entirely as a
test... do things speed-up?

The javadoc for JNDIRealm says that authenticate() is synchronized
because there is no connection-pooling implemented to the AD server.
Do you have a problem only under load or also when you are testing a
single-user?

The AuthenticatorBase component (parent of (HTTP)BasicAuthenticator)
implements a caching mechanism for requests and sessions (if in
existence) to improve performance. Because you have disabled sessions
(or avoided their creation), you are not benefitting from this caching
mechanism.

The BasicAuthenticatorValve (which is being used whether you
explicitly declare it or not) has a "alwaysUseSession" attribute which
you can flip in order to force the creation of sessions to enable this
type of caching.
http://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#Basic_Authenticator_Valve

This will always create a session for the client. But, since you are
not using the sessions for anything else (i.e. stateless), switching
servers will not be a problem for the client: they will experience a
short delay while waiting to authenticate with the new server if they
have to switch.

In order to get the most benefit from this caching feature, you should
enable session stickiness on your load balancer(s).

Hope that helps,
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTVn47AAoJEBzwKT+lPKRYPAQQAJKxelUwxdiAHUOv9U42lhbo
ZPsJdwmtEQHCeTL6+ckSU7IGA4zymTV5V6w9JqITSBdzksjZwwVCdht+e3kL7bht
aWmZbDrmwqHim4JROjI2vQxLbTtQC4u0fwwScrt+7kMS9VpdFN4psZ3y2NgKtmIu
ZDLIuFCpz4+3qh6J1j57VViOJXb/mNnh9tHW8tS6ZZex0/DBflSZa9w+/FQlEGAk
sKTGtOVWr6hKVd4S/gFFHQH9OtNnm8E8KSvZFYM8ndjBbgg0OaTR1T6eBBoSlJ5Z
bNlzXLghcTIbTWAzvqCa1u93y0nKBrufde6cw94Dlx//5mSrmUefltiVOT1PmK2e
g4jYhALUBJE6k/0yXfTnqd3obN60SMnglLeWajhqSctJ0k2DhMQJwZ0P80+TxBnH
01oyCL4GLkeKC4HddJecECSju8gi5SCGLnUL6yLSWyDUJB1XeNfe22UJUCJTIMdb
+3c3rTMVMWi08dez2K5bCsEHt1kZOIS3y1DvcZ8kEz4eIqf37bwLahw3ssiwgjLx
NY5c33+3OnW2kh+7V4wNqwXNzeOcVN6dhnaZpNTEAlo1STpRyb6drxscThBA3i3q
+kmqKLwc627OW70xAwzmzM/WpqQoHJkDynjo1KfhADuUavNLEtzkaCxt98M2B0cZ
aFm+ZyzlCu0MwAyDrOph
=WyYW
-END PGP SIGNATURE-

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



RE: catalina.out is 13G

2014-04-22 Thread Randhir Singh
Thanks for your answer Leon. The space should be freed immediately on the
system, can the catalina.out be truncated on an running system?

Regards

-Original Message-
From: Leon Rosenberg [mailto:rosenberg.l...@gmail.com]
Sent: Tuesday, April 22, 2014 7:55 PM
To: Tomcat Users List
Subject: Re: catalina.out is 13G

Hello Randhir,

whatever revert means.
However, if you remove the file the place will be occupied on most *'nix
system until a process restart. You will probably have to restart your
server to free this mount point's storage anyway.

regards
Leon


On Tue, Apr 22, 2014 at 4:20 PM, Randhir Singh
wrote:

> Hi,
>
> I have a immediate concern as the mount point on which Tomcat is
> placed is 99% and on checking I found that catalina.out is 13GB. I
> wanted to implement a solution for this but am not sure, can I take a
> backup of catalina.out and truncate catalina.out on the running
> application?
>
> Humbly requesting a revert on an immediate basis on whether I can
> truncate catalina.out after taking a backup on a running tomcat
> application.
>
> Regards
>
> --
>
> *STL Disclaimer:*
> The content of this message may be legally privileged and confidential
> and are for the use of the intended recipient(s) only. It should not
> be read, copied and used by anyone other than the intended
> recipient(s). If you have received this message in error, please
> immediately notify the sender, preserve its confidentiality and delete
> it. Before opening any attachments please check them for viruses and
> defects. No employee or agent is authorised to conclude any binding
> agreement on behalf of Sterlite Technologies Limited with another
> party by email without express written confirmation by authorised
> person. Visit us at www.sterlitetechnologies.com  Please consider
> environment before printing this email !
>
>
>
>
>

-- 

*STL Disclaimer:*
The content of this message may be legally privileged and confidential and 
are for the use of the intended recipient(s) only. It should not be read, 
copied and used by anyone other than the intended recipient(s). If you have 
received this message in error, please immediately notify the sender, 
preserve its confidentiality and delete it. Before opening any attachments 
please check them for viruses and defects. No employee or agent is 
authorised to conclude any binding agreement on behalf of Sterlite 
Technologies Limited with another party by email without express written 
confirmation by authorised person. Visit us at www.sterlitetechnologies.com 
 Please consider environment before printing this email !





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



Re: Best practice to programmatically get the disableURLRewriting context attribute value

2014-04-22 Thread lo lo
I will use a filter to remove and prevent the jsessionid in the URL. It's
indeed really simpler!
Thanks for your answer and your suggestions.

Lo





2014-04-18 22:41 GMT+02:00 Christopher Schultz :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Lo,
>
> On 4/17/14, 10:44 AM, Sauvel Laurent wrote:
> > 1. Before testing the code below with different Tomcat
> > configurations, I would like to know if there is a better way to
> > do what I want. I'm not really satisfied with this code that is
> > closely related to Tomcat classes.
>
> You are trying to fetch a value from a Tomcat-specific
> configuration... why do you think you can do this in a
> non-Tomcat-specific way?
>
> > 2. The original problem is that I would like to:
> >
> > a) prevent Tomcat (6.0.x, including versions older than 6.0.30)
> > from adding the ";jsessionid=xxx" string to the URL when there is
> > no cookie named JSESSIONID in the client browser
>
> Use a Filter, just like everybody else. This will work in any container.
>
> > b) prevent jsessionid hijacking via the url, i.e redirect to an
> > error page when the "jsessionid=" string is detected in the URL
>
> You can do this with a Filter, too. No Tomcat-specific code necessary.
>
> AFAICT, you don't need to sniff/set the disableURLRewriting attribute
> value at all.
>
> Just FYI, preventing "jsessionid hijacking" does not prevent session
> hijacking at all. Forging the JSESSIONID cookie is just as easy as
> forging a jsessiondi URL path parameter. The difference is that you
> can't email a cookie-laden URL to someone.
>
> The real way to prevent session hijacking is to change the session id
> after a login, which is exactly what Tomcat already does for you, so
> you shouldn't have to worry about it at all.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJTUY3dAAoJEBzwKT+lPKRYzgEP/3dXC9Eq0MGpunHdS/iWwbRF
> h83Zodu6Q4VMfj9ugvCdch4MtkAMMoLJCX+eFD9BsDmI+Y+Uou1A1ogL36u/5Lxh
> QyTt8T7BJIs6ZJK/FemCbzKbNPwAfJXZZ0BqWiG/lSE9ZvmI8Pn/DHHIylZZKEMe
> /dTYiNKxEChl7U2qzs/vY5Gh8xzoKnB0JXvVxozVjRgnw9UiWKUlLWy7WvN1YjJF
> 4ET0FcMaRIJbiEIxmPMAaHkQSs8ctApU2WMASUS+zqiNnJ9iLMEfyG+ime5PispG
> JkmR9EAKk2Y/epKy7BAgBIHpGLiHA0H+knEP7ITJj1kWYvZF5IPO9FwR/TMsKTyl
> PhpU80ZF5U8S7du2qAK5K438ms2E/oWTqVAf4yOtsZrIk4C5p5E2ZV4j4anzpwgf
> cTiZHTJhIM6TerYDdReEE11DjH14nPmeV/V/OHLHUEUMhblfhH1TsvDnESsZ0YK3
> fq0qIsmHSgy5Nec2jCe+bUKomYruZBkMzoHL0JbqYW9UYRvoFgRWDJLzs3PVIfZi
> PKArFozMM7+Ggv8irzNSmnyiT/v6TIo8axmIEYrmJAKWXiIHHuQBMdyJ5ntv66+w
> hwm5d/zVn35QVdfGHWMeZG2Cn4z9ch7Gb4zv94M5cJQ9QaIKu5aZPDj9QuJ3RYUM
> R8zWdkTyDumXntA7nJdY
> =tWIu
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


Re: catalina.out is 13G

2014-04-22 Thread Leon Rosenberg
Hello Randhir,

whatever revert means.
However, if you remove the file the place will be occupied on most *'nix
system until a process restart. You will probably have to restart your
server to free this mount point's storage anyway.

regards
Leon


On Tue, Apr 22, 2014 at 4:20 PM, Randhir Singh
wrote:

> Hi,
>
> I have a immediate concern as the mount point on which Tomcat is placed is
> 99% and on checking I found that catalina.out is 13GB. I wanted to
> implement a solution for this but am not sure, can I take a backup of
> catalina.out and truncate catalina.out on the running application?
>
> Humbly requesting a revert on an immediate basis on whether I can truncate
> catalina.out after taking a backup on a running tomcat application.
>
> Regards
>
> --
>
> *STL Disclaimer:*
> The content of this message may be legally privileged and confidential and
> are for the use of the intended recipient(s) only. It should not be read,
> copied and used by anyone other than the intended recipient(s). If you have
> received this message in error, please immediately notify the sender,
> preserve its confidentiality and delete it. Before opening any attachments
> please check them for viruses and defects. No employee or agent is
> authorised to conclude any binding agreement on behalf of Sterlite
> Technologies Limited with another party by email without express written
> confirmation by authorised person. Visit us at
> www.sterlitetechnologies.com
>  Please consider environment before printing this email !
>
>
>
>
>


Re: catalina.out is 13G

2014-04-22 Thread Filip Hanik
http://www.tomcatexpert.com/knowledge-base/rotating-catalinaout-log-files


On Tue, Apr 22, 2014 at 8:20 AM, Randhir Singh
wrote:

> Hi,
>
> I have a immediate concern as the mount point on which Tomcat is placed is
> 99% and on checking I found that catalina.out is 13GB. I wanted to
> implement a solution for this but am not sure, can I take a backup of
> catalina.out and truncate catalina.out on the running application?
>
> Humbly requesting a revert on an immediate basis on whether I can truncate
> catalina.out after taking a backup on a running tomcat application.
>
> Regards
>
> --
>
> *STL Disclaimer:*
> The content of this message may be legally privileged and confidential and
> are for the use of the intended recipient(s) only. It should not be read,
> copied and used by anyone other than the intended recipient(s). If you have
> received this message in error, please immediately notify the sender,
> preserve its confidentiality and delete it. Before opening any attachments
> please check them for viruses and defects. No employee or agent is
> authorised to conclude any binding agreement on behalf of Sterlite
> Technologies Limited with another party by email without express written
> confirmation by authorised person. Visit us at
> www.sterlitetechnologies.com
>  Please consider environment before printing this email !
>
>
>
>
>


catalina.out is 13G

2014-04-22 Thread Randhir Singh
Hi,

I have a immediate concern as the mount point on which Tomcat is placed is
99% and on checking I found that catalina.out is 13GB. I wanted to
implement a solution for this but am not sure, can I take a backup of
catalina.out and truncate catalina.out on the running application?

Humbly requesting a revert on an immediate basis on whether I can truncate
catalina.out after taking a backup on a running tomcat application.

Regards

-- 

*STL Disclaimer:*
The content of this message may be legally privileged and confidential and 
are for the use of the intended recipient(s) only. It should not be read, 
copied and used by anyone other than the intended recipient(s). If you have 
received this message in error, please immediately notify the sender, 
preserve its confidentiality and delete it. Before opening any attachments 
please check them for viruses and defects. No employee or agent is 
authorised to conclude any binding agreement on behalf of Sterlite 
Technologies Limited with another party by email without express written 
confirmation by authorised person. Visit us at www.sterlitetechnologies.com 
 Please consider environment before printing this email !






Re: mod_jk warning about "OPTIONS *" requests

2014-04-22 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

André,

On 4/22/14, 5:09 AM, André Warnier wrote:
> Christopher,
> 
> Christopher Schultz wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>> 
>> All,
>> 
>> I'm running some load tests in a dev environment, and I'm seeing
>> acess log messages like these:
>> 
>> ::1 - - [21/Apr/2014:14:15:03 +] "OPTIONS * HTTP/1.0" 200 -
>> "-" "Apache/2.4.9 (Amazon) OpenSSL/1.0.1g-fips PHP/5.5.10
>> mod_jk/1.2.40 (internal dummy connection)"
>> 
>> Paired with mod_jk errors like these:
>> 
>> [Mon Apr 21 14:15:03.359 2014] [23925:3072505728] [warn] 
>> map_uri_to_worker_ext::jk_uri_worker_map.c (1096): Uri * is
>> invalid. Uri must start with /
>> 
>> This happens to be running Apache httpd 2.4.9 with mod_jk 1.2.40,
>> but I can see similar messages in an otherwise
>> identically-configured server running httpd 2.2.23 and mod_jk
>> 1.2.37:
>> 
>> ==> access.log <== ::1 - - [21/Apr/2014:14:20:24 +] "OPTIONS
>> * HTTP/1.0" 200 - "-" "Apache/2 (internal dummy connection)"
>> 
>> ==> mod_jk.log <== [Mon Apr 21 14:20:24.159 2014]
>> [12384:3072042880] [warn] 
>> map_uri_to_worker_ext::jk_uri_worker_map.c (1057): Uri * is
>> invalid. Uri must start with /
>> 
>> In my httpd 2.4 environment, I seem to be seeing them much more 
>> regularly (once every second or two) than in my httpd 2.2
>> environment (maybe every minute or two). If possible, I'd like to
>> minimize the amount of stuff that goes into my mod_jk.log file,
>> and since this is logged at the WARN level, it's tough to justify
>> disabling it.
>> 
>> Now, I realize that the OPTIONS * messages are httpd's internal 
>> monitoring queries to see if workers are serviceable, so that's
>> not my question. My question is why mod_jk complains about them.
>> Perhaps a URI of "*" itself is invalid, but since httpd is known
>> to issue internal queries like this, why doesn't mod_jk simply
>> ignore them?
>> 
> 
> Just to "keep the church in the middle of the village", as they say
> in my part of the world :

[OT] I'm not sure I can interpret the meaning of that. What does it mean?

> 1) "OPTIONS *" is a valid HTTP request. [...]

Yep, I get all this. My real question is why mod_jk is complaining
about the URI. It shouldn't.

Here's what happens in mod_jk:

httpd
- -> mod_jk.c::jk_handler
- -> jk_uri_worker_map.c::map_uri_to_worker_ext

Here's the code for map_uri_to_worker_ext, around the interesting part:

jk_uri_worker_map.c::map_uri_to_worker_ext
1056if (*uri != '/') {
1057jk_log(l, JK_LOG_WARNING,
1058"Uri %s is invalid. Uri must start with /", uri);
1059JK_TRACE_EXIT(l);
1060return NULL;
1061}

When this happens, jk_handler ultimately returns DECLINED. So,
everything works the way it should work (except possibly a bug where
Tomcat can't receive requests for "OPTIONS *") except that mod_jk
complains about a URI that it should not complain about.

I'm wondering if there's a particular reason to complain about this
URI, especially given that httpd (to which mod_jk is rather tightly
bound) uses these requests internally for legitimate reasons. To me,
it just seems like this message should be suppressed entirely.

> The real basic issue here seems to be that mod_jk /misinterprets/
> these OPTIONS requests : it takes itself the decision to reject it
> and log an error, because it misinterprets the fact that, for
> OPTIONS, "*" is a valid "path".

All correct, except that mod_jk returns DECLINED instead of ERROR.

> I don't think it should do that.

+1

> That it then logs an error is a side-effect of this
> misinterpretation. Stopping mod_jk from logging this "error" would
> just hide the underlying issue.

No. It would just shut it up and everything would still work fine.

> It would be mildly interesting, in comparison, to know how the 
> mod_proxy_ajp developers handle this case.
> 
> (*) For example, if you used a  section with a 
> "SetHandler jakarta-servlet", and in that , excluded the 
> OPTIONS requests (via a filter?). Or if you used mod_rewrite to set
> the "no-jk" httpd env value for OPTIONS requests. Unfortunately, I
> think that there is no corresponding "JkUnMount" syntax which
> allows to exclude some requests based on the HTTP request Verb.

I believe that to be correct. I exclusively use JkMount, so the
"OPTIONS *" should never have mod_jk explicitly set as a request
handler... httpd is just apparently consulting mod_jk for all
requests. That's a bit unexpected, honestly (I thought mod_jk could
"register" itself as a request handler for certain URIs, but in
retrospect that would be pretty chaotic), but the situation is fairly
clear.

I would simply like to remove the warning, or maybe place it at a
lower logging level. It would be nice if "OPTIONS *" requests could be
forwarded-through to Tomcat, but it appears that it not possible with
the current mod_jk version. "OPTIONS /" would certainly work, but not
"OPTIONS *".

- -chris
-BEGIN PGP SIGNAT

How to specify log rotation in Tomcat 6

2014-04-22 Thread Randhir Singh
Hi,

I want to know how to specify log rotation in Tomcat 6. I tried searching
for information but I could not find anything substantial. The mount point
on which Tomcat is placed is 99% and I wanted to understand the log
rotation.

Humbly requesting a revert on this as it a immediate problem.

Regards

-- 

*STL Disclaimer:*
The content of this message may be legally privileged and confidential and 
are for the use of the intended recipient(s) only. It should not be read, 
copied and used by anyone other than the intended recipient(s). If you have 
received this message in error, please immediately notify the sender, 
preserve its confidentiality and delete it. Before opening any attachments 
please check them for viruses and defects. No employee or agent is 
authorised to conclude any binding agreement on behalf of Sterlite 
Technologies Limited with another party by email without express written 
confirmation by authorised person. Visit us at www.sterlitetechnologies.com 
 Please consider environment before printing this email !






Re: How to monitor performance of tomcat

2014-04-22 Thread Randhir Singh
Hi,

I have come across a point which could be a reason, the catalina.out file
has become 13G which came to notice when we were analysing space crunch on
the mount point in which tomcat is located.

Further to this, there is some log rotation which is happening. But, what
should be the steps to check or to introduce log rotation otherwise.

Request you to please revert as it is urgent. I would be waiting for a
revert.

Regards


On Mon, Apr 21, 2014 at 3:47 PM, Randhir Singh
wrote:

> Hi,
>
> I wanted input from the experts on my query below that the port 8891 does
> not respond when the command,
>
> jconsole 10.101.17.79:8891
>
> is issued when the application hangs and stops responding.
>
> Requesting inputs so that the root cause analysis of this issue can be
> found out.
>
> Regards
>
> -Original Message-
> From: Randhir Singh [mailto:randhir.si...@sterlite.com]
> Sent: Tuesday, April 15, 2014 4:20 PM
> To: 'Tomcat Users List'
> Subject: RE: How to monitor performance of tomcat
>
> There is 1 finding. We normally monitor the tomcat port using jconsole as-
>
> jconsole 10.101.17.79:8891
>
> As per my initial query, our application hangs and we need to restart
> JBoss & Tomcat. I have observed that during this time the port 8891 does
> not respond as the command,
>
> jconsole 10.101.17.79:8891
>
> does not give any console for monitoring.
>
> Requesting an update so that the root cause analysis of this issue can be
> found out.
>
> Regards
>
> -Original Message-
> From: Shanti Suresh [mailto:sha...@umich.edu]
> Sent: Saturday, April 12, 2014 1:12 AM
> To: Tomcat Users List
> Subject: Re: How to monitor performance of tomcat
>
> On Fri, Apr 11, 2014 at 3:04 PM, André Warnier  wrote:
>
> > Shanti Suresh wrote:
> >
> >> Hi Chris,
> >>
> >> On Fri, Apr 11, 2014 at 12:17 PM, Christopher Schultz <
> >> ch...@christopherschultz.net> wrote:
> >>
> >>  -BEGIN PGP SIGNED MESSAGE-
> >>> Hash: SHA256
> >>>
> >>> Shanti,
> >>>
> >>> On 4/11/14, 9:01 AM, Shanti Suresh wrote:
> >>>
>  Thank you!  Great presentation and most wonderful notes!  One
>  question - on slide #48, where the notes say, "You can see here
>  that the current usage is about 100MiB, less than the 115MiB
>  threshold we set", where is the 100MB or thereabouts shown?  Is it
>  the committed value?  I don't follow that statement.
> 
> >>> The statement refers to the "used" value.
> >>>
> >>> - -chris
> >>>
> >>> Thank you!  I got it.
> >>>
> >>
> >> The "used" value says "used 114510568".  I was looking for a value
> >> closer to 100MiB.
> >>
> >
> >   114510568  (~ 109 MB)
> > - 104857600(100 MB)
> > ===
> > 9652968   (~  9 MB)
> >
> > How much closer were you looking for ?
>
>
> Well, I don't know, maybe 1 or 2 MiB over?  The threshold is 115 MiB, so
> if the notes had said "the current usage is less than the 115MiB threshold
> we set", I might not have had any doubt.
>
>
> >
> >
> >> So in the slide, you were making a point of the current usage being
> >> less than the threshold, basically, if I am not mistaken.
> >>
> >> Thanks,
> >>
> >>   -Shanti
> >>
> >>
> >
> Thanks,
>
>   -Shanti
>

-- 

*STL Disclaimer:*
The content of this message may be legally privileged and confidential and 
are for the use of the intended recipient(s) only. It should not be read, 
copied and used by anyone other than the intended recipient(s). If you have 
received this message in error, please immediately notify the sender, 
preserve its confidentiality and delete it. Before opening any attachments 
please check them for viruses and defects. No employee or agent is 
authorised to conclude any binding agreement on behalf of Sterlite 
Technologies Limited with another party by email without express written 
confirmation by authorised person. Visit us at www.sterlitetechnologies.com 
 Please consider environment before printing this email !






RE: Stateless application is very slow using LDAP authentication

2014-04-22 Thread Frédéric Poliquin
The goal is to have a friendly cloud and cluster application. By removing all 
sessions, I can shut down any node at any time. It is mostly a JavaScript 
application relying on REST services.



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



Re: Stateless application is very slow using LDAP authentication

2014-04-22 Thread André Warnier

Frédéric Poliquin wrote:

Hi,

I'm working on a stateless application which does not create an http session. 
This application has a standard security constraint requesting basic 
authentication on all resources.

Tomcat is configured using a standard JNDIRealm to authenticate against Active 
Directory. Authentication and authorisation are working fine but with this 
configuration, the application is very slow; we even get timeouts from 
requirejs. The documentation says:

"Once a user has been authenticated, the user (and his or her associated roles) are 
cached within Tomcat for the duration of the user's login. (For FORM-based 
authentication, that means until the session times out or is invalidated; for BASIC 
authentication, that means until the user closes their browser). The cached user is not 
saved and restored across sessions serialisations. Any changes to the directory 
information for an already authenticated user will not be reflected until the next time 
that user logs on again."



I see this paragraph too, in : 
https://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html#JNDIRealm

"Additional Notes"
 and I believe that it is unclear (or maybe the parenthesis are misplaced).

I don't think that Tomcat can cache the authentication information if there is no session, 
and thus for Basic Authentication, it probably calls the LDAP server at each request, to 
re-authenticate the user.




Does Tomcat have a cache outside the http session? Is there a workaround to get 
one?
Does Tomcat can be used as a simple file server with LDAP authentication?



You should probably describe your application a bit more, and also explain why you seem to 
be adverse to sessions.


That's because it seems to me that using sessions would be the answer here.
And that is because I believe (maybe wrongly) that Tomcat *does* cache the authenticated 
user-id within the session.  Most authentication schemes would not make much sense if that 
is not the case.




We are using Tomcat 7.0.53 with JDK  1.7.0_55 on Windows Server 2008 R2.

Thank you.

Frédéric.
frederic.poliq...@dti.ulaval.ca






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



Stateless application is very slow using LDAP authentication

2014-04-22 Thread Frédéric Poliquin
Hi,

I'm working on a stateless application which does not create an http session. 
This application has a standard security constraint requesting basic 
authentication on all resources.

Tomcat is configured using a standard JNDIRealm to authenticate against Active 
Directory. Authentication and authorisation are working fine but with this 
configuration, the application is very slow; we even get timeouts from 
requirejs. The documentation says:

"Once a user has been authenticated, the user (and his or her associated roles) 
are cached within Tomcat for the duration of the user's login. (For FORM-based 
authentication, that means until the session times out or is invalidated; for 
BASIC authentication, that means until the user closes their browser). The 
cached user is not saved and restored across sessions serialisations. Any 
changes to the directory information for an already authenticated user will not 
be reflected until the next time that user logs on again."

Does Tomcat have a cache outside the http session? Is there a workaround to get 
one?
Does Tomcat can be used as a simple file server with LDAP authentication?

We are using Tomcat 7.0.53 with JDK  1.7.0_55 on Windows Server 2008 R2.

Thank you.

Frédéric.
frederic.poliq...@dti.ulaval.ca




Re: Should validationQuery commit ?

2014-04-22 Thread Mark H. Wood
On Tue, Apr 22, 2014 at 01:58:56PM +0200, Franck Routier wrote:
[snip]
> That said, I was hit by another (related) problem this week-end, with
> Oracle.
> The validation query was configured as 'select 1 from dual;'. Notice the
> semi-column: this broke everything with intermittent ORA-12516 errors.
> Removing the semi-column fixes my app with Oracle.
> Has anyone an idea of what is happening with this ; ?

I believe that the semicolon is a delimiter used by SQL*Plus (and many
other interactive tools for DBMS access).  It seems to be used by SQL
itself only in the module language and embedded SQL, where a statement
delimiter is needed.  It's not part of an SQL statement, so it
probably doesn't belong in a query string.

Commandline tools need a statement delimiter, but statements fed to
the DBMS programmatically are delimited by end-of-string.

-- 
Mark H. Wood, Lead System Programmer   mw...@iupui.edu
Machines should not be friendly.  Machines should be obedient.


signature.asc
Description: Digital signature


Re: Configuring a JSR-356 Websocket

2014-04-22 Thread Konstantin Kolinko
2014-04-22 16:43 GMT+04:00 Thom Hehl :
>
> On 04/22/2014 07:50 AM, Konstantin Kolinko wrote:
>>
>> 2014-04-22 15:31 GMT+04:00 Thom Hehl :
>>>
>>> On 04/21/2014 04:30 PM, Daniel Mikusa wrote:

 On Apr 21, 2014, at 9:58 AM, Thom Hehl  wrote:

>>
>>
>> 1. What exactly version of Tomcat you are using?
>> https://wiki.apache.org/tomcat/FAQ/Linux_Unix#Q5
>>
>> 2. Does you copy of Tomcat has the following libraries in its lib
>> directory?
>> tomcat-websocket.jar
>> websocket-api.jar
>>
>> 3. Loading of what class fails?
>>
>> Your class, or some of its dependencies?
>>
>> What is stacktrace when class loading fails?
>>
>>> I have been through the examples web.xml and cannot find any
>>> configuration for websockets
>>> at all except the listener definition for the old school version of web
>>> sockets. (I'm
>>> assuming this predated JSR-356.)
>>
>> All websockets in Tomcat 8 are JSR-356.  ("Old-school" were in Tomcat
>> 7, where both them and JSR-356 are available now).
>>
>> Best regards,
>> Konstantin Kolinko
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
> 1. Sorry, tomcat 8.0.5.
> 2. Yes.
> 3. My class. A class being used was not included on the classpath, which
> caused the class not to load.
>
> The stacktrace is IllegalStateException from ClassNotFoundException. This
> stack trace doesn't show up anywhere in tomcat 8.0.5.

If you are in debugger, you can go to "threads" view and there should
be a way to copy a thread's stacktrace in its context menu.

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



Re: Configuring a JSR-356 Websocket

2014-04-22 Thread Thom Hehl


On 04/22/2014 07:50 AM, Konstantin Kolinko wrote:

2014-04-22 15:31 GMT+04:00 Thom Hehl :

On 04/21/2014 04:30 PM, Daniel Mikusa wrote:

On Apr 21, 2014, at 9:58 AM, Thom Hehl  wrote:


Tomcat 8/Ubuntu 12.04

I have my tomcat deployed with the example echo application. I wrote a
tester that hits the URL provided and sends a message and then receives the
response back.

I want to deploy my own websocket. I have done so using the
@ServerEndpoint(value = "/websocket") annotation. When i try to hit this
from my client, I get a http 404 status.

I looked at the examples again and found that there was this
ExamplesConfig.java. Aha! I thought, a magic class that makes this
configuration work. I implemented my own and it does not change the results.
It does not appear to be calling my config at all because I have
System.out.println()s in my config and they are not showing up in the log.

I have been through the examples web.xml and cannot find any
configuration for websockets at all except the listener definition for the
old school version of web sockets. (I'm assuming this predated JSR-356.)

So how do i configure tomcat so it knows about my web socket?

I don’t think this is really Tomcat specific.  Maybe start with a JSR-356
tutorial and see if that helps to answer your questions.

http://docs.oracle.com/javaee/7/tutorial/doc/websocket.htm

I also have some examples on Github, if you’re looking for more WebSockets
examples.

https://github.com/dmikusa-pivotal/tomcat-8-features



I appreciate the help, but I've been through the tutorials. I've been
debugging the code for tomcat 8.05 and this looks like a defect. It finds my
class in ContextConfig.checkHandlesTypes and then passes it to
Introspection.loadClass(), but the class load fails and so the class isn't
added to the list of endpoints. This is the exact thing that happens when I
pull the EchoAnnotation endpoint out of the examples webapp and try it
independently. Can I get someone to verify, please?


1. What exactly version of Tomcat you are using?
https://wiki.apache.org/tomcat/FAQ/Linux_Unix#Q5

2. Does you copy of Tomcat has the following libraries in its lib directory?
tomcat-websocket.jar
websocket-api.jar

3. Loading of what class fails?

Your class, or some of its dependencies?

What is stacktrace when class loading fails?


I have been through the examples web.xml and cannot find any configuration for 
websockets
at all except the listener definition for the old school version of web 
sockets. (I'm
assuming this predated JSR-356.)

All websockets in Tomcat 8 are JSR-356.  ("Old-school" were in Tomcat
7, where both them and JSR-356 are available now).

Best regards,
Konstantin Kolinko

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


I created bug 56442 for this issue.

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



Re: Configuring a JSR-356 Websocket

2014-04-22 Thread Thom Hehl


On 04/22/2014 07:50 AM, Konstantin Kolinko wrote:

2014-04-22 15:31 GMT+04:00 Thom Hehl :

On 04/21/2014 04:30 PM, Daniel Mikusa wrote:

On Apr 21, 2014, at 9:58 AM, Thom Hehl  wrote:


Tomcat 8/Ubuntu 12.04

I have my tomcat deployed with the example echo application. I wrote a
tester that hits the URL provided and sends a message and then receives the
response back.

I want to deploy my own websocket. I have done so using the
@ServerEndpoint(value = "/websocket") annotation. When i try to hit this
from my client, I get a http 404 status.

I looked at the examples again and found that there was this
ExamplesConfig.java. Aha! I thought, a magic class that makes this
configuration work. I implemented my own and it does not change the results.
It does not appear to be calling my config at all because I have
System.out.println()s in my config and they are not showing up in the log.

I have been through the examples web.xml and cannot find any
configuration for websockets at all except the listener definition for the
old school version of web sockets. (I'm assuming this predated JSR-356.)

So how do i configure tomcat so it knows about my web socket?

I don’t think this is really Tomcat specific.  Maybe start with a JSR-356
tutorial and see if that helps to answer your questions.

http://docs.oracle.com/javaee/7/tutorial/doc/websocket.htm

I also have some examples on Github, if you’re looking for more WebSockets
examples.

https://github.com/dmikusa-pivotal/tomcat-8-features



I appreciate the help, but I've been through the tutorials. I've been
debugging the code for tomcat 8.05 and this looks like a defect. It finds my
class in ContextConfig.checkHandlesTypes and then passes it to
Introspection.loadClass(), but the class load fails and so the class isn't
added to the list of endpoints. This is the exact thing that happens when I
pull the EchoAnnotation endpoint out of the examples webapp and try it
independently. Can I get someone to verify, please?


1. What exactly version of Tomcat you are using?
https://wiki.apache.org/tomcat/FAQ/Linux_Unix#Q5

2. Does you copy of Tomcat has the following libraries in its lib directory?
tomcat-websocket.jar
websocket-api.jar

3. Loading of what class fails?

Your class, or some of its dependencies?

What is stacktrace when class loading fails?


I have been through the examples web.xml and cannot find any configuration for 
websockets
at all except the listener definition for the old school version of web 
sockets. (I'm
assuming this predated JSR-356.)

All websockets in Tomcat 8 are JSR-356.  ("Old-school" were in Tomcat
7, where both them and JSR-356 are available now).

Best regards,
Konstantin Kolinko

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


1. Sorry, tomcat 8.0.5.
2. Yes.
3. My class. A class being used was not included on the classpath, which 
caused the class not to load.


The stacktrace is IllegalStateException from ClassNotFoundException. 
This stack trace doesn't show up anywhere in tomcat 8.0.5.



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



Re: Should validationQuery commit ?

2014-04-22 Thread Franck Routier
Hi Chris,

Le 18/04/2014 20:44, Christopher Schultz a écrit :
> 
> Every database I've ever used accepts "SELECT 1 FROM DUAL" because
> Oracle did it first. You could try that.

Well, Postgresql does not (although you can of course create table
dual(id integer primary key); insert 1 into dual(id);).

That said, I was hit by another (related) problem this week-end, with
Oracle.
The validation query was configured as 'select 1 from dual;'. Notice the
semi-column: this broke everything with intermittent ORA-12516 errors.
Removing the semi-column fixes my app with Oracle.
Has anyone an idea of what is happening with this ; ?

Franck

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



Re: Configuring a JSR-356 Websocket

2014-04-22 Thread Konstantin Kolinko
2014-04-22 15:31 GMT+04:00 Thom Hehl :
>
> On 04/21/2014 04:30 PM, Daniel Mikusa wrote:
>>
>> On Apr 21, 2014, at 9:58 AM, Thom Hehl  wrote:
>>
>>> Tomcat 8/Ubuntu 12.04
>>>
>>> I have my tomcat deployed with the example echo application. I wrote a
>>> tester that hits the URL provided and sends a message and then receives the
>>> response back.
>>>
>>> I want to deploy my own websocket. I have done so using the
>>> @ServerEndpoint(value = "/websocket") annotation. When i try to hit this
>>> from my client, I get a http 404 status.
>>>
>>> I looked at the examples again and found that there was this
>>> ExamplesConfig.java. Aha! I thought, a magic class that makes this
>>> configuration work. I implemented my own and it does not change the results.
>>> It does not appear to be calling my config at all because I have
>>> System.out.println()s in my config and they are not showing up in the log.
>>>
>>> I have been through the examples web.xml and cannot find any
>>> configuration for websockets at all except the listener definition for the
>>> old school version of web sockets. (I'm assuming this predated JSR-356.)
>>>
>>> So how do i configure tomcat so it knows about my web socket?
>>
>> I don’t think this is really Tomcat specific.  Maybe start with a JSR-356
>> tutorial and see if that helps to answer your questions.
>>
>>http://docs.oracle.com/javaee/7/tutorial/doc/websocket.htm
>>
>> I also have some examples on Github, if you’re looking for more WebSockets
>> examples.
>>
>>https://github.com/dmikusa-pivotal/tomcat-8-features
>>
>>
> I appreciate the help, but I've been through the tutorials. I've been
> debugging the code for tomcat 8.05 and this looks like a defect. It finds my
> class in ContextConfig.checkHandlesTypes and then passes it to
> Introspection.loadClass(), but the class load fails and so the class isn't
> added to the list of endpoints. This is the exact thing that happens when I
> pull the EchoAnnotation endpoint out of the examples webapp and try it
> independently. Can I get someone to verify, please?


1. What exactly version of Tomcat you are using?
https://wiki.apache.org/tomcat/FAQ/Linux_Unix#Q5

2. Does you copy of Tomcat has the following libraries in its lib directory?
tomcat-websocket.jar
websocket-api.jar

3. Loading of what class fails?

Your class, or some of its dependencies?

What is stacktrace when class loading fails?

> I have been through the examples web.xml and cannot find any configuration 
> for websockets
> at all except the listener definition for the old school version of web 
> sockets. (I'm
> assuming this predated JSR-356.)

All websockets in Tomcat 8 are JSR-356.  ("Old-school" were in Tomcat
7, where both them and JSR-356 are available now).

Best regards,
Konstantin Kolinko

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



Re: java: src/network.c:441: Java_org_apache_tomcat_jni_Socket_send: Assertion failed

2014-04-22 Thread Dmitry Batiyevskiy
NIO connector works without any issues, there is some problem in apr

Regards,

Dmitry Batiyevskiy

Ardas Group Inc.

www.ardas.dp.ua


2014-03-05 16:13 GMT+02:00 Dmitry Batiyevskiy <
dmitry.batiyevs...@ardas.dp.ua>:

> Thanks
>
> Regards,
>
> Dmitry Batiyevskiy
>
> Ardas Group Inc.
>
> www.ardas.dp.ua
>
>
> 2014-03-05 16:04 GMT+02:00 Martin Gainty :
>
> FYI If you are using NIO Connector you will want to supply these NIO
>> Connector attributes
>>
>>
>> https://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Standard_Implementation
>>
>>
>>
>> If you are using SSL on NIO read SSL on NIO for that capability
>>
>>
>>
>> APR Native SSL would use these parameters
>>
>>
>>
>>
>>
>>
>> Attribute
>> Description
>>
>> SSLCACertificateFile
>>
>> See the mod_ssl documentation.
>>
>>
>> SSLCACertificatePath
>>
>> See the mod_ssl documentation.
>>
>>
>> SSLCARevocationFile
>>
>> See the mod_ssl documentation.
>>
>>
>> SSLCARevocationPath
>>
>> See the mod_ssl documentation.
>>
>>
>> SSLCertificateChainFile
>>
>> See the mod_ssl documentation.
>>
>>
>> SSLCACertificateFile
>>
>> Name of the file that contains the concatenated certificates for the
>> trusted certificate authorities. The format is PEM-encoded.
>>
>>
>> SSLCACertificatePath
>>
>> Name of the directory that contains the certificates for the trusted
>> certificate authorities. The format is PEM-encoded.
>>
>>
>> SSLCARevocationFile
>>
>> Name of the file that contains the concatenated certificate revocation
>> lists for the certificate authorities. The format is PEM-encoded.
>>
>>
>> SSLCARevocationPath
>>
>> Name of the directory that contains the certificate revocation lists for
>> the certificate authorities. The format is PEM-encoded.
>>
>>
>> SSLCertificateChainFile
>>
>> Name of the file that contains concatenated certifcates for the
>> certificate authorities which form the certifcate chain for the server
>> certificate. The format is PEM-encoded.
>>
>>
>> SSLCertificateFile
>>
>> Name of the file that contains the server certificate. The format is
>> PEM-encoded.
>>
>>
>> SSLCertificateKeyFile
>>
>> Name of the file that contains the server private key. The format is
>> PEM-encoded. The default value is the value of "SSLCertificateFile" and in
>> this case both certificate and private key have to be in this file (NOT
>> RECOMMENDED).
>>
>>
>> SSLCipherSuite
>>
>> Ciphers which may be used for communicating with clients. The default is
>> "ALL", with other acceptable values being a list of ciphers, with ":" used
>> as the delimiter (see OpenSSL documentation for the list of ciphers
>> supported).
>>
>>
>> SSLDisableCompression
>>
>> Disables compression if set to true and OpenSSL supports disabling
>> compression. Default is false which inherits the default compression
>> setting in OpenSSL.
>>
>>
>> SSLHonorCipherOrder
>>
>> Set to true to enforce the server's cipher order (from the SSLCipherSuite
>> setting) instead of allowing the client to choose the cipher (which is the
>> default).
>>
>>
>> SSLPassword
>>
>> Pass phrase for the encrypted private key. If "SSLPassword" is not
>> provided, the callback function should prompt for the pass phrase.
>>
>>
>> SSLProtocol
>>
>> Protocol which may be used for communicating with clients. The default
>> value is all, which is equivalent to SSLv3+TLSv1 with other acceptable
>> values being SSLv2, SSLv3, TLSv1 and any combination of the three protocols
>> concatenated with a plus sign. Note that the protocol SSLv2 is inherently
>> unsafe.
>>
>>
>> SSLVerifyClient
>>
>> Ask client for certificate. The default is "none", meaning the client
>> will not have the opportunity to submit a certificate. Other acceptable
>> values include "optional", "require" and "optionalNoCA".
>>
>>
>> SSLVerifyDepth
>>
>> Maximum verification depth for client certificates. The default is "10".
>>
>>
>>
>> Tweak these Connector timeout parameters to acomodate your requirement
>>
>> asyncTimeout
>>
>> connectionTimeout
>>
>> connectionUploadTimeout
>>
>> disableUploadTimeout
>>
>> executorTerminationTimeoutMillis
>>
>> keepAliveTimeout
>>
>> socket.soTimeout
>>
>> socket.unlockTimeout
>>
>> selectorTimeout
>> sessionTimeout
>>
>>
>> (yes..Mr Schultz is correct on the last statement)
>> Martin-
>>
>>
>>
>>
>>
>> > Date: Wed, 5 Mar 2014 15:12:02 +0200
>> > Subject: Re: java: src/network.c:441:
>> Java_org_apache_tomcat_jni_Socket_send: Assertion failed
>> > From: dmitry.batiyevs...@ardas.dp.ua
>> > To: users@tomcat.apache.org
>> >
>> > Atmosphere upgrade didn't help
>> >
>> > Regards,
>> >
>> > Dmitry Batiyevskiy
>> >
>> > Ardas Group Inc.
>> >
>> > www.ardas.dp.ua
>> >
>> >
>> > 2014-03-05 9:39 GMT+02:00 Dmitry Batiyevskiy <
>> dmitry.batiyevs...@ardas.dp.ua
>> > >:
>> >
>> > > We are ok with tomcat 7.0.42 and old tcnative now, and may be next
>> > > tcnative update will work appropriately
>> > > We will try updating atmosphere before trying NIO anyway
>> > >
>> > > Regards,
>> > >
>> > > Dmitry Batiyevskiy
>> > >
>> > > Ardas Gro

Re: Configuring a JSR-356 Websocket

2014-04-22 Thread Thom Hehl


On 04/22/2014 07:35 AM, Mark Thomas wrote:

On 22/04/2014 12:31, Thom Hehl wrote:


I appreciate the help, but I've been through the tutorials. I've been
debugging the code for tomcat 8.05 and this looks like a defect. It
finds my class in ContextConfig.checkHandlesTypes and then passes it to
Introspection.loadClass(), but the class load fails

Why / how does the class load fail?


and so the class
isn't added to the list of endpoints. This is the exact thing that
happens when I pull the EchoAnnotation endpoint out of the examples
webapp and try it independently. Can I get someone to verify, please?


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

As an experiment, I downloaded and ran tomcat 7.0.52 and dropped my same 
war file in. When I did so, I got an exception in the log because an 
interface I implemented wasn't found. This must be the reason the class 
wasn't loading.


I'm going to fix this and test again with tomcat 8, but, for some 
reason, tomcat 8 was eating the exception and not displaying in the log.



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



Re: Configuring a JSR-356 Websocket

2014-04-22 Thread Mark Thomas
On 22/04/2014 12:31, Thom Hehl wrote:

> I appreciate the help, but I've been through the tutorials. I've been
> debugging the code for tomcat 8.05 and this looks like a defect. It
> finds my class in ContextConfig.checkHandlesTypes and then passes it to
> Introspection.loadClass(), but the class load fails

Why / how does the class load fail?

> and so the class
> isn't added to the list of endpoints. This is the exact thing that
> happens when I pull the EchoAnnotation endpoint out of the examples
> webapp and try it independently. Can I get someone to verify, please?


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



Re: Configuring a JSR-356 Websocket

2014-04-22 Thread Thom Hehl


On 04/21/2014 04:30 PM, Daniel Mikusa wrote:

On Apr 21, 2014, at 9:58 AM, Thom Hehl  wrote:


Tomcat 8/Ubuntu 12.04

I have my tomcat deployed with the example echo application. I wrote a tester 
that hits the URL provided and sends a message and then receives the response 
back.

I want to deploy my own websocket. I have done so using the @ServerEndpoint(value = 
"/websocket") annotation. When i try to hit this from my client, I get a http 
404 status.

I looked at the examples again and found that there was this 
ExamplesConfig.java. Aha! I thought, a magic class that makes this 
configuration work. I implemented my own and it does not change the results. It 
does not appear to be calling my config at all because I have 
System.out.println()s in my config and they are not showing up in the log.

I have been through the examples web.xml and cannot find any configuration for 
websockets at all except the listener definition for the old school version of 
web sockets. (I'm assuming this predated JSR-356.)

So how do i configure tomcat so it knows about my web socket?

I don’t think this is really Tomcat specific.  Maybe start with a JSR-356 
tutorial and see if that helps to answer your questions.

   http://docs.oracle.com/javaee/7/tutorial/doc/websocket.htm

I also have some examples on Github, if you’re looking for more WebSockets 
examples.

   https://github.com/dmikusa-pivotal/tomcat-8-features

Dan




-
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

I appreciate the help, but I've been through the tutorials. I've been 
debugging the code for tomcat 8.05 and this looks like a defect. It 
finds my class in ContextConfig.checkHandlesTypes and then passes it to 
Introspection.loadClass(), but the class load fails and so the class 
isn't added to the list of endpoints. This is the exact thing that 
happens when I pull the EchoAnnotation endpoint out of the examples 
webapp and try it independently. Can I get someone to verify, please?



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



Re: mod_jk warning about "OPTIONS *" requests

2014-04-22 Thread André Warnier

Christopher,

Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

I'm running some load tests in a dev environment, and I'm seeing acess
log messages like these:

::1 - - [21/Apr/2014:14:15:03 +] "OPTIONS * HTTP/1.0" 200 - "-"
"Apache/2.4.9 (Amazon) OpenSSL/1.0.1g-fips PHP/5.5.10 mod_jk/1.2.40
(internal dummy connection)"

Paired with mod_jk errors like these:

[Mon Apr 21 14:15:03.359 2014] [23925:3072505728] [warn]
map_uri_to_worker_ext::jk_uri_worker_map.c (1096): Uri * is invalid.
Uri must start with /

This happens to be running Apache httpd 2.4.9 with mod_jk 1.2.40, but
I can see similar messages in an otherwise identically-configured
server running httpd 2.2.23 and mod_jk 1.2.37:

==> access.log <==
::1 - - [21/Apr/2014:14:20:24 +] "OPTIONS * HTTP/1.0" 200 - "-"
"Apache/2 (internal dummy connection)"

==> mod_jk.log <==
[Mon Apr 21 14:20:24.159 2014] [12384:3072042880] [warn]
map_uri_to_worker_ext::jk_uri_worker_map.c (1057): Uri * is invalid.
Uri must start with /

In my httpd 2.4 environment, I seem to be seeing them much more
regularly (once every second or two) than in my httpd 2.2 environment
 (maybe every minute or two). If possible, I'd like to minimize the
amount of stuff that goes into my mod_jk.log file, and since this is
logged at the WARN level, it's tough to justify disabling it.

Now, I realize that the OPTIONS * messages are httpd's internal
monitoring queries to see if workers are serviceable, so that's not my
question. My question is why mod_jk complains about them. Perhaps a
URI of "*" itself is invalid, but since httpd is known to issue
internal queries like this, why doesn't mod_jk simply ignore them?



Just to "keep the church in the middle of the village", as they say in my part 
of the world :

1) "OPTIONS *" is a valid HTTP request.  It is often used in the DAV context, by DAV 
clients, to figure out at the beginning of an interaction, if the server supports DAV.

(granted, here it does not seem to be such a context, but I mean in general)

2) Tomcat (with the appropriat application) supports DAV, and probably even without DAV, I 
would guess that it supports the OPTIONS request, including "OPTIONS *".


3) To generate the response to any given request, Apache httpd works as follows (in 
general terms) :
- there is a "stack" of possible "response handlers", of which the "default handler" is 
the last in the stack.
- given a request, httpd calls each of the stacked handlers in turn, passing it the 
request, and (kind of) asking it : "do you want to handle this ?".  The called handler 
then responds with one of the following status codes :
- "ERROR", meaning "I did try to handle the response to this request, but I encountered an 
error in doing so".  Given that response code, httpd skips the rest of the request 
handling phases, and goes straight to the logging phase.
- "OK", meaning : "I did handle that request, produced a response, and everything was 
fine".  Given that response code, httpd does not call any further stacked response 
handlers, and proceeds to the next request handling phase.
- "DECLINED", meaning : "No, that request was not for me, ask someone else".  Given that 
response, httpd calls the next stacked response handler, passing it the same request.

(and keeps doing so until one of the handlers returns something else than 
DECLINED.
And the last (default) handler will never return DECLINED).

4) mod_jk, for Apache httpd, is just one of these stacked response handlers.  httpd passes 
the request to mod_jk, and it is up to mod_jk to accept or decline that request.  If 
mod_jk accepts it, it forwards it to Tomcat, and whatever response Tomcat returns, it 
returns it to httpd.
httpd itself doesn't even know that behind mod_jk there is one (or several) Tomcats.  It 
just sees mod_jk as another stacked response handler, among several.


All of this to say that it is perfectly normal for mod_jk to receive this OPTIONS request 
from httpd, and to respond "OK", "ERROR" or "DECLINED" as a return status.
Furthermore, there might be cases where there is an Apache httpd in front which does not 
handle these OPTIONS requests, but there is a back-end Tomcat with DAV which does.  So 
httpd would /have to/ pass this kind of request to mod_jk (just in case), unless it is 
specifically configured to do otherwise (which you could do (*)).


The real basic issue here seems to be that mod_jk /misinterprets/ these OPTIONS requests : 
it takes itself the decision to reject it and log an error, because it misinterprets the 
fact that, for OPTIONS, "*" is a valid "path".

I don't think it should do that.
That it then logs an error is a side-effect of this misinterpretation.
Stopping mod_jk from logging this "error" would just hide the underlying issue.

It would be mildly interesting, in comparison, to know how the mod_proxy_ajp developpers 
handle this case.


(*) For example, if you used a  section with a "SetHandler 
jakarta-servlet", and in