Tomcat 5.5 vs 7.0 SSL

2014-06-02 Thread Арсений Зинченко
Hi.

Faced with very odd behavior of Tomcat 7...

Have two instances on same box - Tomcat 5.5 and Tomcat 7.

Both have same configuration - first from 5.5:

Connector port=${port.https} maxHttpHeaderSize=8192
   maxThreads=150 minSpareThreads=25 maxSpareThreads=75
   enableLookups=false disableUploadTimeout=true
   acceptCount=100 scheme=https secure=true
   clientAuth=want sslProtocol=TLS
   keystoreFile=conf/.ssl/tomcat.jks
   keyAlias=tomcat
   keystorePass=pass
   truststoreFile=conf/.ssl/trustcacerts.jks
   truststorePass=pass /

Next - from 7.0:

Connector
  port=${port.https}
  protocol=HTTP/1.1
  SSLEnabled=true
  enableLookups=false
  disableUploadTimeout=true
  scheme=https
  secure=true
  clientAuth=want
  sslProtocol=TLS
  keystoreFile=conf/.ssl/tomcat.jks
  keyAlias=tomcat
  keystorePass=pass
  truststoreFile=conf/.ssl/trustcacerts.jks
  truststorePass=pass
/

Also - both configured for CLIENT-CERT authentification (same applicaion
with same web.xml).

In browser installed  cert, but - when I'm trying open connection to 7
Tomcat - I got 401 - Cannot authenticate with the provided credentials and
no authentification attempt in log:

10.***.***.15 - - [02/Jun/2014:17:10:31 +0300] GET /service/ HTTP/1.1 401
1049

But connection to 5.5 - succsessfull with same browser  certificate.

Also, in ssldump I see that browser can't make handshake with 7.0 server:

1 2  0.0317 (0.0308)  SC  Handshake
  ServerHello
Version 3.1
session_id[32]=
  53 8c 85 d7 cf 17 a1 45 8a 4e 64 e6 95 7f 2b f3
  cb 74 0a f3 13 40 71 e8 74 50 53 1a 00 24 a0 76
cipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA
compressionMethod   NULL
  Certificate
  ServerKeyExchange
  CertificateRequest
certificate_types   rsa_sign
certificate_types   dss_sign
certificate_authority
  30 62 31 0b 30 09 06 03 55 04 06 13 02 55 41 31
  10 30 0e 06 03 55 04 08 13 07 55 6e 6b 6e 6f 77
  6e 31 0d 30 0b 06 03 55 04 07 13 04 4b 69 65 76
  31 0f 30 0d 06 03 55 04 0a 13 06 4c 75 78 6f 66
  74 31 0c 30 0a 06 03 55 04 0b 13 03 4c 4d 53 31
  13 30 11 06 03 55 04 03 13 0a 61 7a 69 6e 63 68
  65 6e 6b 6f
certificate_authority
  30 60 31 0b 30 09 06 03 55 04 06 13 02 55 41 31
// and that's all

But on 5.5 - everyting OK:

1 2  0.0213 (0.0195)  SC  Handshake
  ServerHello
Version 3.1
session_id[32]=
  53 8c 85 89 be 1f c5 63 e2 16 a0 a0 dc 5b aa 68
  0d 1c 8d b7 24 c5 13 0a 24 0a 66 9b 54 f4 b0 0f
cipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA
compressionMethod   NULL
  Certificate
  ServerKeyExchange
  ServerHelloDone
1 3  0.0256 (0.0042)  CS  Handshake
  ClientKeyExchange
DiffieHellmanClientPublicValue[96]=
  4a 39 5e f5 2a c1 58 13 6b 7c 98 0b 44 d7 9a 42
  bf 48 c2 6e a4 c6 6d 50 a7 89 8f 53 a4 54 92 a5
  81 18 1b 22 63 cf c1 63 8f 36 9f d2 59 c3 3e 67
  1f 4e 18 01 db f2 9d 07 0b 81 12 39 64 62 83 84
  78 dc 36 9b 00 34 f5 34 44 2d 92 eb d9 f6 b0 7e
  c4 66 d9 ad f2 bf 7f fb 07 56 eb 58 5d 58 41 2e

What I'm doing wrong?

Thanks.


RE: Deploying JerseyWS 2.8 w/o web.xml

2014-06-02 Thread Cuneo, Nicholas
We are using Ivy for our dependency manager, but I'm not exactly following what 
you mean.  Are you suggesting  I'm supplying a jar file in my war that  doesn't 
need to be there because Tomcat has its own version of it?

Thanks,
Nick


-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Friday, May 30, 2014 4:55 PM
To: Tomcat Users List
Subject: Re: Deploying JerseyWS 2.8 w/o web.xml

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Nick

