Re: Issue while using SSL with Embedded Tomcat 6.0.37
Hi Chris, Thanks for the code,it helped a lot. Now,using that code on my server machine I found out that TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA is not even in the defaults ciphers for jdk1.6.0_39. Isn't this a strange behaviour? Server can only select available ciphers,I suppose. Thanks Chirag On Tuesday, 8 October 2013 9:10 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chirag, On 10/8/13 6:01 AM, Chirag Dewan wrote: I am using Embedded Tomcat 6.0.37. I have a servlet which is running over HTTPS using SSL Connector. I have a Java Keystore with Customer Certificate imported in it. Now,there is a HTTP Client on the customers end which connects with the servlet over HTTPS(I have very little information about the customers client configuration) The problem we are facing is: For the first request from Client,the SSL handshaking fails. How, specifically? What do you observe on the server? What do you observe on the client? From second request, handshaking is completed successfully and the requests are processed. I have observed when Server selects TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA as the cipher suite, only then the Server sends a reset to the client and the handshaking fails. On second request, with same cipher suite,it works fine. So the first request and second request seem to both negotiate the same cipher suite (TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA) but the first one fails? Can anyone assist me in understanding why it is failing for the first time? And is there any way I can force the Tomcat not to select this cipher suite? Or any other way that I can resolve this issue. See the Connector documentation, specifically the cipherSuites attribute. Unfortunately, Tomcat's cipherSuites configuration is only explicit... you can't say something like defaults without TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA. See this thread in the archives for a short program that will dump-out the available cipher suites and indicates which ones are available by default in your environment (note that the results will change for every different version of Java you use): http://markmail.org/message/zn4namfhypyxum23 - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSVCdnAAoJEBzwKT+lPKRYM9cP/3GztDeXBYguwJ/Q+YBnNSea NzEQuJXFmaSJhhhCP4NMrHz0Fq4zZlKu9khxicK4gwcfGuCZ0i2BkNx1jZh9wgOF aedSeZinpXtF5L+EiWUCm9Xz2yPHuX40+VIaW9X4/TfG+DMcDVvFFAH1onjHQ5im KECrmK5ratXmVfm9o37SrXItoqNFLqk70mxcZlVec40fp7nu3Bn2ReMIKcSCSXcb Sr97cHlRD8yMBqTn42RNTSzfFfJ/5TFNzmwXzlrSJcWO+6mpKYmXXdbJc3voNd3W e+ZWmJQheJEVm6n86z2PMqwJyBtaiNFRxOxbeXHtU1BwemhSAP1EVPtZSUKQ5k+4 vHbZ4CfhuSgM6IaoTZjqqZkvch4POTLUWPArFJeEyOS8p9vayNoVhFectMtutR4O zHxanjckpCgJYp5w82jRaZ4Xs9SojTedHn6gSElxZK94fg9H4dL6g43h+zSpnuJC 0KF4U47FMklZJBikjDXbkcH3YY8Bd+e+5JMl2Uu+TyjG12Cj6wxyOKM4ubAF7pMO IZbs9WEgHx2Oj515RgFNQGF8uXLysLo4uBiCbTEvFQ3T/eGrSzvYi6kLKi/izPuc TbSYcS1UEAiRKABPMRbUKDqmD6IOTOjbR66lamwTzNFvsyH+BhoaB1RVHy9TUC2U YicDQSfyb9kfCnANiGwR =pYDx -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HOWTO Same web application serving UI / SOAP ?
N.s.Karthik wrote: Hi Do any body have any Brain storming Ideas for the Following With single Web Application Installation Use a Web application for Web based - Browser Interface. Use the same Web application for exposing the SOAP based - Client Interface URL should be same and no changes either of Browser / Soap . * Web : http://:8080/App/jsp/abcd.jsp Soap : http://8080/App/services/abcd.wsdl * How to achieve the same Your question is a bit confusing. You are asking for the same URL being used in both cases, but you list 2 different ones above. First, a webapp can consist of a collection of different servlets. So a HTTP request to http://myhost.com:8080/App/type1; and a request to http://myhost.com:8080/App/type2; could both be mapped to the webapp App, but each to a different servlet (type1 or type2) within that webapp. That is just a matter of mapping the calls properly in the WEB-INF/web.xml of the webapp App. Second, if you want a single URL like http://myhost.com:8080/App/xyz; to map to 2 different servlets, depending on whether this request comes from a certain type of client (browser or SOAP client), then I suppose that some of the HTTP request headers will be different in one case compared to the other. In that case, you could add a servlet filter to your webapp App, mapped to the URL /xyz, which would look at the HTTP request headers and depending on whether this looks like a SOAP call or not, internally re-direct the request to the appropriate servlet type1 or type2. Have a look at the URLRewriteFilter for that. http://tuckey.org/urlrewrite/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Bad Gateway
On 09/10/2013 04:43, Salisbury, Richard W DLA CTR TRANSACTION SERVICES snip/ We confirmed that Tomcat on server-B is configured to handle port 53309, from this excerpt from its server.xml: Connector description=Content Switch HTTPS maxHttpHeaderSize=8192 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false disableUploadTimeout=true acceptCount=100 scheme=https secure=true keystoreFile=/keystore/server-ks.p12 keystoreType=PKCS12 keystorePass=pass truststoreFile=/keystore/ts.jks truststoreType=JKS truststorePass=pass clientAuth=false algorithm=SunX509 sslProtocol=TLS port=53309 / We confirmed Tomcat was started successfully on server-B and listening on port 53309, from the application log: 2013-08-22 18:01:49,321 INFO : Succesfully started Apache Tomcat/6.0.35 @ Catalina:53309 Any ideas on what might be going on? You appear to be missing SSLEnabled=true on your Tomcat connector. The start-up log messages for that connector will confirm whether that analysis is correct. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Deploy web app with context version by tomcat-maven-plugin
On Oct 8, 2013, at 9:37 PM, Phuoc Nguyen nhph...@mytrax.co.jp wrote:
Dear tomcat experts,
I am using Tomcat 7. In the manager html interface, there is a column named
version in the list of applications table. I read the document here
http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Naming to find
the way to set version for my web application. I deploy my web application
by tomcat-maven-plugin
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdtomcat-maven-plugin/artifactId
version1.1/version
configuration
warFile${project.build.directory}/${project.build.finalName}.war/warFile
urlhttp://myhostname.com:8080/manager/text/url
path//path
tag##${project.version}/tag
usernametomcat/username
passwordxxx/password
/configuration
/plugin
Please help me how can I set the version for my web app.
If I manually deploy I just rename the war to ROOT#version.war.
Are you using ROOT#version.war? Cause it should be ROOT##version.war.
Using one # means something different.
Dan
Thanks best regards
Phuoc Nguyen
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: In Tomcat JULI, do the 'facility specific' loggers become per-webapp logger roots?
On Oct 8, 2013, at 11:03 PM, David Bullock david.bull...@machaira.com.au
wrote:
Please answer at Stackoverflow, and I'll report the results back to this
list:
http://stackoverflow.com/questions/19261727/in-tomcat-juli-do-the-facility-specific-loggers-become-per-webapp-logger-root
If you want to control your application's logging with the
org.apache.catalina.core.ContainerBase.[${engine}].[${host}].[${context}]
options in conf/logging.properties then the application needs to use the
Servlet logging api. See here for more details.
http://tomcat.apache.org/tomcat-7.0-doc/logging.html#Servlets_logging_API
In general, I don't think most web application's will want to use this
mechanism for logging though. Rather they'd use something more modern like
Log4j or Logback (possibly through SLF4J) which each have their own separate
and more flexible way of being configured.
This intent behind this question is very similar to that asked in 2011:
How to externalize a webapp's logging.properties?, but it was never
adequately answered:
http://marc.info/?l=tomcat-userm=131831958930163w=2
In general, I'm really grumpy when I have to unpack a WAR and fiddle with
some files **each time** I deploy it. If there is some more-general
mechanism for allowing a deployer (remember those things called 'roles'
from the EJB 1.0 spec, anyone?) to override configuration settings which
have unfortunately been embedded in the WAR file, I'd **love** to know
about it. I haven't spotted anything about this in the Tomcat doco so far.
In general, I would suggest the VirtualWebappLoader. With that you can add an
external directory like /opt/app-1-config/ to the class path for a particular
web application. *If* the application is loading it's configuration from the
class path it will be able to load configuration files from this location.
http://tomcat.apache.org/tomcat-7.0-doc/config/loader.html#VirtualWebappLoader_Implementation
I don't think this will work for logging.properties, but that's a special case.
It would work for other logging configurations like log4j.properties or
logback.xml.
Dan
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Deploy web app with context version by tomcat-maven-plugin
Hi Dan Are you using ROOT#version.war? Cause it should be ROOT##version.war. Using one # means something different. I am using ROOT##version.war. I have a typo mistake in the previous email. My problem is using tomcat-maven-plugin. I don't know how to achieve this with tomcat-maven-plugin. Thanks you for your reply. Phuoc Nguyen - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HOWTO Same web application serving UI / SOAP ?
My Friend Let me Explain... I have an an web based application hosted on a tomcat server (port :8080) hence to access the application , i have to use the URL as follows *http://IP:port/APP/index.jsp* Now if some reason , I have to expose some underlying methods part's of the same web Application as SOAP requirement (Applying Axis2 config on same web application) ,I have to use the URL as follows *http://IP:port/APP/services/abcd?wsdl* What OTHER config changes / challenges should i have to do in Tomcat for multi usage ( browser / SOAP ) for the same ? regards Karthik -- View this message in context: http://tomcat.10.x6.nabble.com/HOWTO-Same-web-application-serving-UI-SOAP-tp5005925p5005937.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Issue while using SSL with Embedded Tomcat 6.0.37
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chirag, On 10/8/13 9:48 PM, Chirag Dewan wrote: For this particular cipher, the server sends a RST to the client after the certificate exchange is done. And the handshaking fails,for the first time only. Second request onwards handshaking happens and the traffic flows as usual. When you say first and second request... are you talking about the first and second request that the server receives since it's been started, or are you talking about the first and second requests that the client makes without restarting? What action resets the experiment? I'm wondering if the server gets fixed or the client. What I understand is,I can provide a set of ciphers to the connector and the client will select from that particular set and can thus avoid the particular cipher. Can I do this in embedded tomcat? And what set of ciphers should I allow with that connector? I'm not sure why the embedded case would be any different from the non-embedded case... you are setting-up your connectors in a standard way, right? Maybe if you posted some code... - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSVUfzAAoJEBzwKT+lPKRY/isP/RCAEn9zkHU2pl2zowwP5s0R lqsa3QcXuOWpBN3UUa/+HYCJ2CorldBplISSd2lSeReAAJu0XdvnKW8ObizmXFyD +Rx8PjgJlLjImJZGmTObJGSBbuk9NqnsG0AkoZ3/ERTE8mLJtsS3cxMMWCMCKtL1 VIhgQDfDy2e2NSBKQHtTGPUaqvpV5MVeeox6/M73n+t2ZoD8rtpi8OQPJjGkmtmE oGqnLM5KSuWso7ajhHlWoR5zQmVMqcWtig1iGa4OBXXKhvcu/+XCuv+KZSnSVBui TTiBemIz4/pzWaABQElyvb807g6WZstPvpkRzORWRai+Mzc/oGtP2Wcu1LLyRikb Jctt0W5xpjEKYKlQCYWUZK6NOvBjS9kxiCaBJO8R+B3OT9/zL/eXdWZ9m6gZrXT2 FPMv2nxUcOnKZw+NZu7htn5Reabd5rn5tCFdjYFsosPJIJWRKpLldRmftA9CosQd FYS7BTq5Yfrhx4SQbvaH5avcJc8QRtRJ8//CBMTyDl2Aj5JYyBkPMINOWgCDEUxN D3dKk/FPi1sRiVtokXzvOKItYR0FjVF8vmsjH1hDECRqynTr9JzDjpwA4qDvPI/G DPB0UMAyWglihOB+LdIAf96iSbW4Jbi1ltroWtm3FgGQRGgl4nmf2e4sruGXVwky 06oIRLcYemFogN3Pqnl7 =JXdI -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Issue while using SSL with Embedded Tomcat 6.0.37
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chirag, On 10/8/13 9:48 PM, Chirag Dewan wrote: For this particular cipher, the server sends a RST to the client after the certificate exchange is done. And the handshaking fails,for the first time only. Second request onwards handshaking happens and the traffic flows as usual. What I understand is,I can provide a set of ciphers to the connector and the client will select from that particular set and can thus avoid the particular cipher. Technically speaking, the server selects the cipher given the list sent by the client and any restrictions the server has (e.g. using the ciphers list from your connector). It's very strange that the server would be selecting that (evidently missing) cipher in the first place (then failing) and then choosing it /again/ and succeeding. I must be missing something. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSVUi4AAoJEBzwKT+lPKRYvn4P/AlheFMNQ/6b+tydwX6/YzlQ gbI20pnDMZV2+03lQB/3ACLNmWWkS4NbjW/6FeYfaN8yEZFMP0EwvnTkVye9VMaG RlGpgNjOsANruNrtmDT/frAIGjLQxQM+f+4Bjc+TGBSNAnjeoDnintDhEAcXHtpp NaL2H2IJMtXJrGBhfZ3z0xu1gYLY6+SCuSeilahl6uvMS1PU0s5KT0Nm3D8xIkeC L48yU+y0kVV9Ok2gojNPxCxKt6EJP+/WrR37q+H7LFCsfESKG8yYK72tBU0ex6Z2 mUinqnYcbLXTGrtWzuFJUGMUyJWpLeuZJii5McBtwqudOnbFWo8hbXPKj2IfEMMT FuSBJgLyVXAoZ51SrRYCOjYMy3tH2kB4FgHc43GWlxwznrHVgTeOUe5OQRiFpfa5 BDKCtEQF/xHUp9zE2BKpvieR1lCxUc+8zgJvThvFElGkvdenK0kgE1RgsgEf9cTv cgyr+PM6T8Yp99ngj69kfqvTt8tNfg8UUZVzHmUPj4zMEII9uKRElk26g31yiRf7 2FXguR1ANn2cbn6mDQvrE48LjfQ6Zupr6XWUXSBffenI3yyJdeueRc0BvrY4LUYH Yn2OVjd0NnITmqfDje03cDxtosGJTESUc+LtBK4eJUYftkSgGMxZmKE0tM+QucVM k0EQUBpo4cU/QqFZ6lyU =3uiN -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: In Tomcat JULI, do the 'facility specific' loggers become per-webapp logger roots?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 David, On 10/8/13 11:03 PM, David Bullock wrote: Please answer at Stackoverflow, and I'll report the results back to this list: http://stackoverflow.com/questions/19261727/in-tomcat-juli-do-the-facility-specific-loggers-become-per-webapp-logger-root Um, no. If you want to ask this community, then ask here. If you prefer the SO community, ask there. Feel free to ask both. But don't come here and tell us to go somewhere else to help you. This intent behind this question is very similar to that asked in 2011: How to externalize a webapp's logging.properties?, but it was never adequately answered: http://marc.info/?l=tomcat-userm=131831958930163w=2 The answer was no, you can't do that. When you say adequately do you mean to your satisfaction (i.e. you wanted the answer to be yes) or that it wasn't actually answered. Becaue Konstantin Kolinko did answer in no uncertain terms. He also gave some suggestions for where to look to maybe hack your way to a working solution. Dan used one of those suggestions to effect a working solution. In general, I'm really grumpy when I have to unpack a WAR and fiddle with some files **each time** I deploy it. If there is some more-general mechanism for allowing a deployer (remember those things called 'roles' from the EJB 1.0 spec, anyone?) to override configuration settings which have unfortunately been embedded in the WAR file, I'd **love** to know about it. I haven't spotted anything about this in the Tomcat doco so far. Virtual. Class. Loader. Or Resources, depending upon your Tomcat version. Or, fix your packaging and/or deployment so that it builds the correct WAR file for your environment. I know this isn't always possible, especially for mass-distributed webapps where the developer doesn't control the target environment. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSVU0GAAoJEBzwKT+lPKRYUTYP/1BcmrEtNl8qayVXyay85hAu aYQsfzd0lxmtf1m0MSnh2llmVQUCsQUjC2PozDqmxl44wFBXUJaUaKVMRZybaLJ6 Nn/elxzqfma3YzPHWiRcwKkHDKkwqRUPCujrlyqf2ZU+ap2U/ct8SQE/ehDVStLo XKiJ8pQYyerHK/ZzbXXgjO1uDj7AEGOlqfzbIPrKm3eUARFkNAOkPpkObkA7bThc GxyixZ3SL6Vfjk0EZKipmjxarBisVo4NGhbav18u1FfCCktM4F/J5Kr78VVfy63c MfsSDjY+FgYLbcoklqHV1uVqW5R5rTkK1ZA5LIg3xjJ6ZePFf1YbkIbFKuTFZ9Pa stu+qY2XtVTvWhNS6h0rC0+YJhRrrEpsE2h4zq715uS1w4yxvn+x4fTxmR+J7WJP eX/7Bw8Mb9sVJMia3+82yd4mhdcbr5fMwj635SqY1XUXn96tFc4gZAewpnG3rNsq JWq29YacNbHx8d9V2XDCaJi2Eyxs99Rj2sPJcEZj3lQZ7noqj/rs30MjAwEBnLzB oN2hpp4qmeRxBq0gkddsrJLOHvJUWs2tmmcmnc96EpH0+WgVkR3FthoucHF2Qthc G0SfgsBURWbhoyLP9jjq+Aw8vzinyel0gOkBCCkoDmcFuvuSZWJ1szaKMstPmRMX uPhekGt5l15IEZqGYArs =l2Cb -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Issue while using SSL with Embedded Tomcat 6.0.37
Hi, The first request after the Server is started gets rejected. I am setting my connector as follows: IntrospectionUtils.setProperty( this, sslProtocol, TLS ); IntrospectionUtils.setProperty( this, keystore, keyStoreFile ); IntrospectionUtils.setProperty( this, keypass, keyStorePassword ); IntrospectionUtils.setProperty( this, SSLEnabled, true ); IntrospectionUtils.setProperty( this, ciphers, cipherSet ); This is my connector configuration. I am now setting cipher,as you can see. And it is selecting the specified cipher,so that way I can limit the cipher sets to be selected by Server. On Wednesday, 9 October 2013 5:45 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chirag, On 10/8/13 9:48 PM, Chirag Dewan wrote: For this particular cipher, the server sends a RST to the client after the certificate exchange is done. And the handshaking fails,for the first time only. Second request onwards handshaking happens and the traffic flows as usual. What I understand is,I can provide a set of ciphers to the connector and the client will select from that particular set and can thus avoid the particular cipher. Technically speaking, the server selects the cipher given the list sent by the client and any restrictions the server has (e.g. using the ciphers list from your connector). It's very strange that the server would be selecting that (evidently missing) cipher in the first place (then failing) and then choosing it /again/ and succeeding. I must be missing something. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSVUi4AAoJEBzwKT+lPKRYvn4P/AlheFMNQ/6b+tydwX6/YzlQ gbI20pnDMZV2+03lQB/3ACLNmWWkS4NbjW/6FeYfaN8yEZFMP0EwvnTkVye9VMaG RlGpgNjOsANruNrtmDT/frAIGjLQxQM+f+4Bjc+TGBSNAnjeoDnintDhEAcXHtpp NaL2H2IJMtXJrGBhfZ3z0xu1gYLY6+SCuSeilahl6uvMS1PU0s5KT0Nm3D8xIkeC L48yU+y0kVV9Ok2gojNPxCxKt6EJP+/WrR37q+H7LFCsfESKG8yYK72tBU0ex6Z2 mUinqnYcbLXTGrtWzuFJUGMUyJWpLeuZJii5McBtwqudOnbFWo8hbXPKj2IfEMMT FuSBJgLyVXAoZ51SrRYCOjYMy3tH2kB4FgHc43GWlxwznrHVgTeOUe5OQRiFpfa5 BDKCtEQF/xHUp9zE2BKpvieR1lCxUc+8zgJvThvFElGkvdenK0kgE1RgsgEf9cTv cgyr+PM6T8Yp99ngj69kfqvTt8tNfg8UUZVzHmUPj4zMEII9uKRElk26g31yiRf7 2FXguR1ANn2cbn6mDQvrE48LjfQ6Zupr6XWUXSBffenI3yyJdeueRc0BvrY4LUYH Yn2OVjd0NnITmqfDje03cDxtosGJTESUc+LtBK4eJUYftkSgGMxZmKE0tM+QucVM k0EQUBpo4cU/QqFZ6lyU =3uiN -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HOWTO Same web application serving UI / SOAP ?
N.s.Karthik wrote: My Friend Let me Explain... I have an an web based application hosted on a tomcat server (port :8080) hence to access the application , i have to use the URL as follows *http://IP:port/APP/index.jsp* Now if some reason , I have to expose some underlying methods part's of the same web Application as SOAP requirement (Applying Axis2 config on same web application) ,I have to use the URL as follows *http://IP:port/APP/services/abcd?wsdl* What OTHER config changes / challenges should i have to do in Tomcat for multi usage ( browser / SOAP ) for the same ? Hi. Sorry, but I still do not understand clearly what the problem is. What do you call one URL ? To me, http://IP:port/APP/index.jsp is one URL and http://IP:port/APP/services/abcd?wsdl is another URL These 2 URLs happen to match for the part http://IP:port/APP/ which would mean that, using the standard Tomcat mapping rules, they would be passed on by Tomcat to the same webapp APP. Now what happens below that, with the parts /index.jsp or /services/*, is under control of the url-mapping sections of the webapp's ..(tomcat)/webapps/APP/WEB-INF/web.xml file. Is it that part that is not clear ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: In Tomcat JULI, do the 'facility specific' loggers become per-webapp logger roots?
On 9 October 2013 23:33, Christopher Schultz ch...@christopherschultz.net wrote: On 10/8/13 11:03 PM, David Bullock wrote: Please answer at Stackoverflow, and I'll report the results back to this list: http://stackoverflow.com/questions/19261727/in-tomcat-juli-do-the-facility-specific-loggers-become-per-webapp-logger-root Um, no. If you want to ask this community, then ask here. If you prefer the SO community, ask there. Feel free to ask both. But don't come here and tell us to go somewhere else to help you. Sure, it was more of an option for convenience, rather than a demand. Some answerers might prefer it, since email is so inefficient for this kind of discussion. My offer to post the results back here shows I wasn't attempting to replace this list as a forum. This intent behind this question is very similar to that asked in 2011: How to externalize a webapp's logging.properties?, but it was never adequately answered: http://marc.info/?l=tomcat-userm=131831958930163w=2 The answer was no, you can't do that. Oh you're right. The last 2 messages of the thread didn't appear in my initial search. Sorry about that. True, not to my satisfaction. Dan used one of those suggestions to effect a working solution. Nice. Virtual Class Loader seems like a good general solution to the problem that's been un-necessarily introduced by JULI, as well as many other similar problems. Or, fix your packaging and/or deployment so that it builds the correct WAR file for your environment. No thanks. The WAR is the distributable unit. All deployment-specific information must persist in the container between re-deploys, and therefore must not live in the WAR itself. Why the creators of JULI thought it would be a great idea to require a WEB-INF/classes/logger.properties is beyond my comprehension. cheers, David. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Why am i getting this exception often?
Hi i am using tomcat-7 with eclipse kepler. I am getting the following exception very often. Is there a way to prevent this? Exception:org.apache.jasper.JasperException: Unable to compile class for JSPStack trace: org.apache.jasper.JasperException: Unable to compile class for JSP at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:661) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:357) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334) at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:749) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:487) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:412) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:339) at org.apache.struts2.dispatcher.ServletDispatcherResult.doExecute(ServletDispatcherResult.java:164) at org.apache.struts2.dispatcher.StrutsResultSupport.execute(StrutsResultSupport.java:186) at com.opensymphony.xwork2.DefaultActionInvocation.executeResult(DefaultActionInvocation.java:371) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:275) at org.apache.struts2.interceptor.debugging.DebuggingInterceptor.intercept(DebuggingInterceptor.java:256) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246) at com.opensymphony.xwork2.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:176) at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:98) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246) at com.opensymphony.xwork2.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:265) at org.apache.struts2.interceptor.validation.AnnotationValidationInterceptor.doIntercept(AnnotationValidationInterceptor.java:68) at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:98) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246) at com.opensymphony.xwork2.interceptor.ConversionErrorInterceptor.intercept(ConversionErrorInterceptor.java:138) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246) at com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(ParametersInterceptor.java:249) at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:98) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246) at com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(ParametersInterceptor.java:249) at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:98) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246) at com.opensymphony.xwork2.interceptor.StaticParametersInterceptor.intercept(StaticParametersInterceptor.java:191) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246) at org.apache.struts2.interceptor.MultiselectInterceptor.intercept(MultiselectInterceptor.java:73) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246) at org.apache.struts2.interceptor.CheckboxInterceptor.intercept(CheckboxInterceptor.java:91) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246) at org.apache.struts2.interceptor.FileUploadInterceptor.intercept(FileUploadInterceptor.java:252) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246) at com.opensymphony.xwork2.interceptor.ModelDrivenInterceptor.intercept(ModelDrivenInterceptor.java:100) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246) at com.opensymphony.xwork2.interceptor.ScopedModelDrivenInterceptor.intercept(ScopedModelDrivenInterceptor.java:141) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246) at
Re: Issue while using SSL with Embedded Tomcat 6.0.37
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chirag, On 10/9/13 8:39 AM, Chirag Dewan wrote: The first request after the Server is started gets rejected. Interesting. I am setting my connector as follows: IntrospectionUtils.setProperty( this, sslProtocol, TLS ); IntrospectionUtils.setProperty( this, keystore, keyStoreFile ); IntrospectionUtils.setProperty( this, keypass, keyStorePassword ); IntrospectionUtils.setProperty( this, SSLEnabled, true ); IntrospectionUtils.setProperty( this, ciphers, cipherSet ); This is my connector configuration. I am now setting cipher,as you can see. And it is selecting the specified cipher,so that way I can limit the cipher sets to be selected by Server. What is the value of cipherSet? Perhaps you could share some /more/ code... the above for instance doesn't show how you initialize the connector, attach it to the container, etc. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSVV5IAAoJEBzwKT+lPKRYhOcP/RMB6jViNpnHboLKWMpxGZmi OhfaT3GOKmjgaN/lbKZJV5tj3Y3Sb4MrYJzybw0FRUwpkmnK0Y9YgcmiizkTRuTr Qn8axJovAYODi//PBopUuDFcM+ecqYaN7CfUVk+x7UfBDgEXtsbMqFC34BOAS4EL KwZxG1ZAsiy6Wcz2RtEqBmioHRFJFP6uyxDvgQEZL90niNtAz+tnc3ut9gVZdZt7 mRl6gEfczWTMKwRYNcE2ltXbAeDjRT1dWEShjHcf7ybawA72lxdxoc8S1iWmZBJ5 ULTdwbwIOmepbUyGT5KioXt7/uENXYElzBqnO4O6lceg0bofcub8d12JNjHUA+bD YbVHwSRkG9sjM7aou1xmK/JD6zRUbVbuBVg8HYsHZYcN5S0GEolfLlDiaz0vF6iS 56B0aYwTvBm/+KF+FPFPv/Nj+rPV0ukhE145MbHELN8rzfTbcP2m0q/dyUdddOa/ GY79VjXPevqlVUmiIlahx+woVJzpWq2pdG3AckPP0ZXehP/X4WjSmCgT+xATmg33 K88mqGgaU3zJnBpUUWe1mkUy8K0tVBSUuGNlivkHXxabY16Lci+kCsoveaVivTtp RLhTQ+eryoudQb5wGY6OWQKLdIwm8vTBQ7HArrq2OePy6tzqY/8vjKWqKXn7Byn9 FhmxAFdo+ulfNChxVIC4 =JFmk -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Issue while using SSL with Embedded Tomcat 6.0.37
Hi,
I have a wrapper connector class :
public HTTPConnector(int port, String keystoreFile, String password, int
maxKeepAliveRequests, int maxThreads, int connectionTimeout, Logger logger)
throws Exception
{
myLogger = logger;
this.keyStoreFile = keystoreFile;
this.keyStorePassword = password;
if( maxKeepAliveRequests != 0 maxKeepAliveRequests = -1 )
{
IntrospectionUtils.setProperty( this, maxKeepAliveRequests,
String.valueOf( maxKeepAliveRequests ) );
}
if( maxThreads 0 )
{
IntrospectionUtils.setProperty( this, maxThreads, String.valueOf(
maxThreads ) );
}
InetAddress address = null;
try
{
if( keystoreFile != null )
{
String cipherSet = System.getProperty(https.cipher.set);
setSecure( true );
if( myLogger.isLoggable( Level.FINER ) ) myLogger.finer(
EmbeddedTomcat using HTTPS and cipher sets + cipherSet );
setScheme( https );
try
{
// Added TLS since there is a bug in Tomcat 5.5.9. No
default protocol is set.
IntrospectionUtils.setProperty( this, sslProtocol, TLS
);
IntrospectionUtils.setProperty( this, keystore,
keyStoreFile );
IntrospectionUtils.setProperty( this, keypass,
keyStorePassword );
IntrospectionUtils.setProperty( this, SSLEnabled, true
);
if(cipherSet != null !cipherSet.equalsIgnoreCase()){
IntrospectionUtils.setProperty( this, ciphers,
cipherSet );
}
}
catch( Exception exception )
{
myLogger.severe( Could not load SSL server socket
factory. );
throw new Exception( Could not load SSL server socket
factory. );
}
}
else
{
setSecure( false );
}
address = InetAddress.getLocalHost();
if( address != null )
{
IntrospectionUtils.setProperty( this, address, + address );
}
IntrospectionUtils.setProperty( this, port, + port );
IntrospectionUtils.setProperty( this, connectionTimeout,
String.valueOf((connectionTimeout * 1000)) );
}
catch( Exception exception )
{
myLogger.severe( Exception occurred while making HTTP Connector.
);
throw new Exception( Exception occurred while making HTTP
Connector. );
}
try
{
setEnableLookups( false );
}
catch( Exception exception )
{
myLogger.severe( Exception occurred while enabling lookups. );
throw new Exception( Exception occurred while enabling lookups.
);
}
}
and I attach it to the container by :
Embedded embedded = new Embedded();
embedded.addConnector( connector );
connector.start();
and I call embedded.start(); during intialization,so I have the Tomcat running.
Chris,cipherSet is a configurable parameter. I am usually using
TLS_DHE_RSA_WITH_AES_128_CBC_SHA for testing purpose.
Thanks!
Chirag
On Wednesday, 9 October 2013 7:17 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Chirag,
On 10/9/13 8:39 AM, Chirag Dewan wrote:
The first request after the Server is started gets rejected.
Interesting.
I am setting my connector as follows:
IntrospectionUtils.setProperty( this, sslProtocol, TLS );
IntrospectionUtils.setProperty( this, keystore, keyStoreFile );
IntrospectionUtils.setProperty( this, keypass, keyStorePassword
); IntrospectionUtils.setProperty( this, SSLEnabled, true );
IntrospectionUtils.setProperty( this, ciphers, cipherSet );
This is my connector configuration. I am now setting cipher,as you
can see. And it is selecting the specified cipher,so that way I
can limit the cipher sets to be selected by Server.
What is the value of cipherSet?
Perhaps you could share some /more/ code... the above for instance
doesn't show how you initialize the connector, attach it to the
container, etc.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJSVV5IAAoJEBzwKT+lPKRYhOcP/RMB6jViNpnHboLKWMpxGZmi
OhfaT3GOKmjgaN/lbKZJV5tj3Y3Sb4MrYJzybw0FRUwpkmnK0Y9YgcmiizkTRuTr
Qn8axJovAYODi//PBopUuDFcM+ecqYaN7CfUVk+x7UfBDgEXtsbMqFC34BOAS4EL
KwZxG1ZAsiy6Wcz2RtEqBmioHRFJFP6uyxDvgQEZL90niNtAz+tnc3ut9gVZdZt7
mRl6gEfczWTMKwRYNcE2ltXbAeDjRT1dWEShjHcf7ybawA72lxdxoc8S1iWmZBJ5
ULTdwbwIOmepbUyGT5KioXt7/uENXYElzBqnO4O6lceg0bofcub8d12JNjHUA+bD
Re: In Tomcat JULI, do the 'facility specific' loggers become per-webapp logger roots?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 David, On 10/9/13 9:25 AM, David Bullock wrote: Nice. Virtual Class Loader seems like a good general solution to the problem that's been un-necessarily introduced by JULI, as well as many other similar problems. Suggestions (especially with patches) are always welcome. Or, fix your packaging and/or deployment so that it builds the correct WAR file for your environment. No thanks. The WAR is the distributable unit. All deployment-specific information must persist in the container between re-deploys, and therefore must not live in the WAR itself. Why the creators of JULI thought it would be a great idea to require a WEB-INF/classes/logger.properties is beyond my comprehension. Because loading logging.properties from the classpath is what users of java.util.logging have come to expect. The ClassLoaderLogManager doesn't have a great deal of context, so it's hard to have it decide things like where to load logging.properties from. You can't use anything webapp-context-sensitive because that information simply isn't available. I can't find anywhere to configure the context's LogManager, so it's not like writing your own would do any good. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSVWFEAAoJEBzwKT+lPKRYAAcP+weg/vyBn3VosgG2vJuyEVSm fNASx/usRdTlj039jV/n27ZyMBCiw7xxwdD+haqWp2gzXRSuubAq1oGYOBHWZ5j1 Y7JF426iB/OUe/dX2CFwCY560yWChbpa2pUYipR69STaUrH9sd6zV9rh9g2vmMs6 sJgPkk77SF5+lD26nxyj+oiHzOBHSKop6470gTZkmdrq8VNqcqtcPVns7lC1y7vw +DJZxCqbiYyZ7u64AR0VyEmJUeO/SGYSyZ4OhsA/c/YdHjlA5qKSM8RQQFufYN3F CWrlukG/puIKG/Y5JWR2DP7HIdRU3s/GMffDV+qFrU2M+Udel2v1dR3AG3P3m/1E tgYviUrfRWSPIFBJ7m8zIb75SNXQmMI67McGH6o9EAMtWQhPLNIadaqmYVAsDBYB v1zMxPW2wAdbRtS7qqmzK+PnY0QVC5c18S7ItC4aPmT/D4oew8neLl6Nge9CtjlS 4XdrruozLN3+nBPFUPjhhAYlZcmbQW60BKSAesM6RHoCCw36DRhC8UpWSCqw7Ao6 4TJClAzH/Y9cIa+ZAUGJYhljDSnKara1cKujRVZrCOvJVJV9tM54MHsN9BSprMUx W8zK6icoHP69LeJDY6NcAb3gK8rQCT9+Q5O2OjHoM9rvUdxfyKddQ6e7YMDqxnQe WdbeI/uwn+ptB773rs1H =xDKB -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Bad Gateway
You appear to be missing SSLEnabled=true on your Tomcat connector. The start-up log messages for that connector will confirm whether that analysis is correct. Mark Thank you Mark. That was it. I added SSLEnabled=true to the Tomcat connector, restarted Tomcat and the Bad Gateway error disappeared. Don't know why the production system works without that setting, unless it is because it is a different version. Anyway, we thank you very much for your assistance. This is awesome. Richard - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: SpnegoAuthenticator gives GSSException (Desired initLifetime) wih IBM JDK
Hi All,
I am struggling on SSO configuration using SPENGO mechanism on Tomcat 7.0.42
but not able to get it working. We tried on 7.0.29 version too. Since I get
Login Successful in logs, I assume Kerberos login was successful. Its
SpnegoAuthentication that is failing.
Exception:
java.security.PrivilegedActionException: org.ietf.jgss.GSSException, major
code: 11, minor code: 0
major string: General failure, unspecified at GSSAPI level
minor string: Desired initLifetime zero or less
Used http://tomcat.apache.org/tomcat-7.0-doc/windows-auth-howto.html as
reference. On decompiling SpnegoAuthenticator code, we saw that we are using
GSSCredential.DEFAULT_LIFETIME in createCredential method, which might be the
reason for the exception.
final PrivilegedExceptionActionGSSCredential action =
new PrivilegedExceptionActionGSSCredential() {
@Override
public GSSCredential run() throws GSSException {
return manager.createCredential(null,
GSSCredential.DEFAULT_LIFETIME,
new Oid(1.3.6.1.5.5.2),
GSSCredential.ACCEPT_ONLY);
}
};
Hi,
I am using the same source code for my SpnegoAuthenticator with an Oracle JVM
on Windows and a HP VM on HP-UX.
Something must be different/wrong with the JGSS Provider from IBM.
What you could do is download my source [1], change the lifetime to
GSSCredential.INDEFINITE_LIFETIME and see whether it fixes the problem.
Michael
[1] http://tomcatspnegoad.sourceforge.net/download.html
Thanks Michael. It did solve the issue.
Not sure, if it will be acceptable as a fix, due to constraints and stuff.
Appreciate the effort :).
This email and any files transmitted with it are confidential, proprietary and
intended solely for the individual or entity to whom they are addressed. If you
have received this email in error please delete it immediately.
Re: Issue while using SSL with Embedded Tomcat 6.0.37
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Chirag,
I have a bunch of non-SSL-related questions about your code.
On 10/9/13 9:59 AM, Chirag Dewan wrote:
I have a wrapper connector class :
public HTTPConnector(int port, String keystoreFile, String
password, int maxKeepAliveRequests, int maxThreads, int
connectionTimeout, Logger logger) throws Exception { myLogger =
logger; this.keyStoreFile = keystoreFile; this.keyStorePassword =
password;
if( maxKeepAliveRequests != 0 maxKeepAliveRequests = -1 ) {
IntrospectionUtils.setProperty( this, maxKeepAliveRequests,
String.valueOf( maxKeepAliveRequests ) ); }
What's wrong with calling
this.setMaxKeepAliveRequests(maxKeepAliveRequests)?
It seems like you have way more code than necessary in this class.
if( keystoreFile != null ) { String cipherSet =
System.getProperty(https.cipher.set);
setSecure( true );
Here, you're using this.serSecure(true) instead of using
IntrospectionUtils. Why some settings via IntrospectionUtils and
others with direct method calls?
setScheme( https );
try { // Added TLS since there is a bug in Tomcat 5.5.9. No default
protocol is set. IntrospectionUtils.setProperty( this,
sslProtocol, TLS ); IntrospectionUtils.setProperty( this,
keystore, keyStoreFile ); IntrospectionUtils.setProperty( this,
keypass, keyStorePassword ); IntrospectionUtils.setProperty(
this, SSLEnabled, true ); if(cipherSet != null
!cipherSet.equalsIgnoreCase()){
It might be worth calling trim() on the cipherSet value before
checking for equality with . Using ignore case on an empty string
is not going to add anything, FYI.
catch( Exception exception ) { myLogger.severe( Could not load SSL
server socket factory. ); throw new Exception( Could not load SSL
server socket factory. ); }
How about just throw exception;... any reason to completely swallow
the original exception and throw a new one? That just seems confusing.
This constructor seems much more appropriate to be a factory method
instead of a constructor for a class that trivially extends the
existing Connector. With a factory, you could also choose the type of
connector to use instead of having to extend a specific one (e.g. NIO
vs. BIO, etc.).
and I attach it to the container by :
Embedded embedded = new Embedded();
embedded.addConnector( connector ); connector.start();
and I call embedded.start(); during intialization,so I have the
Tomcat running.
Chris,cipherSet is a configurable parameter. I am usually using
TLS_DHE_RSA_WITH_AES_128_CBC_SHA for testing purpose.
That all seems fairly straightforward. I have no idea why SSL would be
acting up, there.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJSVXjbAAoJEBzwKT+lPKRYdpYP/jJfmjmJunQ6vGpuVuEQuRqd
lmAE3IflDuubcTls6XHyGrR2CM1X/3ALuu3ISm6HiRMsqACJ8EYLvOYcp821uom6
y7Gy21DkjUg7T51X1QjBQVvpt8LtKGmsQeGxmYZN91gNYJG8MFQaugPn3GDbDpVj
f8WQgDwUG5JYrKtHY1MF+neDEUkkz3xUjlTak5S2YEFi4o2wF6bCigexVUavae4v
gZgCtoTmcBhyWL/t4M0/BaAm7PdNce7GGHDl1/+yZS6rlvMC8wlxxPNCicROHySo
lTirs5boNlIVJuAXqf3pEequk+IowtoZD6Dix+Y90YX0DlExVnTkPY86n7A4QQUK
3lxvWOjjbsJn8hY4Pq8RjR64uTi/Exy6qczTeJmDVu3sY+KhtpZ1Ez+sMlCHNrHP
KlNKFEwtnO97hxZBzBUiiLl+6nMWxpWoGRXeMqYozNg6qxV2bzG3q141I5OmHjs5
fu/kGtHHZFkNIXgsxpdo/w3chSLLUFY6AtCIQdBeQ6A36Kei6ccyw1vWZL6kfLJT
UK51b+27kOpgW085dnfUncUx4bQoUrEo9+aCbRJBRbj233CMI+LOQCh+VLJqu4K+
vnlNMY2SZchSHwyoYGTCeYNg9GB9TbPjFI6T7Hq+cDdYI0hONS545ohfFojCaa8F
szV4iCbcDwgJDOrFDG1w
=g/8J
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Issue while using SSL with Embedded Tomcat 6.0.37
Chris, This is a legacy code and do need some tweaks for sure. Regarding the issue,for some other Cipher as well the handshaking is failing. I get a TCP_ZERO_WINDOW in my snoops. And thus resulting in Server sending a RST to client. Chirag Sent from Yahoo! Mail on Android
Re: Why am i getting this exception often?
I am getting this exception very often even when i am using tomcat without eclipse. Is there a way to avoid this? *Thanks And Regards,* Muralidhar Yaragalla.* (Visit My Blog http://yaragalla.blogspot.in) * On Wed, Oct 9, 2013 at 7:00 PM, Muralidhar Yaragalla java.yaraga...@gmail.com wrote: Hi i am using tomcat-7 with eclipse kepler. I am getting the following exception very often. Is there a way to prevent this? Exception:org.apache.jasper.JasperException: Unable to compile class for JSP Stack trace: org.apache.jasper.JasperException: Unable to compile class for JSP at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:661) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:357) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334) at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:749) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:487) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:412) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:339) at org.apache.struts2.dispatcher.ServletDispatcherResult.doExecute(ServletDispatcherResult.java:164) at org.apache.struts2.dispatcher.StrutsResultSupport.execute(StrutsResultSupport.java:186) at com.opensymphony.xwork2.DefaultActionInvocation.executeResult(DefaultActionInvocation.java:371) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:275) at org.apache.struts2.interceptor.debugging.DebuggingInterceptor.intercept(DebuggingInterceptor.java:256) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246) at com.opensymphony.xwork2.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:176) at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:98) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246) at com.opensymphony.xwork2.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:265) at org.apache.struts2.interceptor.validation.AnnotationValidationInterceptor.doIntercept(AnnotationValidationInterceptor.java:68) at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:98) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246) at com.opensymphony.xwork2.interceptor.ConversionErrorInterceptor.intercept(ConversionErrorInterceptor.java:138) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246) at com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(ParametersInterceptor.java:249) at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:98) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246) at com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(ParametersInterceptor.java:249) at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:98) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246) at com.opensymphony.xwork2.interceptor.StaticParametersInterceptor.intercept(StaticParametersInterceptor.java:191) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246) at org.apache.struts2.interceptor.MultiselectInterceptor.intercept(MultiselectInterceptor.java:73) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246) at org.apache.struts2.interceptor.CheckboxInterceptor.intercept(CheckboxInterceptor.java:91) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246) at org.apache.struts2.interceptor.FileUploadInterceptor.intercept(FileUploadInterceptor.java:252) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246) at com.opensymphony.xwork2.interceptor.ModelDrivenInterceptor.intercept(ModelDrivenInterceptor.java:100) at
Re: minIdle not being respected (tomcat thread pool)
On Tue, Oct 8, 2013 at 5:42 AM, Daniel Mikusa dmik...@gopivotal.com wrote: On Oct 7, 2013, at 11:14 PM, John Rellis john.d.rel...@gmail.com wrote: Hi, Tomcat : 7.0.33 Java : 6 JDBC Pool : 1.0.9.3 Grails : 1.3.9 We are running a grails app that is using the tomcat JDBC thread pool, what we are seeing is the idle connections falling below minIdle and then continuously heading towards zero over the course of a few hours. I think I understand that if validation fails on a connection or a connection becomes abandoned, it will be removed from the pool but shouldn't the pool attempt to climb back up to minIdle every timeBetweenEvictionRunsMillis?? We are not seeing this behaviour at all. I don't believe so. The pool cleaner checks for abandoned and idle connections. It first looks at the number of idle connections and checks to see if there are too many idle connections hanging around. If there are, it checks to see if it can release any connections. Then if configured to, it validates idle connections. The important thing to note is that it only removes connections, it won't add new ones. If you want to take a look check out the PoolCleaner class here. https://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java I am really confused by the behaviour I am seeing so any help that stops our connections tending towards zero is greatly appreciated! It sounds like your connections might be failing validation. Since you're validation query looks good, perhaps the connections are being disconnected from the server or a firewall in between your Tomcat server and database server. Does your database server have it have a connection timeout? If there is a firewall, does it restrict how long connections can remain open and idle? Dan The Grails WAR contains -- com.springsource.org.apache.juli.extras-6.0.24.jar com.springsource.org.apache.tomcat.jdbc-1.0.9.3.jar - Datasource parameters -- * * * * maxActive = 100 maxIdle = 100 minIdle = 80 initialSize = 100 maxWait = 5000 validationQuery = 'SELECT 1' validationInterval = 3//validate at most every 30 seconds testWhileIdle = true logAbandoned = true removeAbandoned = true removeAbandonedTimeout = 300//seconds timeBetweenEvictionRunsMillis = 6//run evictor every minute minEvictableIdleTimeMillis = 360//anything idle for more than an hour, evict, I am assuming validation means they will not be idle -- Debug Print out to the log Pool Name : Tomcat Connection Pool[1-882332278] Initial Size : 100 Active Connection : 1 Idle Connection : 66 Size : 81 Max Active Connections : 100 Max Age : 0 Max Idle : 100 Min Idle : 80 Max Wait : 5000 Log Abandoned : true Remove Abandoned : true Remove Abandoned Timeout : 300 timeBetweenEvictionRunsMillis : 6 minEvictableIdleTimeMillis : 360 Validation Query : SELECT 1 -- John Rellis - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Thanks Daniel. This helped us figure out that the connections were actually falling out of the pool because they were becoming abandoned. There's something causing some queries to hang but that is another issue. My understanding of minIdle is that it prevents evictions from taking connections out of the pool once minIdle is reached. We can return the dataSource connection settings to sane levels now that we know what is going on, it looks like our app is happy enough with circa 10 connections which is great. -- John Rellis - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Bad Gateway
On 09/10/2013 16:21, Salisbury, Richard W DLA CTR TRANSACTION SERVICES wrote: You appear to be missing SSLEnabled=true on your Tomcat connector. The start-up log messages for that connector will confirm whether that analysis is correct. Mark Thank you Mark. That was it. Happy to help. I added SSLEnabled=true to the Tomcat connector, restarted Tomcat and the Bad Gateway error disappeared. Don't know why the production system works without that setting, unless it is because it is a different version. It could be. You might want to check that because any earlier version is likely to have known security vulnerabilities (5.5.x certainly does). That might be an issue depending on the nature of your production system. Mark Anyway, we thank you very much for your assistance. This is awesome. Richard - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SpnegoAuthenticator gives GSSException (Desired initLifetime) wih IBM JDK
Am 2013-10-09 17:28, schrieb Chawla, Rachit:
Hi All,
I am struggling on SSO configuration using SPENGO mechanism on Tomcat 7.0.42
but not able to get it working. We tried on 7.0.29 version too. Since I get
Login Successful in logs, I assume Kerberos login was successful. Its
SpnegoAuthentication that is failing.
Exception:
java.security.PrivilegedActionException: org.ietf.jgss.GSSException, major
code: 11, minor code: 0
major string: General failure, unspecified at GSSAPI level
minor string: Desired initLifetime zero or less
Used http://tomcat.apache.org/tomcat-7.0-doc/windows-auth-howto.html as
reference. On decompiling SpnegoAuthenticator code, we saw that we are using
GSSCredential.DEFAULT_LIFETIME in createCredential method, which might be the
reason for the exception.
final PrivilegedExceptionActionGSSCredential action =
new PrivilegedExceptionActionGSSCredential() {
@Override
public GSSCredential run() throws GSSException {
return manager.createCredential(null,
GSSCredential.DEFAULT_LIFETIME,
new Oid(1.3.6.1.5.5.2),
GSSCredential.ACCEPT_ONLY);
}
};
Hi,
I am using the same source code for my SpnegoAuthenticator with an Oracle JVM
on Windows and a HP VM on HP-UX.
Something must be different/wrong with the JGSS Provider from IBM.
What you could do is download my source [1], change the lifetime to
GSSCredential.INDEFINITE_LIFETIME and see whether it fixes the problem.
Michael
[1] http://tomcatspnegoad.sourceforge.net/download.html
Thanks Michael. It did solve the issue.
Not sure, if it will be acceptable as a fix, due to constraints and stuff.
Appreciate the effort :).
If this one works, are you able to file a bug with IBM's JVM?
The behavior should be the same as in Oracle's VM or MIT/Heimdal Kerberos.
Michael
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Issue while using SSL with Embedded Tomcat 6.0.37
Hi , A small update. The customers client is C++ client,which uses OpenSSL. And I found that client hello message is SSLv2 protocol. And the server response(server hello) is a TLSv1 protocol. Is there something I am missing? Chirag On Wednesday, 9 October 2013 9:25 PM, Chirag Dewan chirag.dewa...@yahoo.in wrote: Chris, This is a legacy code and do need some tweaks for sure. Regarding the issue,for some other Cipher as well the handshaking is failing. I get a TCP_ZERO_WINDOW in my snoops. And thus resulting in Server sending a RST to client. Chirag Sent from Yahoo! Mail on Android