On 5/30/14, 5:03 PM, Cuneo, Nicholas wrote:
 We are trying to deploy a webservice to tomcat 8.0.5 using Jersey WS
 2.8.  In the Jersey documentation it mentions deploying without the
 need for a web.xml in your war file using annotations, so I thought
 I’d give that a  try.

 However, when I go to deploy my webservice Tomcat is throwing the
 exception below, I can’t figure out what might be the issue.



 Some notes about our environment in case  they come into play:

 The webservice  is compiled with java 8.

 Tomcat is running on a linux server.

 As per the Jersey documentation, I have a class annotated with
 @ApplicationPath which extends ResourceConfig.  Our webservices exist
 in a separate package which is being loaded using the
 packages() function.



 30-May-2014 20:57:22.592 SEVERE [localhost-startStop-4]
 org.apache.catalina.startup.ContextConfig.processServletContainerIniti
 alizers


Failed to process JAR found at URL [/api] for
 ServletContainerInitializers for context with name [{1}]

 java.io.IOException: java.lang.ClassCastException: Cannot cast
 org.glassfish.jersey.servlet.init.JerseyServletContainerInitializer
 to javax.servlet.ServletContainerInitializer

It looks like you might have a JAR file in WEB-INF/lib that contains 
ServletContextInitializer or something similar. Tomcat should veto the loading 
of such classes, but something may have slipped-by.

Remember that runtime class is classloader + class, so the above error may be 
confusing: JerseyServletContainerInitializer does in fact extend 
ServletContainerInitializer (at least given their current API
javadoc) so the problem is likely that the ClassLoaders do not match.

Perhaps you are using Maven and it's unaware that Tomcat provides some of the 
javax.* packages itself?

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

iQIcBAEBCAAGBQJTiRpRAAoJEBzwKT+lPKRYeZUP/RQ4NlB9yxhGaXVdBNoPVKdq
L8DakkbBlHLOVnOgEcyK++s5iOUFXHSeRVJuTIDQs0fAiDnMjC4V+3wynCJbzgz1
174AsN50+LEG4wvJ+rVwS0yBaEzwn7bHKY5zR/J0Rrry4Ms6J4xTuuL8nofr/qkJ
muNFagg+Ypxfbo9qH0Y/XgFMU7IVy4+ti3dtVKXCZJjjOkaRC9DB6A/Win83onAC
FU8zO2bgrTyGtJFsF1IK5VE9V4lafSIy8HgszWUm3zbG1dmrXpii65vdF+gSBALs
kyTN4bekR15O9ubuHXspqZwpJyEBxRLy71048PEHg0gQ4BCluy6nmksxeRTTtVsH
30VRsp2p/JlUHIJWrB/mJ98Co0hN5h2dwzodARarTm8Qm9P/ZDCDzOLj2cHgv6cY
AodGJYuLcNDiwfyv74kVyf0sr/mj54ghZ61ttLYPpqwcZyDTf9dmPiS/SuB9uSWa
oHOcg36v6s0FSIXlvpM+MZ7R1n+m/Dsj2u5dRkt/L/WzNBR7BSQqfs6vPiYoz5H7
IVRhgxYGZLXTmhNx/0yk14zr3EF8Ww84oXlyXNui2kM6jpGgkbleSV/1dkd6F3Ud
/mZxY8a5rqrqrEN/qgFRx0gk2LEtnQhE8p4qHT/2ij0Q1UQXMpPQBL4bdLIe4Zep
FPjzCGsmV9amCd6jvJU2
=6tVn
-END PGP SIGNATURE-

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





This e-mail contains privileged and confidential information intended for the 
use of the addressees named above. If you are not the intended recipient of 
this e-mail, you are hereby notified that you must not disseminate, copy or 
take any action in respect of any information contained in it. If you have 
received this e-mail in error, please notify the sender immediately by e-mail 
and immediately destroy this e-mail and its attachments.

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



RE: Deploying JerseyWS 2.8 w/o web.xml

2014-06-02 Thread Cuneo, Nicholas
I think you are correct, maybe I need to exclude some jars from my bundle?

find . -name *.jar | xargs grep ServletContainerInitializer.class
Binary file ./servlet-api.jar matches

find ../webapps/api/WEB-INF/lib -name *.jar | xargs grep 
ServletContainerInitializer.class
Binary file ../webapps/api/WEB-INF/lib/jersey-container-servlet-jar-2.8.jar 
matches
Binary file ../webapps/api/WEB-INF/lib/javax.servlet-api-jar-3.0.1.jar matches

Thanks,
Nick


-Original Message-
From: Cuneo, Nicholas [mailto:ncu...@tycoint.com]
Sent: Monday, June 02, 2014 9:25 AM
To: Tomcat Users List
Subject: RE: Deploying JerseyWS 2.8 w/o web.xml

We are using Ivy for our dependency manager, but I'm not exactly following what 
you mean.  Are you suggesting  I'm supplying a jar file in my war that  doesn't 
need to be there because Tomcat has its own version of it?

Thanks,
Nick


-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Friday, May 30, 2014 4:55 PM
To: Tomcat Users List
Subject: Re: Deploying JerseyWS 2.8 w/o web.xml

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Nick

On 5/30/14, 5:03 PM, Cuneo, Nicholas wrote:
 We are trying to deploy a webservice to tomcat 8.0.5 using Jersey WS
 2.8.  In the Jersey documentation it mentions deploying without the
 need for a web.xml in your war file using annotations, so I thought
 I’d give that a  try.

 However, when I go to deploy my webservice Tomcat is throwing the
 exception below, I can’t figure out what might be the issue.



 Some notes about our environment in case  they come into play:

 The webservice  is compiled with java 8.

 Tomcat is running on a linux server.

 As per the Jersey documentation, I have a class annotated with
 @ApplicationPath which extends ResourceConfig.  Our webservices exist
 in a separate package which is being loaded using the
 packages() function.



 30-May-2014 20:57:22.592 SEVERE [localhost-startStop-4]
 org.apache.catalina.startup.ContextConfig.processServletContainerIniti
 alizers


Failed to process JAR found at URL [/api] for
 ServletContainerInitializers for context with name [{1}]

 java.io.IOException: java.lang.ClassCastException: Cannot cast
 org.glassfish.jersey.servlet.init.JerseyServletContainerInitializer
 to javax.servlet.ServletContainerInitializer

It looks like you might have a JAR file in WEB-INF/lib that contains 
ServletContextInitializer or something similar. Tomcat should veto the loading 
of such classes, but something may have slipped-by.

Remember that runtime class is classloader + class, so the above error may be 
confusing: JerseyServletContainerInitializer does in fact extend 
ServletContainerInitializer (at least given their current API
javadoc) so the problem is likely that the ClassLoaders do not match.

Perhaps you are using Maven and it's unaware that Tomcat provides some of the 
javax.* packages itself?

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

iQIcBAEBCAAGBQJTiRpRAAoJEBzwKT+lPKRYeZUP/RQ4NlB9yxhGaXVdBNoPVKdq
L8DakkbBlHLOVnOgEcyK++s5iOUFXHSeRVJuTIDQs0fAiDnMjC4V+3wynCJbzgz1
174AsN50+LEG4wvJ+rVwS0yBaEzwn7bHKY5zR/J0Rrry4Ms6J4xTuuL8nofr/qkJ
muNFagg+Ypxfbo9qH0Y/XgFMU7IVy4+ti3dtVKXCZJjjOkaRC9DB6A/Win83onAC
FU8zO2bgrTyGtJFsF1IK5VE9V4lafSIy8HgszWUm3zbG1dmrXpii65vdF+gSBALs
kyTN4bekR15O9ubuHXspqZwpJyEBxRLy71048PEHg0gQ4BCluy6nmksxeRTTtVsH
30VRsp2p/JlUHIJWrB/mJ98Co0hN5h2dwzodARarTm8Qm9P/ZDCDzOLj2cHgv6cY
AodGJYuLcNDiwfyv74kVyf0sr/mj54ghZ61ttLYPpqwcZyDTf9dmPiS/SuB9uSWa
oHOcg36v6s0FSIXlvpM+MZ7R1n+m/Dsj2u5dRkt/L/WzNBR7BSQqfs6vPiYoz5H7
IVRhgxYGZLXTmhNx/0yk14zr3EF8Ww84oXlyXNui2kM6jpGgkbleSV/1dkd6F3Ud
/mZxY8a5rqrqrEN/qgFRx0gk2LEtnQhE8p4qHT/2ij0Q1UQXMpPQBL4bdLIe4Zep
FPjzCGsmV9amCd6jvJU2
=6tVn
-END PGP SIGNATURE-

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





This e-mail contains privileged and confidential information intended for the 
use of the addressees named above. If you are not the intended recipient of 
this e-mail, you are hereby notified that you must not disseminate, copy or 
take any action in respect of any information contained in it. If you have 
received this e-mail in error, please notify the sender immediately by e-mail 
and immediately destroy this e-mail and its attachments.

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




This e-mail contains privileged and confidential information intended for the 
use of the addressees named above. If you are not the intended recipient of 
this e-mail, you are hereby notified that you must not disseminate, copy or 
take any action in 

Re: Tomcat 5.5 vs 7.0 SSL

2014-06-02 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Арсений,

On 6/2/14, 10:24 AM, Арсений Зинченко wrote:
 Hi.
 
 Faced with very odd behavior of Tomcat 7...
 
 Have two instances on same box - Tomcat 5.5 and Tomcat 7.
 
 Both have same configuration - first from 5.5:
 
 Connector port=${port.https} maxHttpHeaderSize=8192 
 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 
 enableLookups=false disableUploadTimeout=true acceptCount=100
 scheme=https secure=true clientAuth=want sslProtocol=TLS 
 keystoreFile=conf/.ssl/tomcat.jks keyAlias=tomcat 
 keystorePass=pass truststoreFile=conf/.ssl/trustcacerts.jks 
 truststorePass=pass /
 
 Next - from 7.0:
 
 Connector port=${port.https} protocol=HTTP/1.1 
 SSLEnabled=true enableLookups=false 
 disableUploadTimeout=true scheme=https secure=true 
 clientAuth=want sslProtocol=TLS 
 keystoreFile=conf/.ssl/tomcat.jks keyAlias=tomcat 
 keystorePass=pass truststoreFile=conf/.ssl/trustcacerts.jks 
 truststorePass=pass /
 
 Also - both configured for CLIENT-CERT authentification (same
 applicaion with same web.xml).
 
 In browser installed  cert, but - when I'm trying open connection
 to 7 Tomcat - I got 401 - Cannot authenticate with the provided
 credentials and no authentification attempt in log:
 
 10.***.***.15 - - [02/Jun/2014:17:10:31 +0300] GET /service/
 HTTP/1.1 401 1049
 
 But connection to 5.5 - succsessfull with same browser 
 certificate.
 
 Also, in ssldump I see that browser can't make handshake with 7.0
 server:
 
 1 2  0.0317 (0.0308)  SC  Handshake ServerHello Version 3.1 
 session_id[32]= 53 8c 85 d7 cf 17 a1 45 8a 4e 64 e6 95 7f 2b f3 cb
 74 0a f3 13 40 71 e8 74 50 53 1a 00 24 a0 76 cipherSuite
 TLS_DHE_DSS_WITH_AES_128_CBC_SHA compressionMethod
 NULL Certificate ServerKeyExchange CertificateRequest 
 certificate_types   rsa_sign certificate_types
 dss_sign certificate_authority 30 62 31 0b 30 09 06 03 55 04 06 13
 02 55 41 31 10 30 0e 06 03 55 04 08 13 07 55 6e 6b 6e 6f 77 6e 31
 0d 30 0b 06 03 55 04 07 13 04 4b 69 65 76 31 0f 30 0d 06 03 55 04
 0a 13 06 4c 75 78 6f 66 74 31 0c 30 0a 06 03 55 04 0b 13 03 4c 4d
 53 31 13 30 11 06 03 55 04 03 13 0a 61 7a 69 6e 63 68 65 6e 6b 6f 
 certificate_authority 30 60 31 0b 30 09 06 03 55 04 06 13 02 55 41
 31 // and that's all
 
 But on 5.5 - everyting OK:
 
 1 2  0.0213 (0.0195)  SC  Handshake ServerHello Version 3.1 
 session_id[32]= 53 8c 85 89 be 1f c5 63 e2 16 a0 a0 dc 5b aa 68 0d
 1c 8d b7 24 c5 13 0a 24 0a 66 9b 54 f4 b0 0f cipherSuite
 TLS_DHE_DSS_WITH_AES_128_CBC_SHA compressionMethod
 NULL Certificate ServerKeyExchange ServerHelloDone 1 3  0.0256
 (0.0042)  CS  Handshake ClientKeyExchange 
 DiffieHellmanClientPublicValue[96]= 4a 39 5e f5 2a c1 58 13 6b 7c
 98 0b 44 d7 9a 42 bf 48 c2 6e a4 c6 6d 50 a7 89 8f 53 a4 54 92 a5 
 81 18 1b 22 63 cf c1 63 8f 36 9f d2 59 c3 3e 67 1f 4e 18 01 db f2
 9d 07 0b 81 12 39 64 62 83 84 78 dc 36 9b 00 34 f5 34 44 2d 92 eb
 d9 f6 b0 7e c4 66 d9 ad f2 bf 7f fb 07 56 eb 58 5d 58 41 2e
 
 What I'm doing wrong?

Anything in the catalina.out or other log files in logs/* ?

Are both Tomcats running on the same server?

In the Tomcat 7 case, does ssldump tell you whether the SC has hung?
Can you tell if the TCP message is incomplete? Can you get a thread
dump on the Tomcat 7 side?

The configuration itself looks okay to me.

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

iQIcBAEBCAAGBQJTjKygAAoJEBzwKT+lPKRYVJEQAKlVEFFwEyfyYFML/aArNHqb
00qGyoyzu7+mLNlZlMvP4wvuXivK13Sxy+NNJ/TqkijZ4ZlaSTx82vUBHt2HNX9J
Rsq5lTL1FRHNDzHABoXwkDLj64xhJ41iBFUcdsGENJ9K9mpFtPXi3wSRsQK4eguv
ynRr+f3pJwWsiPlXxWiGICV55mKGsUvSwjKzXhG6RYMpUmHeT1V7SOyOfPA73Jks
GGPaDsc0tNT9K6c8NGX+c5+u0h5Af5UQn10Rcpp/22QSzfIDwq4kv1MPZ9I+TTQa
l/S/L6VfVtbacUuvVMsnN15eIEQDfTVA9RoKjacG0rsrB+oqoSG0UDjFhuP8LXHx
huvhim7CJcZyaNR3Ydp8Q+NFz5ON4w6tlP/APA48x6HUgAJq3DoSlFbrbJGu4HVV
NgziXOdlwz7KD7yVdUckrbCsLVCFrxkBENtOUdQ5a6dp1bjPBfOcxrtPcEduvLUR
mdNsoXQA8pOFBLHwIJSONBn7lSXQPBR+XCkxGJDqYzdmaykoz2OrB7aA4DqtYXCD
iwA0bvwFCOOzq/DiNlLgqscQz9+sAbT7ROjCvkKpDfjJYBi7S26eNx9Gg1S39scX
uAlDoRe96CQDmcitZ8Oqrn5ErKReTpbhGULn0YnHB1uL9Vxd5M8EkAI0whTQMQ5u
qYcRj4u7cd24Okq8KQUd
=zoKs
-END PGP SIGNATURE-

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



Re: Deploying JerseyWS 2.8 w/o web.xml

2014-06-02 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Nicholas,

On 6/2/14, 12:38 PM, Cuneo, Nicholas wrote:
 I think you are correct, maybe I need to exclude some jars from my
 bundle?
 
 find . -name *.jar | xargs grep
 ServletContainerInitializer.class Binary file ./servlet-api.jar
 matches
 
 find ../webapps/api/WEB-INF/lib -name *.jar | xargs grep
 ServletContainerInitializer.class Binary file
 ../webapps/api/WEB-INF/lib/jersey-container-servlet-jar-2.8.jar
 matches Binary file
 ../webapps/api/WEB-INF/lib/javax.servlet-api-jar-3.0.1.jar matches

Yes, those are going to be a problem. and need to be removed from
WEB-INF/lib

You should also remove anything that provides JSP or EL APIs.

Like I said, Tomcat should be protecting itself against such classes
being loaded... are there any warnings during deployment that JAR
files are being rejected?

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

iQIcBAEBCAAGBQJTjK0XAAoJEBzwKT+lPKRYnNoQALTKiIDycnKxYmAWt7QdQy2c
evQYKt1xEQwDUq1qrng7KDWaF5qgy6udm682z0RLgfNVQOmklXEkR8TTnPyuhaDY
QNrTg0ojQytXcVdBiyqiectVTkj9Bqf3nATGqUN20CI2zUuEvK1Bt+dvGzBTRNji
ckJSgNZyA6dbODr84jLZG4s5eVwrS+Ee68EtDuJSxKPtjWiBwMtzJ+1inYL9xHY+
jUXC71UCroj7typlNVeSTL6pUlPrs1xq2FJGNQn6Q5IecevLHK08EZlKkcqVdc5A
BH8/VlSnFgYBIDXCWY+UydFT+M3GmwLX5h120oTczY9doPAHF0W4s6anrzt6hPc7
mMOjHhBbgyMi2EigS/kGCpK4opiLTkGouba8JQQPmc6IhMRZyaEW3WyDDfaFlRGQ
w3cN/mQ0QKY0sirOPa4O2wqeH6rW/tG6i20MCKDOkT9X7KXEvLkvfTZDuQyi7FOI
Ew81AztOODBci6MByrgt7MVPmhLd0I+jaqAERLk3bLAKbd5CFDe5yHo5l3f+JMGB
dS+cQUFLu51GteTLLnhoiyZpER6OXKliZxytlbqbMfyj+iuMvkbnLy+X8XAaiEWk
+BGskIIqLi70c4MOLbZwlVQxQp+DLuQhwWmIQ3Fa+Gf6gF1IhUhY/5AUxKz4hK3P
GdRQ++l8m626y7pfS3Cy
=LKd/
-END PGP SIGNATURE-

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



RE: Deploying JerseyWS 2.8 w/o web.xml

2014-06-02 Thread Cuneo, Nicholas
The only error I saw in my catalina logs was the one I copied earlier.
Indeed, removing javax.servlet-api fixed the issue.

Thanks,
Nick


-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Monday, June 02, 2014 9:58 AM
To: Tomcat Users List
Subject: Re: Deploying JerseyWS 2.8 w/o web.xml

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Nicholas,

On 6/2/14, 12:38 PM, Cuneo, Nicholas wrote:
 I think you are correct, maybe I need to exclude some jars from my
 bundle?

 find . -name *.jar | xargs grep
 ServletContainerInitializer.class Binary file ./servlet-api.jar
 matches

 find ../webapps/api/WEB-INF/lib -name *.jar | xargs grep
 ServletContainerInitializer.class Binary file
 ../webapps/api/WEB-INF/lib/jersey-container-servlet-jar-2.8.jar
 matches Binary file
 ../webapps/api/WEB-INF/lib/javax.servlet-api-jar-3.0.1.jar matches

Yes, those are going to be a problem. and need to be removed from WEB-INF/lib

You should also remove anything that provides JSP or EL APIs.

Like I said, Tomcat should be protecting itself against such classes being 
loaded... are there any warnings during deployment that JAR files are being 
rejected?

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

iQIcBAEBCAAGBQJTjK0XAAoJEBzwKT+lPKRYnNoQALTKiIDycnKxYmAWt7QdQy2c
evQYKt1xEQwDUq1qrng7KDWaF5qgy6udm682z0RLgfNVQOmklXEkR8TTnPyuhaDY
QNrTg0ojQytXcVdBiyqiectVTkj9Bqf3nATGqUN20CI2zUuEvK1Bt+dvGzBTRNji
ckJSgNZyA6dbODr84jLZG4s5eVwrS+Ee68EtDuJSxKPtjWiBwMtzJ+1inYL9xHY+
jUXC71UCroj7typlNVeSTL6pUlPrs1xq2FJGNQn6Q5IecevLHK08EZlKkcqVdc5A
BH8/VlSnFgYBIDXCWY+UydFT+M3GmwLX5h120oTczY9doPAHF0W4s6anrzt6hPc7
mMOjHhBbgyMi2EigS/kGCpK4opiLTkGouba8JQQPmc6IhMRZyaEW3WyDDfaFlRGQ
w3cN/mQ0QKY0sirOPa4O2wqeH6rW/tG6i20MCKDOkT9X7KXEvLkvfTZDuQyi7FOI
Ew81AztOODBci6MByrgt7MVPmhLd0I+jaqAERLk3bLAKbd5CFDe5yHo5l3f+JMGB
dS+cQUFLu51GteTLLnhoiyZpER6OXKliZxytlbqbMfyj+iuMvkbnLy+X8XAaiEWk
+BGskIIqLi70c4MOLbZwlVQxQp+DLuQhwWmIQ3Fa+Gf6gF1IhUhY/5AUxKz4hK3P
GdRQ++l8m626y7pfS3Cy
=LKd/
-END PGP SIGNATURE-

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





This e-mail contains privileged and confidential information intended for the 
use of the addressees named above. If you are not the intended recipient of 
this e-mail, you are hereby notified that you must not disseminate, copy or 
take any action in respect of any information contained in it. If you have 
received this e-mail in error, please notify the sender immediately by e-mail 
and immediately destroy this e-mail and its attachments.


Re: Tomcat 5.5 vs 7.0 SSL

2014-06-02 Thread Arseny

02.06.2014 19:56, Christopher Schultz пишет:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Арсений,

On 6/2/14, 10:24 AM, Арсений Зинченко wrote:

Hi.

Faced with very odd behavior of Tomcat 7...

Have two instances on same box - Tomcat 5.5 and Tomcat 7.

Both have same configuration - first from 5.5:

Connector port=${port.https} maxHttpHeaderSize=8192
maxThreads=150 minSpareThreads=25 maxSpareThreads=75
enableLookups=false disableUploadTimeout=true acceptCount=100
scheme=https secure=true clientAuth=want sslProtocol=TLS
keystoreFile=conf/.ssl/tomcat.jks keyAlias=tomcat
keystorePass=pass truststoreFile=conf/.ssl/trustcacerts.jks
truststorePass=pass /

Next - from 7.0:

Connector port=${port.https} protocol=HTTP/1.1
SSLEnabled=true enableLookups=false
disableUploadTimeout=true scheme=https secure=true
clientAuth=want sslProtocol=TLS
keystoreFile=conf/.ssl/tomcat.jks keyAlias=tomcat
keystorePass=pass truststoreFile=conf/.ssl/trustcacerts.jks
truststorePass=pass /

Also - both configured for CLIENT-CERT authentification (same
applicaion with same web.xml).

In browser installed  cert, but - when I'm trying open connection
to 7 Tomcat - I got 401 - Cannot authenticate with the provided
credentials and no authentification attempt in log:

10.***.***.15 - - [02/Jun/2014:17:10:31 +0300] GET /service/
HTTP/1.1 401 1049

But connection to 5.5 - succsessfull with same browser 
certificate.

Also, in ssldump I see that browser can't make handshake with 7.0
server:

1 2  0.0317 (0.0308)  SC  Handshake ServerHello Version 3.1
session_id[32]= 53 8c 85 d7 cf 17 a1 45 8a 4e 64 e6 95 7f 2b f3 cb
74 0a f3 13 40 71 e8 74 50 53 1a 00 24 a0 76 cipherSuite
TLS_DHE_DSS_WITH_AES_128_CBC_SHA compressionMethod
NULL Certificate ServerKeyExchange CertificateRequest
certificate_types   rsa_sign certificate_types
dss_sign certificate_authority 30 62 31 0b 30 09 06 03 55 04 06 13
02 55 41 31 10 30 0e 06 03 55 04 08 13 07 55 6e 6b 6e 6f 77 6e 31
0d 30 0b 06 03 55 04 07 13 04 4b 69 65 76 31 0f 30 0d 06 03 55 04
0a 13 06 4c 75 78 6f 66 74 31 0c 30 0a 06 03 55 04 0b 13 03 4c 4d
53 31 13 30 11 06 03 55 04 03 13 0a 61 7a 69 6e 63 68 65 6e 6b 6f
certificate_authority 30 60 31 0b 30 09 06 03 55 04 06 13 02 55 41
31 // and that's all

But on 5.5 - everyting OK:

1 2  0.0213 (0.0195)  SC  Handshake ServerHello Version 3.1
session_id[32]= 53 8c 85 89 be 1f c5 63 e2 16 a0 a0 dc 5b aa 68 0d
1c 8d b7 24 c5 13 0a 24 0a 66 9b 54 f4 b0 0f cipherSuite
TLS_DHE_DSS_WITH_AES_128_CBC_SHA compressionMethod
NULL Certificate ServerKeyExchange ServerHelloDone 1 3  0.0256
(0.0042)  CS  Handshake ClientKeyExchange
DiffieHellmanClientPublicValue[96]= 4a 39 5e f5 2a c1 58 13 6b 7c
98 0b 44 d7 9a 42 bf 48 c2 6e a4 c6 6d 50 a7 89 8f 53 a4 54 92 a5
81 18 1b 22 63 cf c1 63 8f 36 9f d2 59 c3 3e 67 1f 4e 18 01 db f2
9d 07 0b 81 12 39 64 62 83 84 78 dc 36 9b 00 34 f5 34 44 2d 92 eb
d9 f6 b0 7e c4 66 d9 ad f2 bf 7f fb 07 56 eb 58 5d 58 41 2e

What I'm doing wrong?

Anything in the catalina.out or other log files in logs/* ?

Are both Tomcats running on the same server?

In the Tomcat 7 case, does ssldump tell you whether the SC has hung?
Can you tell if the TCP message is incomplete? Can you get a thread
dump on the Tomcat 7 side?

The configuration itself looks okay to me.

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

iQIcBAEBCAAGBQJTjKygAAoJEBzwKT+lPKRYVJEQAKlVEFFwEyfyYFML/aArNHqb
00qGyoyzu7+mLNlZlMvP4wvuXivK13Sxy+NNJ/TqkijZ4ZlaSTx82vUBHt2HNX9J
Rsq5lTL1FRHNDzHABoXwkDLj64xhJ41iBFUcdsGENJ9K9mpFtPXi3wSRsQK4eguv
ynRr+f3pJwWsiPlXxWiGICV55mKGsUvSwjKzXhG6RYMpUmHeT1V7SOyOfPA73Jks
GGPaDsc0tNT9K6c8NGX+c5+u0h5Af5UQn10Rcpp/22QSzfIDwq4kv1MPZ9I+TTQa
l/S/L6VfVtbacUuvVMsnN15eIEQDfTVA9RoKjacG0rsrB+oqoSG0UDjFhuP8LXHx
huvhim7CJcZyaNR3Ydp8Q+NFz5ON4w6tlP/APA48x6HUgAJq3DoSlFbrbJGu4HVV
NgziXOdlwz7KD7yVdUckrbCsLVCFrxkBENtOUdQ5a6dp1bjPBfOcxrtPcEduvLUR
mdNsoXQA8pOFBLHwIJSONBn7lSXQPBR+XCkxGJDqYzdmaykoz2OrB7aA4DqtYXCD
iwA0bvwFCOOzq/DiNlLgqscQz9+sAbT7ROjCvkKpDfjJYBi7S26eNx9Gg1S39scX
uAlDoRe96CQDmcitZ8Oqrn5ErKReTpbhGULn0YnHB1uL9Vxd5M8EkAI0whTQMQ5u
qYcRj4u7cd24Okq8KQUd
=zoKs
-END PGP SIGNATURE-

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



Hi, Chris.

Thanks for replay and sorry spending your time - there was my error in 
server.xml - include ojdbc Realm in wrong place (our from Host element).


I think so... Because I made a lot of experiments today trying fix it...

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



Clearing ResourceBundle cache

2014-06-02 Thread Jan Tosovsky
Dear All,

in my Java webapp I switched to UTF-8 encoded properties files. 

I've implemented a custom ResourceBundle 
http://stackoverflow.com/questions/3645491/i18n-with-utf-8-encoded-propertie
s-files-in-jsf-2-0-appliaction

but my strings are still displayed incorrectly. The original ASCII ones seem
to be somehow cached. It is discussed in this thread
http://stackoverflow.com/questions/981/how-to-clear-resourcebundle-cache

but I haven't succeed yet. I run this app on Win7/JDK8/tomcat 8.0.3/Netbeans
IDE 8

I do not need to clear this cache programatically. Is there any manual way
to force tomcat/mojarra to use newer resource version? 

Thanks, Jan


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



Re: Clearing ResourceBundle cache

2014-06-02 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jan,

On 6/2/14, 4:35 PM, Jan Tosovsky wrote:
 Dear All,
 
 in my Java webapp I switched to UTF-8 encoded properties files.
 
 I've implemented a custom ResourceBundle 
 http://stackoverflow.com/questions/3645491/i18n-with-utf-8-encoded-propertie

 
s-files-in-jsf-2-0-appliaction
 
 but my strings are still displayed incorrectly. The original ASCII
 ones seem to be somehow cached.

Did you shut down and restart your JVM? If you did, then caching is
not your problem. Did you copy the code into your deployment?

I'm curious why you bothered to write your own ResourceBundle instead
of just using native2ascii.

 It is discussed in this thread 
 http://stackoverflow.com/questions/981/how-to-clear-resourcebundle-cache

  but I haven't succeed yet. I run this app on Win7/JDK8/tomcat
 8.0.3/Netbeans IDE 8
 
 I do not need to clear this cache programatically. Is there any
 manual way to force tomcat/mojarra to use newer resource version?

Redeploy/reload the web application?

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

iQIcBAEBCAAGBQJTjO5GAAoJEBzwKT+lPKRYn7wP+QGE0+syroX01WzEfRxNfFO3
hz7o4w+MfTYF1KyiaLXrs1++uqEkkEkz/w9ILWnAclGrq2dT/PNaWpw0tWlJk6YX
tsaZJIbhmcF6hTq4pfN78C9xjYtmurSrhDVIwNwI8vZWFc+gSWQdH2thAQgVVb58
onBcqh50nGVhnaxtnFhLtuC1ADCH22RD+lP5ea6CxXoxoS+UeFSh6sNk2BXjcQPk
X3nYNZBbxm8TpEp2io4lMLpqdUGtz+tZPlD3JYGbdVdZSRoY+eBmbtapBzZET5b0
kGUxUhaoH7PQUlr08XCPlTYVbN2pHYS6+fm2FiQNqzSH0rW1vvY3FLsz5jhhcnYA
fonA5AMwGP+XCzszXUQvxu1lEBRYu5w51NhEYeBO2prrE873XFYZ3ikuY005+7H4
qzzBZczmodo/QMkMRCNvxiuAB/vJkneGW8xPjP9k+kSeXHfttNJn4GHcyRt9xIR9
iQ6/DdoZdlEha/6LTlVNAY7x/3iXOEb5Vg+ANouw94GlDyEHJk7LnDQyNccFNs3u
tHue/+cwW3rZjLTqle+v1VGRvLc9agMa92Wjt2edMFg82oMTnunQWN806i4il00Q
BWp6iLCmmcVcfLLgq/IB0zFQKBLuSO6bHHBD7tDB37HIEaSyNNTx8djsHJVoc4XE
u8RLiHc3xOvI7ck5+SA1
=vYeK
-END PGP SIGNATURE-

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