Re: WorkManager replacement
On 2/13/2015 7:29 AM, Daniel Mikusa wrote: On Thu, Feb 12, 2015 at 11:59 PM, Kevin Hale Boyes kcbo...@gmail.com wrote: I currently have an application running on weblogic that I'm moving over to tomcat 8. One of the things the application does is run background jobs using the commonj WorkManager. These jobs are managed by weblogic which seems to be the recommended practice. What is the best/recommended way to run background jobs in Tomcat 8? Personally I'd use Spring, which has a nice and simple way to schedule tasks. I'd also be using Spring for other things though and I'm not sure I'd pull it in just for scheduled tasks. I use java.util.timer for my scheduled jobs in tomcat. A quick google search came up with this library. http://commonj.myfoo.de/ Haven't personally used it though. I suppose another option would be to just use java.util.concurrent. Dan Thanks, Kevin - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: WorkManager replacement
On Fri, Feb 13, 2015 at 9:49 AM, Kevin Hale Boyes kcbo...@gmail.com wrote: We already use Spring in the project so I'll have a look there. http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#scheduling Dan Thanks On 13 February 2015 at 05:29, Daniel Mikusa dmik...@pivotal.io wrote: On Thu, Feb 12, 2015 at 11:59 PM, Kevin Hale Boyes kcbo...@gmail.com wrote: I currently have an application running on weblogic that I'm moving over to tomcat 8. One of the things the application does is run background jobs using the commonj WorkManager. These jobs are managed by weblogic which seems to be the recommended practice. What is the best/recommended way to run background jobs in Tomcat 8? Personally I'd use Spring, which has a nice and simple way to schedule tasks. I'd also be using Spring for other things though and I'm not sure I'd pull it in just for scheduled tasks. A quick google search came up with this library. http://commonj.myfoo.de/ Haven't personally used it though. I suppose another option would be to just use java.util.concurrent. Dan Thanks, Kevin
Re: [OT] Java client using Expect: 100-continue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Konstantin, On 2/12/15 11:52 AM, Konstantin Kolinko wrote: 2015-02-12 19:43 GMT+03:00 Christopher Schultz ch...@christopherschultz.net: All, I've been trying to find some information online about how to do this, and maybe I'm just being bad search terms. I've not yet played-around with any code for this, but I'm interested in observing the server's response to an Expect: 100-continue header when a request has a body (e.g. PUT, POST, etc.). This is from an HTTP client's perspective, and I've got code that already uses HttpURLConnection to open a connection and stream a body if requested. Before streaming the body, I'd like my code to take a look at the server's response and maybe make some decision based upon that. For instance, if the server replies with 417 Expectation Failed then I'd like to maybe throw some kind of exception, or maybe .. I dunno, compress the request to see if the body is small enough to re-try. Anyhow, I don't see anything in the API that directly supports this, and I haven't found anything online about how to do this in HttpURLConnection other than the obvious setting of the HTTP header. Is this something that HttpURLConnection does not expose to the programmer? Does it simply handle the situation on its own? See the following recent BZ issue for a link https://issues.apache.org/bugzilla/show_bug.cgi?id=57530 Thanks. From my reading of that, the answer is you can't do what you want to do. I'll play around with what happens with 417. I'm almost certainly not going to abandon HttpURLConnection and deal with the socket directly. :) Thanks, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJU3gN/AAoJEBzwKT+lPKRY0pQP/jGYycc/jNu6z2Tk5CReBv3T 7IOT0QtRmTx8/6O3hjCXbGCXTYPTaDZTKW4uP4r/BGvvzJpRsXj7KwzlVWxEeSw3 OEJyinCstCL1tcOrN0Rvc5CH/2X/k8iLVEp/7YSrC0k8pvm3mNU/mzqilN54Z2vY Fq3SBZUqxhRkUXyq1VPsWA1EZcUnH378E1E+FJi0znPExCH+wSRXYvMCMIwOEaEw OAB7Xf5ocBxPWGg6AEuCspQh1Xp4oUxct2O9EslmQwxA++nT8ypVj2QL7krcZIeI oR9z3vPJVWbxHNL2V4B6rvEjdv6BlNoI72Ym6Xt1A8Ss0nqdkqB/VipiYXBIxmOe uy++MzCegq+eleHGDlWLtV7nIq2OgGnP8P0fdIpq8qY5hIul6RlbURr1EtwZSzcj 7mHhFU2h1WEgw8PzIVu/dATwXiPoQQAU5tasZnwyny1hIWuN46jRTsvvHtemICsM OxepL0JttfgDYN9KLBuwZySZm4O9OW2MxC0qoGXdv4v8g/9qJYLmQoi2aa9CeuuL xYfqtAiZbOs8Pl+M5ffbNFWL3E4WrOTjR9OlFr51hj4Q5b9nnzZNi+p2uioPhfgE GdbwEOQqkubOFOVAq9ilvjMY5T9UQmabyYQeSYGI3o6e1AAusiOKG/96PQifTp9M qRAu1f5vdFWuqjhuwUdH =MRJR -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: WorkManager replacement
I'll look into the timers for sure. I've also noticed that my application (lots of code) also uses Executors and ExecutorService so I might do something there. One of the things that WorkManager gave us, and we take advantage of, is a callback handler that lets us know when the work was accepted for processing and when it was complete. I'll have to find replacements for that feature. Maybe that's easily done with Future's in the concurrency framework. Thanks for your help. Kevin On 13 February 2015 at 06:15, David kerber dcker...@verizon.net wrote: On 2/13/2015 7:29 AM, Daniel Mikusa wrote: On Thu, Feb 12, 2015 at 11:59 PM, Kevin Hale Boyes kcbo...@gmail.com wrote: I currently have an application running on weblogic that I'm moving over to tomcat 8. One of the things the application does is run background jobs using the commonj WorkManager. These jobs are managed by weblogic which seems to be the recommended practice. What is the best/recommended way to run background jobs in Tomcat 8? Personally I'd use Spring, which has a nice and simple way to schedule tasks. I'd also be using Spring for other things though and I'm not sure I'd pull it in just for scheduled tasks. I use java.util.timer for my scheduled jobs in tomcat. A quick google search came up with this library. http://commonj.myfoo.de/ Haven't personally used it though. I suppose another option would be to just use java.util.concurrent. Dan Thanks, Kevin - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: WorkManager replacement
We already use Spring in the project so I'll have a look there. Thanks On 13 February 2015 at 05:29, Daniel Mikusa dmik...@pivotal.io wrote: On Thu, Feb 12, 2015 at 11:59 PM, Kevin Hale Boyes kcbo...@gmail.com wrote: I currently have an application running on weblogic that I'm moving over to tomcat 8. One of the things the application does is run background jobs using the commonj WorkManager. These jobs are managed by weblogic which seems to be the recommended practice. What is the best/recommended way to run background jobs in Tomcat 8? Personally I'd use Spring, which has a nice and simple way to schedule tasks. I'd also be using Spring for other things though and I'm not sure I'd pull it in just for scheduled tasks. A quick google search came up with this library. http://commonj.myfoo.de/ Haven't personally used it though. I suppose another option would be to just use java.util.concurrent. Dan Thanks, Kevin
Tomcat Access Logging Valve ?
I am running Tomcat 7.0.54 on a Windows 2008 R1 with SP1 platform. I would like to control the contents of what gets logged to the Tomcat localhost_access_log specifically , I would like to remove logging of entries like : 10.239.54.8 - - [13/Feb/2015:00:00:07 -0600] GET /atb HTTP/1.0 200 573 10.239.58.29 - - [13/Feb/2015:00:00:08 -0600] GET /atb HTTP/1.0 200 561 we have some external load balancers and server monitoring software periodically hitting the application web page to see if it is responding. I would like to know how remove these entries to reduce the amount of noise that is in the localhost_access_log log file, but allow other entries (i.e. from OTHER IP addresses or with other functions like POST or other strings like HTTP/1.1 I have examined the information at the below link (unfortunately there is no example there with detail on what I am attempting to do). http://tomcat.apache.org/tomcat-7.0-doc/config/valve.html Seems like I want to use the valve Access Log Valve Attributes: conditionIf or conditionUnless options from valve documentation, but it is not clear to me how to do this (if this is the correct way ?). Server.xml currently has the following setup configuration: !-- Access log processes all example. Documentation at: /docs/config/valve.html Note: The pattern used is equivalent to using pattern=common -- Valve className=org.apache.catalina.valves.AccessLogValve directory=logs prefix=localhost_access_log. suffix=.txt pattern=%h %l %u %t quot;%rquot; %s %b / Is it possible to do this without programming (i.e. can I set the valve components to simply filter on an ip address or key word string (i.e. Get /atb HTTP/1.0 and if that value is found in the request, can I chose to then NOT write that entry to the AccessLogValve). I have searched pretty thoroughly for some time on how to do this, but the documentation simply does not provide enough of an example on how to do this. I am not a programmer, but would think that filtering entries out of logs based on criteria would be a valuable feature to have. Any example would be greatly appreciated Thanks Jeff Sent from Google Nexus Phone
Re: tomcat severe error when shutting down service but startup is clean
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Kevin, On 2/12/15 11:58 AM, Wirth, Kevin wrote: -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Thursday, February 12, 2015 11:54 AM To: Tomcat Users List Subject: Re: tomcat severe error when shutting down service but startup is clean Kevin, On 2/12/15 11:46 AM, Wirth, Kevin wrote: It should be logging to stderrour correct? I don't see anything extra in that file other than the same severe messages I have been getting. That depends upon how you tried to trigger the thread dump. Care to be specific? Thanks, -chris I right clicked the tomcat manager and selected thread dump and then stopped the service The Windows Service Manager? That will either cause a thread dump on standard output (or standard error) and therefore be in whatever log file you have configured to capture standard output (or stderr). The default is service-stdout.YEAR-MONTH-DAY.log for stdout and service-stderr.YEAR-MONTH-DAY.log for stderr. The files should be in Tomcat's logs/ directory. If you have split CATALINA_HOME and CATALINA_BASE, then they will be under CATALINA_BASE/logs. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJU3iS8AAoJEBzwKT+lPKRY/PsQAJzzxk3Dt5hgIDtSk1/UX7hX /qHbfLyNxP9qR1sTlQJL56eqY6LKKS8Lf+PofgglX4gIenkzQfem+K/l0qpCN8j/ 1nSe7Tx3cjFv4uZpeH/RVZPym76fyARjBDH/CLMrlXhBE95f81C4jz25gsHG6QQw pb/0xDcQENpkzX2BusE+H73Z5CXSW7y9AgF+TD+sdsgIxNTvSeX09EngXFJmSbed GlN5RsDydrOEqFUiZoDTobePlC819tv1SoUmgE273uUU9ZElmU5IV96KvJj7vxfw ojXNstplI3NsYzGDUXo4Uz24Zzfe3VPWLiXLgexmWt2Iatx9CowfUEwn8BqIND9R WXSeRfNIg1FDgzbPXsVYRKZm5cxleO2SSP8OsN+xjdj/E2ZU7OfzVMFRwv01UHJC gcA/jXbYWe3TBokZa7MczthC/OPsh1nzpFbTonJzO6w/VvBRkwV0ppcRmIKAF47L 4R4JM53sm2yz/fhQ1yaPTEsAOZWVzLw0OqZkGSuRMlEBRz/QpF3HEVd9XE524bNG CulYs4kfsVCT1WbS4OQQLRDLpXeEP5rQjxyG5WTSypr7x1n+RkWmT6OtU98xKf66 zcdjCGDpPX41E3sZQxenEeND949qrlcHISjPPgIkcA+cFAlR74ArI2Rt9BsbyVOv /N5pE2OhqgTl2Rd84UDF =4WGJ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat severe error when shutting down service but startup is clean
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
David,
On 2/12/15 2:01 PM, David kerber wrote:
On 2/12/2015 1:46 PM, Wirth, Kevin wrote:
-Original Message- From: David kerber
[mailto:dcker...@verizon.net] Sent: Thursday, February 12, 2015
1:00 PM To: Tomcat Users List Subject: Re: tomcat severe error
when shutting down service but startup is clean
On 2/12/2015 12:48 PM, Cris Berneburg - US wrote:
-Original Message- From: David kerber
[mailto:dcker...@verizon.net] Sent: Thursday, February 12, 2015
9:40 AM To: Tomcat Users List Subject: Re: tomcat severe error
when shutting down service but startup is clean
On 2/12/2015 9:06 AM, Wirth, Kevin wrote:
I keep getting these weird tomcat errors on shutdown on a
newly built system using tomcat 7.0.57 on a windows 2012
server with jdk 1.7 that I can't figure out. This is the
catalina log: Feb 12, 2015 8:54:31 AM
org.apache.catalina.loader.WebappClassLoader
clearReferencesJdbc SEVERE: The web application [/identityiq]
registered the JDBC driver
[com.microsoft.sqlserver.jdbc.SQLServerDriver] but failed to
unregister it when the web application was stopped. To
prevent a memory leak, the JDBC Driver has been forcibly
unregistered. Feb 12, 2015 8:54:31 AM
org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads SEVERE: The web application
[/identityiq] appears to have started a thread named
[Thread-3] but has failed to stop it. This is very likely to
create a memory leak.
I ran into this a while back, and it means exactly what
it says: the db driver is being registered (loaded), but
not being unloaded. I fixed it by putting the db driver
unload commands in a contextDestroyed method.
David
I have the same issue as Kevin. What unload commands code
did you call in the contextDestroyed method? Are those methods
universal? The reason I ask is because we use different ODBC
drivers for different environments.
I call this code from my .contextDestroyed method (I didn't write
it, I copied it from somewhere on the web):
public static void unRegisterDrivers() { try { for (
EnumerationDriver drivers = DriverManager.getDrivers();
drivers.hasMoreElements(); ) { DriverManager.deregisterDriver(
drivers.nextElement() ); } } catch ( Exception e ) { /* log the
exception */ } }
Thank you for your response. Where do I put this code as I am
new to tomcat? The application I am deploying is not written by
me so I don't know the code.
It needs to be called from the .contextDestroyed method of
whatever class is defined as a listener in your application. I
don't know if it can be done without modifying existing classes or
not.
Yes, you can write a new ServletContextListener and register it along
with any others you may have. There is no need to modify existing code
(but you will have to add new code).
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJU3iVhAAoJEBzwKT+lPKRYOLMP/1gTWvu2ejJ28PJRC8wXo83s
5ScuJ915aIYq3Rbf+UjguXswkw2M9KGu7Uoi1svHYoqBY9iGbGIo/vand8ifkUUU
Vpm2IbIkgZM/Epemu9xSTJu/0pZNSFiYD0zHdItNsBbSm0zDtxR8aUQWp2IwdBnN
nawH7ePTNbtF3WwM8raDEyij3rL+tKwEYOsy3mwEdpPAVwMBANS4XOzjae6TgrCJ
VUMS30y4/aF9VMJZh+HuuCqafJ9ApVBj0Rpjgt4b11GSpeTwHtSWkf5L2IQ8i6DL
1uuS7WTz02aqUgM1E4lGRvRxJcmb9G+EPMLLW+EFcBC8E4pE2YP6oA5+BolWVp1N
vH4GjUwnT2EqYCSxtpzpzZEDpUdh6mJ0JrKtT2VZ4GxSA1BH00rBIK0GPC4WMEvu
H6DE0K2f/iDvrcaAxqNrVzkVABQmoOdwesXLWH75tGTLoGVF7E+3UuKcYAnrizdn
4SihCHQOeMWfuHh1YlYEh2JoSpGx30djwG7xq72BJzUyr4+WpGEEGXtDIAqX3tBU
ZaurvkbF727Ps7KN2Zz0+VSp3o9D0taXjHOq9hpjBh2iJI8L8k/R8MdSl0fqJvsc
zTo5+z+cMUQ2dQguWpuM9NydoSaZTJS6CiIqmKBTGE5i9W1PaHoQKdaTO+w4KqEY
cfnw3Xk28pGQ1pQ4kqSk
=J7AW
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat severe error when shutting down service but startup is clean
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 JB, On 2/12/15 1:06 PM, JB MORLA wrote: Unsubscribe FYI: To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - -chris Le 12 févr. 2015 15:06, Wirth, Kevin kwi...@astoriabank.com a écrit : I keep getting these weird tomcat errors on shutdown on a newly built system using tomcat 7.0.57 on a windows 2012 server with jdk 1.7 that I can't figure out. This is the catalina log: Feb 12, 2015 8:54:31 AM org.apache.catalina.loader.WebappClassLoader clearReferencesJdbc SEVERE: The web application [/identityiq] registered the JDBC driver [com.microsoft.sqlserver.jdbc.SQLServerDriver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered. Feb 12, 2015 8:54:31 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: The web application [/identityiq] appears to have started a thread named [Thread-3] but has failed to stop it. This is very likely to create a memory leak. The jdbc driver I am using is in the folder identityiq under the webapps directory in tomcat. It is the sqljdbc4.jar driver. This driver is not in the tomcat\lib directory. Please help because I am getting no help from the vender. Thank you. Kevin Wirth Sr. Systems Engineer Information Services Astoria Bank * (516) 327-7762 | * kwi...@astoriabank.commailto: kwi...@astoriabank.com Astoria Federal Savings is now Astoria Bank. We can now be contacted at our new email addresses @astoriabank.com. This e-mail and any attachments that accompany it are confidential and may be legally privileged. It is intended solely for the use of the individual(s) to whom it was intended to be addressed. Access to this e-mail by anyone else is unauthorized. If you are not the intended recipient, please immediately return the e-mail to the sender and delete the original and any copy from your computer. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to its intended recipient, you are herewith notified that any dissemination, distribution, copying or retention of this communication or the information contained herein is strictly prohibited. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJU3iWKAAoJEBzwKT+lPKRYp2AP+wZq30z2A+Mp+0gbk2mk38t2 f78zfkEiTgkDErhrpv1ct5l+35AP7bIsNo/lcLa+LhI2te8fDBGSqcSWVIau8OjT /0IkwE7QeTUyJkMUxmS/VW5gG7JT0Bz2hXIPlLwOZZWb1mHzV0DALu9ZIn4agkFN hP88xiFm9VrvGXN7KrG/Ts2bUZnZr91pbk2dbx5/buIBmMm7sYiLBqItFwx6g+5M j3fh9Op6O2IXLjeBfuzVWkpDzCeCrOR8WO64xJEuMHj77VrRtrEyZOKYjZNihFbR /F9NDRy2IpXJr+ETIffGge34Ty/3jgi0kN4GfVfqUJZOmLZBnoxWCNJJW1U6okK/ PqCd+hjw8JdzuFLeRIfGZ6/Tapq+OFAPNJTcT/5/cwl0gFoDiPMvF2+1ksyKjQUh 4iLeqRJgur2ZQ7HkfRIWDW+C2ngT3bUJQSEHkSdeAoirUD97gY9DOAC5UaWBGI7r rzHm0LSA9MGZ16D0g05xSwH3h7sABRuy2A0iydyrPoT/93BDHGSCGLQB9fK8cZge qyDR0L7AC4uipVmKnrXoYrmqdcMlbS6MJOnDT/gMZ87LSzT32Vym3Vr5kRk2cowb ZGJhjWe4GC+OKnfVs2jYenhw5GJEt4GePOKTaHZ/rhpU3a7fZjw6dsntmxBcelko WGYC2KLJMDaUVKpnm2YX =wSD1 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Access Logging Valve ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jeff, On 2/13/15 10:28 AM, Jeff Kohut wrote: I am running Tomcat 7.0.54 on a Windows 2008 R1 with SP1 platform. I would like to control the contents of what gets logged to the Tomcat localhost_access_log specifically , I would like to remove logging of entries like : 10.239.54.8 - - [13/Feb/2015:00:00:07 -0600] GET /atb HTTP/1.0 200 573 10.239.58.29 - - [13/Feb/2015:00:00:08 -0600] GET /atb HTTP/1.0 200 561 we have some external load balancers and server monitoring software periodically hitting the application web page to see if it is responding. I would like to know how remove these entries to reduce the amount of noise that is in the localhost_access_log log file, but allow other entries (i.e. from OTHER IP addresses or with other functions like POST or other strings like HTTP/1.1 I have examined the information at the below link (unfortunately there is no example there with detail on what I am attempting to do). http://tomcat.apache.org/tomcat-7.0-doc/config/valve.html Seems like I want to use the valve Access Log Valve Attributes: conditionIf or conditionUnless options from valve documentation, but it is not clear to me how to do this (if this is the correct way ?). Yep, this is what you are looking for. Server.xml currently has the following setup configuration: !-- Access log processes all example. Documentation at: /docs/config/valve.html Note: The pattern used is equivalent to using pattern=common -- Valve className=org.apache.catalina.valves.AccessLogValve directory=logs prefix=localhost_access_log. suffix=.txt pattern=%h %l %u %t quot;%rquot; %s %b / Is it possible to do this without programming (i.e. can I set the valve components to simply filter on an ip address or key word string (i.e. Get /atb HTTP/1.0 and if that value is found in the request, can I chose to then NOT write that entry to the AccessLogValve). I have searched pretty thoroughly for some time on how to do this, but the documentation simply does not provide enough of an example on how to do this. I am not a programmer, but would think that filtering entries out of logs based on criteria would be a valuable feature to have. You have to have a way to set (or not) a request attribute in order to use conditionIf/conditionUnless. One way to do it without writing any of your own code is to use url-rewrite, which is more like url-do-whatever: http://tuckey.org/urlrewrite/ You can configure that to set request attributes under certain criteria. Just have it set (or not) whatever attribute name you use for your conditional logging and you should be good to go. Hope that helps, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJU3iZ0AAoJEBzwKT+lPKRYWwgQAJ5DbuAXSfLFsrEW28fO8o3s BaSlltKTATrxY1LqBHGl/6HHTxs9qedE2LWRfoF6532GtVBB8bhWkb4pu/UWmO5x mVCsfHPL3EOpAeCioXnavm17O+7+fs/dYiaXHqynLQlINUTTvUnMgXYciBtIsMGx O8NPRRSrL8LZu2jD6VC0z3ruvvfq3aXFhyvTaBQWxme1OuETmu1LudVt9CrHA1ZY e9Mj4QM3GoXcZJwDH/ZbTQJUymEgXQNj3tyLYqPT6FuMLOGHTDJ9ok9kKxyw461p 9a73H6HpDSCCG3zc/eAudW7YPkxyjM0zez/B0PrGrz28zp5nnrqgFWzHvAIzVD/W 8F0+GBrHebMBlQ9nU1SQChq2mveDJ38kIq7mdm8j4Ncl2Y8W3Umq6YUWSGh3MNmG EtX4KpXE2gT+k5JuCI1E3v+6B/jP+1cv4onjN6y7ZaYjd3fM4nAQWA5N9K/xmPaO qgj4obHTFM76iseit5KgkRihJNAsCLmiQVqQ9KsJUKZe16xMcTLcLh3SAZRW+f07 JJmNiKipaHBpOhWwXH4ZN6CIfXOsx/MKn3o+FjQzodSkv6/6E3l2J4niemy7xIY7 z+ywCKa2ij6mFYHnmmfJEBdZ+5r19ESLasJPP5OdpFHbczY3o0LamYkuXQ9fzENU 89hMIQXCyw7qCmlTfvCF =EZML -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: To log TLS sessions !
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Utkarsh, On 2/13/15 12:39 AM, Utkarsh Dave wrote: Need your thoughts and comments on the requirement where we need to log/capture information when TLS sessions are setup, the logs will be logged to indicate successful or failed connection establishment or even connection being disconnected. RequestDumperFilter is one way but that will dump each and every requests and response in detail My first thought would be to see how the RequestDumperFilter does it, and then only use that part of the code. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJU3idTAAoJEBzwKT+lPKRYvmcP/1rZ+DuMyTFq9rxyxYcVlH9I s2gcCjSP4vXWEmwV6mTeVP6kD1v2ld8/ZsMcCI9kHPiT9XIFe8w4o9HJQ4vYsu1D hwzNdIhSvYmQzijcUnDxy4M7bG43SRDrEoWLCgcbKx9SBCy5pnoh7fZ5Ubafmv3Z 1eQ6LNha5bY+8CH7Vodkt9ISYZeBUnnWz6TpPlD/wLEst/tF4MyBCyEuqxxJXDMn 9K8OPhnkoXGk2P4Q4dtl+f8CTKWXaWAVA4kynz75zhmaFy68B73bjI+VKubJUnrc 65xsijSVE32ZtFoBxa9I/nw6NwjcvFfjNNvfq/OEZtDEwS7ji88p/J2VFJ3GzI7o isYIuDHftiTeNjS0Q4eZ7EN9YtuuHn+a3tBzZhg6duBERu0aywjK0PEkbPWJP8BX 9fIx75Rqy7iBFcD5rmnmDgRah+R9kqvnAWpYdJWL+CB2kq6mo+0HZT/NQMSZ0PHa BTUIyJGac6DzToeyJ4HjFa8GPGAN68gJsVNX6NM+KUxVNSb6XaMTCTVxWic16QD0 W5FDoEXU7MTEaVN8jUE58VJPIBrXMVbIO5dGuPrjNFqmGteClVN17ULRlGTx+2ru k58MCN0uCRxlCfGQTky3BbcgwAACVpgWNx1dd7N9mfdbGnv92FDX/sU/V0DTeNqF gHGXzkIPn8vfxyJFFAPr =gnmt -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat severe error when shutting down service but startup is clean
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
David,
On 2/13/15 11:33 AM, David kerber wrote:
On 2/13/2015 11:23 AM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256
David,
On 2/12/15 12:59 PM, David kerber wrote:
On 2/12/2015 12:48 PM, Cris Berneburg - US wrote:
-Original Message- From: David kerber
[mailto:dcker...@verizon.net] Sent: Thursday, February 12,
2015 9:40 AM To: Tomcat Users List Subject: Re: tomcat severe
error when shutting down service but startup is clean
On 2/12/2015 9:06 AM, Wirth, Kevin wrote:
I keep getting these weird tomcat errors on shutdown on a
newly built system using tomcat 7.0.57 on a windows 2012
server with jdk 1.7 that I can't figure out. This is the
catalina log: Feb 12, 2015 8:54:31 AM
org.apache.catalina.loader.WebappClassLoader
clearReferencesJdbc SEVERE: The web application
[/identityiq] registered the JDBC driver
[com.microsoft.sqlserver.jdbc.SQLServerDriver] but failed
to unregister it when the web application was stopped. To
prevent a memory leak, the JDBC Driver has been forcibly
unregistered. Feb 12, 2015 8:54:31 AM
org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads SEVERE: The web application
[/identityiq] appears to have started a thread named
[Thread-3] but has failed to stop it. This is very likely
to create a memory leak.
I ran into this a while back, and it means exactly what
it says: the db driver is being registered (loaded),
but not being unloaded. I fixed it by putting the db
driver unload commands in a contextDestroyed method.
David
I have the same issue as Kevin. What unload commands code
did you call in the contextDestroyed method? Are those
methods universal? The reason I ask is because we use
different ODBC drivers for different environments.
I call this code from my .contextDestroyed method (I didn't
write it, I copied it from somewhere on the web):
public static void unRegisterDrivers() { try { for (
EnumerationDriver drivers = DriverManager.getDrivers();
drivers.hasMoreElements(); ) { DriverManager.deregisterDriver(
drivers.nextElement() ); } } catch ( Exception e ) { /* log
the exception */ } }
This is likely to over-reach in many scenarios. YMMV.
Also, Tomcat already de-registers drivers for you. So, this
probably isn't really changing anything.
We manage the pooling in our application, and don't use any of
TC's connection pooling. This is largely because several years ago
(long enough ago that the then-current version of TC was 5.5.25)
the app was moved from another servlet container that either didn't
have pooling, or it was harder to use than it was to write out own.
I wasn't in on the initial development, but did the port to TC.
And at the time I did the port, I had no idea about TC's connection
pooling, so continued with our own pooling implementation.
Until I did this, I could not get rid of the memory leak warnings.
If there is another way, I couldn't find it at the time I was
messing with it...
I'm not sure at what point Tomcat started de-registering drivers. When
it de-registers a driver, it gives you a warning. By you doing it
yourself, you are avoiding the warning, of course.
But if you de-register all drivers, you are also de-registering any
drivers that were registered by different web applications, Tomcat's
connection-pool, etc. It would be better to only de-register the
driver(s) you actually registered in the first place.
I haven't researched such things, but a reasonable way might be to do
something like this:
ClassLoader cl = Thread.currentThread().getContextClassLoader();
for(Driver driver : DriverManager.getDrivers())
if(cl.equals(driver.getClass().getClassLoader()))
DriverManager.deregisterDriver(driver);
This way, you only remove drivers you load yourself. Alternatively,
you probably already know which drivers you have explicitly loaded, so
you could explicitly unload them instead of flushing the whole
DriverManager.
Note: I have no idea if Driver objects get the proper ClassLoader
assigned, but it's worth a try to get a bit more safety.
If your web application is the only one loaded, feel free to wipe-out
the DriverManager like that. But, if you need to operate in a shared
environment, your technique above might negatively impact other code
that relies on its driver not being forcibly un-loaded out from under it.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJU3iw8AAoJEBzwKT+lPKRYu44QAJs8etPXC8CiQxlkPLnBY5lp
A13W+Ibk2X7TX/y3oIIry7juiFWMWBrVKaxFuVEcBgI4P3lfQ5rZAbba44of9r2N
RhXdwIepEgATD3E+LaRTAPuHOv5vZ2hhsj8GhlVp4caa2VCpY/iKL4Ax2w5vttrX
38Cp80eIXaLOl1M802bnoOI3s4NUaCo7+zWOAPXzZ1f1jyQx/H9Vbau90CcmQeIm
t17BOYa3C88FDc2QGfrbucYNqRKYLlUQcGhP+tjtyBv7qcWvBMprUz7dvFhtNTHQ
pEGWctPnJlza3e5quyQrFtLnLcAWlzKwvCxrCFhMDB6FeEpj21fFZYvrNKRHau+T
Yr3ZQ03+PepqyT+graWSSd5ejCRNrmXeTgw/9r+KCimbBp40DbDqWFzWh7OH6OAN
Re: WorkManager replacement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dan, On 2/13/15 7:29 AM, Daniel Mikusa wrote: On Thu, Feb 12, 2015 at 11:59 PM, Kevin Hale Boyes kcbo...@gmail.com wrote: I currently have an application running on weblogic that I'm moving over to tomcat 8. One of the things the application does is run background jobs using the commonj WorkManager. These jobs are managed by weblogic which seems to be the recommended practice. What is the best/recommended way to run background jobs in Tomcat 8? Personally I'd use Spring, which has a nice and simple way to schedule tasks. I'd also be using Spring for other things though and I'm not sure I'd pull it in just for scheduled tasks. A quick google search came up with this library. http://commonj.myfoo.de/ Haven't personally used it though. I suppose another option would be to just use java.util.concurrent. That amounts to rolling-your-own. If you just need to do something on a rough schedule, then java.util.concurrent is fine: start a thread that does something every 10 minutes or whatever. If you want real scheduling, you want something like Quartz: http://quartz-scheduler.org/ I would argue that there are better solutions than using Quartz from within your own web application, but it depends upon your perspective. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJU3icEAAoJEBzwKT+lPKRY9bIP/ilEoImpKncX82WU+SqgQQgP zUhUTP0x+bntXNpouuxbb1NOhHKH6d7l0p2WKkQRoKf2qxJzxYhEnAiBELCI7CQF 02OrXnzl4VmatgVgd5Aom/7QIzhLArLKNosGwIS8d/BbssPcZS6plBTU70VS8C7D I+QON7RW3veJG9SFFA5sKrGhlgFuDUTbrLcz/oZeZ2xdbg4s2htAH9B+XNz5Gbvv NKESUASPTGzYCSwZhgwIVoxZZavdkCwVvSJIEyPDlGwMDrBkYdSg/GbctyHA8Mny METMmlN9Q29mEc6/VNSv6B+XtqUWCPud0WAPZm6rIso7NaV/ScY+/L19lzvLOn1a SvwYavQ8bdGWb+w5xIcnsnZkLknwaDJoYMerquwnCxsPqaAdBygdku8OuvA8PxT4 eIlUCOoT5GjxWTEX+HIWBvyx2KXTM8EScYdyXCuGtxnKcpexYaXBJQ2GhNc4EHym T3JiLu/fAIu4TWyI6oM64YLMfJfNk49gNtPCjWfRluG4qqKQ3YqjQubf8FIe/vOe y1wXzC/7KtV1urLDL74mLTjGpihiig3e9CRa7MWK354K/WoSlgbkze/Ac1df40g+ Zq1MpgnGQmjgvG16FGujeL5U+QlwFTXYNAqXKsP0++FJJ9DEhkQM8c0yYlDplOYZ xFKob5fnVsgVj1flZH4N =aLoS -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat severe error when shutting down service but startup is clean
On 2/13/2015 11:23 AM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
David,
On 2/12/15 12:59 PM, David kerber wrote:
On 2/12/2015 12:48 PM, Cris Berneburg - US wrote:
-Original Message- From: David kerber
[mailto:dcker...@verizon.net] Sent: Thursday, February 12, 2015
9:40 AM To: Tomcat Users List Subject: Re: tomcat severe error
when shutting down service but startup is clean
On 2/12/2015 9:06 AM, Wirth, Kevin wrote:
I keep getting these weird tomcat errors on shutdown on a newly
built system using tomcat 7.0.57 on a windows 2012 server with
jdk 1.7 that I can't figure out. This is the catalina log: Feb
12, 2015 8:54:31 AM
org.apache.catalina.loader.WebappClassLoader
clearReferencesJdbc SEVERE: The web application [/identityiq]
registered the JDBC driver
[com.microsoft.sqlserver.jdbc.SQLServerDriver] but failed to
unregister it when the web application was stopped. To prevent
a memory leak, the JDBC Driver has been forcibly unregistered.
Feb 12, 2015 8:54:31 AM
org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads SEVERE: The web application
[/identityiq] appears to have started a thread named [Thread-3]
but has failed to stop it. This is very likely to create a
memory leak.
I ran into this a while back, and it means exactly what it
says: the db driver is being registered (loaded), but not
being unloaded. I fixed it by putting the db driver unload
commands in a contextDestroyed method.
David
I have the same issue as Kevin. What unload commands code did
you call in the contextDestroyed method? Are those methods
universal? The reason I ask is because we use different ODBC
drivers for different environments.
I call this code from my .contextDestroyed method (I didn't write
it, I copied it from somewhere on the web):
public static void unRegisterDrivers() { try { for (
EnumerationDriver drivers = DriverManager.getDrivers();
drivers.hasMoreElements(); ) { DriverManager.deregisterDriver(
drivers.nextElement() ); } } catch ( Exception e ) { /* log the
exception */ } }
This is likely to over-reach in many scenarios. YMMV.
Also, Tomcat already de-registers drivers for you. So, this probably
isn't really changing anything.
We manage the pooling in our application, and don't use any of TC's
connection pooling. This is largely because several years ago (long
enough ago that the then-current version of TC was 5.5.25) the app was
moved from another servlet container that either didn't have pooling, or
it was harder to use than it was to write out own. I wasn't in on the
initial development, but did the port to TC. And at the time I did the
port, I had no idea about TC's connection pooling, so continued with our
own pooling implementation.
Until I did this, I could not get rid of the memory leak warnings. If
there is another way, I couldn't find it at the time I was messing with
it...
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] FileNotFoundException for existing JAR files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Alexander, On 2/12/15 2:26 PM, Alexander Johnson wrote: It looks like that's true. It turns out this wasn't a permissions issue at all. For some reason copying the JAR files out of the directory and back into it caused them to be picked up (I read this in a suggestion somewhere). Reading the 'man' entry for cp I see that it doesn't preserve Access Control Lists (ACLs) and Extended Attributes (EAs), including resource forks unless the -p flag is set (this is on by default when using mv). My guess is that removing this access control information somehow made the files accessible to the tomcat7-maven-plugin. It seems a little sketchy that I don't really know the root cause of the problem, but I'm happy that it's now fixed. Aah, yes: the ACL. That's one of those super-fun *NIX-isms that can ruin your day. $ ls -l - -rwxrwxrwx chris chris 100 a_file $ cat a_file cat: a_file: Permission denied *grumble* The best part is that 'ls' doesn't show you there is a problem, at least not directly. Everyone always forgets about the other commands. This happens to me occasionally on Mac OS which has its own fun set of extended file attributes. I sometimes have files for which I have write privileges, and dir-write privs, but I still can't delete them. Why? Oh, because they have extended attributes, flags, *and* ACLs. Fun stuff. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJU3ipsAAoJEBzwKT+lPKRYyegQAMin4Iz8yXNPASkQGOupezeu vnkRUXENAmF/Fi+1oSQC7JtkRhVl6sxOgCopxAjXDlYDyQ+oNb87HcIEXianVlMJ +t6v9h0+FEaB+sNEqzG0kM3T+vuQoMN+Rc56+SkS2DV+HHJPC06Dwqtk6rjdoIFO bSeARnHR84+jcNMV9gYw/VdFicwAGkNiJw85BsQHwiCueRSpv7DW9LwD1xN5gQxn Wfg1xZlIan4d/5ZvNWOVVORn0bzWMNAHp37LaTo2tHv2nM8r6IrH2utJ9u1o7chT HPO2m5TFSqIf9/LRSUqJycRBL4enwz+gw4hQglKMwTEOF8ev7VIRz0A900UJbz1d dE1prNyHPpcjDsAoAbmaf5M0zVd/OjT2g3EZrrmJcSPzyfHKPOQGbjtWdx6E6i+I 20j0tntMjroy9PuavAJ7yQ50DlXImeL72fBBoKv11oAP0d4rkHmnTuPgmAeYkKI3 1dRcD3nWm6oaVHNwPwTs8xdMrApFgJXOOynM/ciNTOsyRv++V+m5vUm07AmUGZ7D SPAJBkGozMg930GUoponzI7WGRqn1JLIj9U48FUUbIhQucxNwyVG9byS1ndk9D5c Ft7m90YzwZ2kuEIOmJpfg8JJJlC0xp69kKNqkkud75S+iwceqQ2a8JpGuituwknO WIkeJBzwyakgWJMt51ej =7so9 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat severe error when shutting down service but startup is clean
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
David,
On 2/12/15 12:59 PM, David kerber wrote:
On 2/12/2015 12:48 PM, Cris Berneburg - US wrote:
-Original Message- From: David kerber
[mailto:dcker...@verizon.net] Sent: Thursday, February 12, 2015
9:40 AM To: Tomcat Users List Subject: Re: tomcat severe error
when shutting down service but startup is clean
On 2/12/2015 9:06 AM, Wirth, Kevin wrote:
I keep getting these weird tomcat errors on shutdown on a newly
built system using tomcat 7.0.57 on a windows 2012 server with
jdk 1.7 that I can't figure out. This is the catalina log: Feb
12, 2015 8:54:31 AM
org.apache.catalina.loader.WebappClassLoader
clearReferencesJdbc SEVERE: The web application [/identityiq]
registered the JDBC driver
[com.microsoft.sqlserver.jdbc.SQLServerDriver] but failed to
unregister it when the web application was stopped. To prevent
a memory leak, the JDBC Driver has been forcibly unregistered.
Feb 12, 2015 8:54:31 AM
org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads SEVERE: The web application
[/identityiq] appears to have started a thread named [Thread-3]
but has failed to stop it. This is very likely to create a
memory leak.
I ran into this a while back, and it means exactly what it
says: the db driver is being registered (loaded), but not
being unloaded. I fixed it by putting the db driver unload
commands in a contextDestroyed method.
David
I have the same issue as Kevin. What unload commands code did
you call in the contextDestroyed method? Are those methods
universal? The reason I ask is because we use different ODBC
drivers for different environments.
I call this code from my .contextDestroyed method (I didn't write
it, I copied it from somewhere on the web):
public static void unRegisterDrivers() { try { for (
EnumerationDriver drivers = DriverManager.getDrivers();
drivers.hasMoreElements(); ) { DriverManager.deregisterDriver(
drivers.nextElement() ); } } catch ( Exception e ) { /* log the
exception */ } }
This is likely to over-reach in many scenarios. YMMV.
Also, Tomcat already de-registers drivers for you. So, this probably
isn't really changing anything.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJU3iUdAAoJEBzwKT+lPKRYjEAQAI2iNwQnzT4Rqv6qHswFPLE2
9S/Sb8JgM5ugN+FOkFu8jNllqvZA0wsqYY35a7JpKjKg8cVQcE9LF+gQrH4QJkhA
zdMK07pc756Q5XdxuMqIVwPy0TmQMKXDD2I/hAuWj1MTcyX57zaValTvdp29fOXm
NPiZe0LSd0unttawwFe5kbpF50pYlDWWVoBqyzRw9pCiAwC2z7mqG5Ytt9OXv4gR
p/l1Gu7sKdH6IDg7gcFCYh7qG9MzUz3kYc/5OSP+5nHTpRkJ7+d1/TKyYxF7EDmp
0stc0Q02O0/QoK9XZ5lfrgw1Bv7KXoiUaE5hbhtUj/3qV1PHjgGVaDOiCGXXSEiH
tp2gM3ex4Iz5qJcX0Jjr8WNuVSJb39Tvn1gtpuzui+EU95gnmfp2WFRBYw2V7SUM
SdyhPp/wvhd2hYYc9THOudFHkzzTBrdX8RqC/zHPWQPpctXSnntKxaczJWFl9Tcl
50AoSwxlLAEZ9S+phlyJuzlHU6mWOfz0LEJJinwBV/1a2pDAngFhuI/g0DQkyGi6
bz2oGfnev8/+NAiCFse7EzWvtc9U5F6RuXdxU0l66szw9Qu8htXMxQj4AfRnotPi
OFZunL0hSxTL5huR8LPfItjagfqqm3Ik/t7c8QdG2S2v4gw5CXgmWNWDr7abhvPj
o2ImiINb+5OBKDou78Nh
=IKCS
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: WorkManager replacement
We use quartz already for scheduled tasks but the work that I'm talking about doesn't necessarily happen on a timer. The main use for us is the asynchronous execution of work once we've figured out which node in our cluster should handle it. I'm still going to consider java.util.concurrent since we use it elsewhere but I'm also going to look more into Spring. Thanks for your help, Kevin. On 13 February 2015 at 09:32, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dan, On 2/13/15 7:29 AM, Daniel Mikusa wrote: On Thu, Feb 12, 2015 at 11:59 PM, Kevin Hale Boyes kcbo...@gmail.com wrote: I currently have an application running on weblogic that I'm moving over to tomcat 8. One of the things the application does is run background jobs using the commonj WorkManager. These jobs are managed by weblogic which seems to be the recommended practice. What is the best/recommended way to run background jobs in Tomcat 8? Personally I'd use Spring, which has a nice and simple way to schedule tasks. I'd also be using Spring for other things though and I'm not sure I'd pull it in just for scheduled tasks. A quick google search came up with this library. http://commonj.myfoo.de/ Haven't personally used it though. I suppose another option would be to just use java.util.concurrent. That amounts to rolling-your-own. If you just need to do something on a rough schedule, then java.util.concurrent is fine: start a thread that does something every 10 minutes or whatever. If you want real scheduling, you want something like Quartz: http://quartz-scheduler.org/ I would argue that there are better solutions than using Quartz from within your own web application, but it depends upon your perspective. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJU3icEAAoJEBzwKT+lPKRY9bIP/ilEoImpKncX82WU+SqgQQgP zUhUTP0x+bntXNpouuxbb1NOhHKH6d7l0p2WKkQRoKf2qxJzxYhEnAiBELCI7CQF 02OrXnzl4VmatgVgd5Aom/7QIzhLArLKNosGwIS8d/BbssPcZS6plBTU70VS8C7D I+QON7RW3veJG9SFFA5sKrGhlgFuDUTbrLcz/oZeZ2xdbg4s2htAH9B+XNz5Gbvv NKESUASPTGzYCSwZhgwIVoxZZavdkCwVvSJIEyPDlGwMDrBkYdSg/GbctyHA8Mny METMmlN9Q29mEc6/VNSv6B+XtqUWCPud0WAPZm6rIso7NaV/ScY+/L19lzvLOn1a SvwYavQ8bdGWb+w5xIcnsnZkLknwaDJoYMerquwnCxsPqaAdBygdku8OuvA8PxT4 eIlUCOoT5GjxWTEX+HIWBvyx2KXTM8EScYdyXCuGtxnKcpexYaXBJQ2GhNc4EHym T3JiLu/fAIu4TWyI6oM64YLMfJfNk49gNtPCjWfRluG4qqKQ3YqjQubf8FIe/vOe y1wXzC/7KtV1urLDL74mLTjGpihiig3e9CRa7MWK354K/WoSlgbkze/Ac1df40g+ Zq1MpgnGQmjgvG16FGujeL5U+QlwFTXYNAqXKsP0++FJJ9DEhkQM8c0yYlDplOYZ xFKob5fnVsgVj1flZH4N =aLoS -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does 'absolute-ordering' in web.xml without 'others' kill classpath scanning?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ryan, On 2/13/15 12:59 PM, Ryan Scharer wrote: I'm not sure if this is a bug or not, but I can't find any relevant information in the spec to suggest the behavior is expected. There's a web-fragment in my classpath that I'd like to skip. The only way to accomplish this that I know of is to put an absolute-ordering stanza in my web.xml and omit an others/. Though this has the desired effect of skipping the web-fragment I don't want, it has the very negative side effect that my ServletContainerInitializer doesn't get handed all instances of WebApplicationInitializer anymore, despite its @HandlesTypes annotation. If I add the others/, classpath scanning works fine, but the undesired web-fragment comes back. I've tested this in the latest 7.x and 8.x Tomcat releases. This begs two questions: 1. Why does specifying an absolute-ordering without an others/ kill classpath scanning, or at least the part of Tomcat responsible for finding types specified by @HandlesTypes and giving it to interested parties? 2. Is there an alternate way to skip a web-fragment, short of ripping it out of the jar, which I really don't want to do? It's unclear to me why absolute-ordering affects JAR scanning... absolute-ordering should affect only the processing of web-fragments. The Tomcat documentation for absolute-ordering makes it sounds like you have to mention a JAR name while the spec documentation makes it seem like you need to use the name element from web-fragments that are detected in JAR files. The whole thing is a can of worms, honestly. As for your inability to skip a web-fragment... that seems straightforward to me: if you have others/ specified, then everything else will be processed in that order, including the web-fragment you don't want. There does not seem to be a way to blacklist a web-fragment short of completely removing it from your project's libraries. But the fact that the lack of others causes Tomcat to fail to do JAR scanning is surprising to me. I tend to prefer explicit configuration over all this scanning-related magic so I'm afraid I don't have any experience with this kind of thing. In fact, it's this kind of foolishness that makes me stick with explicitly-specified configurations instead of magic ones. Good luck figuring out how the magic works / is supposed to work! - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJU3j/eAAoJEBzwKT+lPKRYRa8P/0sf9hPQmY5Ivd4lQ5jJGzJy 6u/mdQbNclsbMBFBGDReq0VJFTsKCqd857VpaxIdQmbCeHLc94+zDvGHYNpHddAw MjztFPIXkrLqahc1dWwztMQWQGFrOcFM5KmUeGWbZynHUirJknOlc/gx9xQbD61O a46h6iL1Dn3okBnGBIbmuWVmg1dyC2Pvg+qLgO4etfIaeuvSds2XXW6OgmnyWmM5 neBRnnruFixDtz5xmiBArbRgqnVa59xVnUkvKfUPqtI3MQWq9X8a5/f5rXgfohMd BpgV/yPf6gm9fuFPVPSPLJof0UvenxeYiGMW+1BjIpi3Qt5Me4Ba8CYrmFXf2r2d g5flulx8k+9uZvLlE9vW8xKe+S4OK8vUif5PTcUv7oMTT3ASo1uvMb3Z0/WxNHvu NW/9eGIgGshOENfHu59+bBsPQhu/dsNdvwrdGXYlELjx3X64pCYLkdQr5ZTNBZar UOiIiLpUNgeUC0L10XC205e116G1P3ofVQqo5PZiFntu8sF9AUp+YL/6I3OQ6Q8B wDej78On3ZDmkJAkKZKgVaeAOXY64FF2B5T6QayPABJ/z+LU/DLP8zySLXY9o6I1 FGZoweHmM0cWX3VpuyN167Hd5PEJyjlMpy6NZ+qMbWf3LnQvrrx15vpgd6cypm7B 5Uolv99PqOrAJOE+F/NV =sw5S -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does 'absolute-ordering' in web.xml without 'others' kill classpath scanning?
Chris, I share your misgivings about magic, though if it exhibits well-documented and predictable behavior I usually just shrug and go along with it. Sadly that doesn't seem to be the case here. I'll set aside some time to step through the Tomcat code to try to figure this out, though in the meantime my best bet may be to repackage the 3rd party jar minus its web-fragment. -R On Fri, Feb 13, 2015 at 1:18 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ryan, On 2/13/15 12:59 PM, Ryan Scharer wrote: I'm not sure if this is a bug or not, but I can't find any relevant information in the spec to suggest the behavior is expected. There's a web-fragment in my classpath that I'd like to skip. The only way to accomplish this that I know of is to put an absolute-ordering stanza in my web.xml and omit an others/. Though this has the desired effect of skipping the web-fragment I don't want, it has the very negative side effect that my ServletContainerInitializer doesn't get handed all instances of WebApplicationInitializer anymore, despite its @HandlesTypes annotation. If I add the others/, classpath scanning works fine, but the undesired web-fragment comes back. I've tested this in the latest 7.x and 8.x Tomcat releases. This begs two questions: 1. Why does specifying an absolute-ordering without an others/ kill classpath scanning, or at least the part of Tomcat responsible for finding types specified by @HandlesTypes and giving it to interested parties? 2. Is there an alternate way to skip a web-fragment, short of ripping it out of the jar, which I really don't want to do? It's unclear to me why absolute-ordering affects JAR scanning... absolute-ordering should affect only the processing of web-fragments. The Tomcat documentation for absolute-ordering makes it sounds like you have to mention a JAR name while the spec documentation makes it seem like you need to use the name element from web-fragments that are detected in JAR files. The whole thing is a can of worms, honestly. As for your inability to skip a web-fragment... that seems straightforward to me: if you have others/ specified, then everything else will be processed in that order, including the web-fragment you don't want. There does not seem to be a way to blacklist a web-fragment short of completely removing it from your project's libraries. But the fact that the lack of others causes Tomcat to fail to do JAR scanning is surprising to me. I tend to prefer explicit configuration over all this scanning-related magic so I'm afraid I don't have any experience with this kind of thing. In fact, it's this kind of foolishness that makes me stick with explicitly-specified configurations instead of magic ones. Good luck figuring out how the magic works / is supposed to work! - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJU3j/eAAoJEBzwKT+lPKRYRa8P/0sf9hPQmY5Ivd4lQ5jJGzJy 6u/mdQbNclsbMBFBGDReq0VJFTsKCqd857VpaxIdQmbCeHLc94+zDvGHYNpHddAw MjztFPIXkrLqahc1dWwztMQWQGFrOcFM5KmUeGWbZynHUirJknOlc/gx9xQbD61O a46h6iL1Dn3okBnGBIbmuWVmg1dyC2Pvg+qLgO4etfIaeuvSds2XXW6OgmnyWmM5 neBRnnruFixDtz5xmiBArbRgqnVa59xVnUkvKfUPqtI3MQWq9X8a5/f5rXgfohMd BpgV/yPf6gm9fuFPVPSPLJof0UvenxeYiGMW+1BjIpi3Qt5Me4Ba8CYrmFXf2r2d g5flulx8k+9uZvLlE9vW8xKe+S4OK8vUif5PTcUv7oMTT3ASo1uvMb3Z0/WxNHvu NW/9eGIgGshOENfHu59+bBsPQhu/dsNdvwrdGXYlELjx3X64pCYLkdQr5ZTNBZar UOiIiLpUNgeUC0L10XC205e116G1P3ofVQqo5PZiFntu8sF9AUp+YL/6I3OQ6Q8B wDej78On3ZDmkJAkKZKgVaeAOXY64FF2B5T6QayPABJ/z+LU/DLP8zySLXY9o6I1 FGZoweHmM0cWX3VpuyN167Hd5PEJyjlMpy6NZ+qMbWf3LnQvrrx15vpgd6cypm7B 5Uolv99PqOrAJOE+F/NV =sw5S -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: To log TLS sessions !
Thanks Chris. Any other thoughts? On Fri, Feb 13, 2015 at 10:03 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Utkarsh, On 2/13/15 12:39 AM, Utkarsh Dave wrote: Need your thoughts and comments on the requirement where we need to log/capture information when TLS sessions are setup, the logs will be logged to indicate successful or failed connection establishment or even connection being disconnected. RequestDumperFilter is one way but that will dump each and every requests and response in detail My first thought would be to see how the RequestDumperFilter does it, and then only use that part of the code. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJU3idTAAoJEBzwKT+lPKRYvmcP/1rZ+DuMyTFq9rxyxYcVlH9I s2gcCjSP4vXWEmwV6mTeVP6kD1v2ld8/ZsMcCI9kHPiT9XIFe8w4o9HJQ4vYsu1D hwzNdIhSvYmQzijcUnDxy4M7bG43SRDrEoWLCgcbKx9SBCy5pnoh7fZ5Ubafmv3Z 1eQ6LNha5bY+8CH7Vodkt9ISYZeBUnnWz6TpPlD/wLEst/tF4MyBCyEuqxxJXDMn 9K8OPhnkoXGk2P4Q4dtl+f8CTKWXaWAVA4kynz75zhmaFy68B73bjI+VKubJUnrc 65xsijSVE32ZtFoBxa9I/nw6NwjcvFfjNNvfq/OEZtDEwS7ji88p/J2VFJ3GzI7o isYIuDHftiTeNjS0Q4eZ7EN9YtuuHn+a3tBzZhg6duBERu0aywjK0PEkbPWJP8BX 9fIx75Rqy7iBFcD5rmnmDgRah+R9kqvnAWpYdJWL+CB2kq6mo+0HZT/NQMSZ0PHa BTUIyJGac6DzToeyJ4HjFa8GPGAN68gJsVNX6NM+KUxVNSb6XaMTCTVxWic16QD0 W5FDoEXU7MTEaVN8jUE58VJPIBrXMVbIO5dGuPrjNFqmGteClVN17ULRlGTx+2ru k58MCN0uCRxlCfGQTky3BbcgwAACVpgWNx1dd7N9mfdbGnv92FDX/sU/V0DTeNqF gHGXzkIPn8vfxyJFFAPr =gnmt -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] FileNotFoundException for existing JAR files
On Fri, Feb 13, 2015 at 11:46:37AM -0500, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Alexander, On 2/12/15 2:26 PM, Alexander Johnson wrote: It looks like that's true. It turns out this wasn't a permissions issue at all. For some reason copying the JAR files out of the directory and back into it caused them to be picked up (I read this in a suggestion somewhere). Reading the 'man' entry for cp I see that it doesn't preserve Access Control Lists (ACLs) and Extended Attributes (EAs), including resource forks unless the -p flag is set (this is on by default when using mv). My guess is that removing this access control information somehow made the files accessible to the tomcat7-maven-plugin. It seems a little sketchy that I don't really know the root cause of the problem, but I'm happy that it's now fixed. Aah, yes: the ACL. That's one of those super-fun *NIX-isms that can ruin your day. $ ls -l - -rwxrwxrwx chris chris 100 a_file $ cat a_file cat: a_file: Permission denied *grumble* The best part is that 'ls' doesn't show you there is a problem, at least not directly. Everyone always forgets about the other commands. The 'ls' that comes as part of Gnu Coreutils will, when built that way, add a + to the mask to show that there is an ACL on the object. (But that's all it does -- I still have to remember to use 'getfacl' to see what the ACL actually *says*.) -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu signature.asc Description: Digital signature
Why does 'absolute-ordering' in web.xml without 'others' kill classpath scanning?
Hey folks, I'm not sure if this is a bug or not, but I can't find any relevant information in the spec to suggest the behavior is expected. There's a web-fragment in my classpath that I'd like to skip. The only way to accomplish this that I know of is to put an absolute-ordering stanza in my web.xml and omit an others/. Though this has the desired effect of skipping the web-fragment I don't want, it has the very negative side effect that my ServletContainerInitializer doesn't get handed all instances of WebApplicationInitializer anymore, despite its @HandlesTypes annotation. If I add the others/, classpath scanning works fine, but the undesired web-fragment comes back. I've tested this in the latest 7.x and 8.x Tomcat releases. This begs two questions: 1. Why does specifying an absolute-ordering without an others/ kill classpath scanning, or at least the part of Tomcat responsible for finding types specified by @HandlesTypes and giving it to interested parties? 2. Is there an alternate way to skip a web-fragment, short of ripping it out of the jar, which I really don't want to do? Thanks! -Ryan
Re: tomcat severe error when shutting down service but startup is clean
On 2/13/2015 11:54 AM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
David,
...
public static void unRegisterDrivers() { try { for (
EnumerationDriver drivers = DriverManager.getDrivers();
drivers.hasMoreElements(); ) { DriverManager.deregisterDriver(
drivers.nextElement() ); } } catch ( Exception e ) { /* log
the exception */ } }
This is likely to over-reach in many scenarios. YMMV.
Also, Tomcat already de-registers drivers for you. So, this
probably isn't really changing anything.
We manage the pooling in our application, and don't use any of
TC's connection pooling. This is largely because several years ago
(long enough ago that the then-current version of TC was 5.5.25)
the app was moved from another servlet container that either didn't
have pooling, or it was harder to use than it was to write out own.
I wasn't in on the initial development, but did the port to TC.
And at the time I did the port, I had no idea about TC's connection
pooling, so continued with our own pooling implementation.
Until I did this, I could not get rid of the memory leak warnings.
If there is another way, I couldn't find it at the time I was
messing with it...
I'm not sure at what point Tomcat started de-registering drivers. When
it de-registers a driver, it gives you a warning. By you doing it
yourself, you are avoiding the warning, of course.
But if you de-register all drivers, you are also de-registering any
drivers that were registered by different web applications, Tomcat's
connection-pool, etc. It would be better to only de-register the
driver(s) you actually registered in the first place.
I haven't researched such things, but a reasonable way might be to do
something like this:
ClassLoader cl = Thread.currentThread().getContextClassLoader();
for(Driver driver : DriverManager.getDrivers())
if(cl.equals(driver.getClass().getClassLoader()))
DriverManager.deregisterDriver(driver);
This way, you only remove drivers you load yourself. Alternatively,
you probably already know which drivers you have explicitly loaded, so
you could explicitly unload them instead of flushing the whole
DriverManager.
Note: I have no idea if Driver objects get the proper ClassLoader
assigned, but it's worth a try to get a bit more safety.
If your web application is the only one loaded, feel free to wipe-out
the DriverManager like that. But, if you need to operate in a shared
environment, your technique above might negatively impact other code
that relies on its driver not being forcibly un-loaded out from under it.
Thanks for the suggestions, Chris! The way we operate our environment
currently there's no danger of killing another app, but I'll look into
your suggestion for future reference. I'm always open to suggestions on
ways to improve my coding.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: To log TLS sessions !
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Utkarsh, On 2/13/15 12:25 PM, Utkarsh Dave wrote: Thanks Chris. Any other thoughts? Well, what you want is at a pretty low level. If you are using a JSSE connector, you'll never see failed TLS handshakes. I'm not sure what options are available for failed connection attempts if you are using the APR (native) connector. If you want TLS information from /successful/ attempts, it's easy for you to grab that from any Filter, Servlet, etc. If you want the best information available, I think you want to attach a protocol tracer to the server and watch that traffic. That way, you'll see the full TLS handshake and you can log whatever you want. - -chris On Fri, Feb 13, 2015 at 10:03 PM, Christopher Schultz ch...@christopherschultz.net wrote: Utkarsh, On 2/13/15 12:39 AM, Utkarsh Dave wrote: Need your thoughts and comments on the requirement where we need to log/capture information when TLS sessions are setup, the logs will be logged to indicate successful or failed connection establishment or even connection being disconnected. RequestDumperFilter is one way but that will dump each and every requests and response in detail My first thought would be to see how the RequestDumperFilter does it, and then only use that part of the code. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJU3jz8AAoJEBzwKT+lPKRYqysP/j1JsV4KyHrNP+91qx8PDPjF h+OvWwQsSjFgIAVgkc/uMXHOZWCcgZNBgLu6DIOs2rVdGr6BUYdrmuR9/Xa75NSG n+42BvvrwMMoxRH0/sV+Zt30Ge34iYYAlT5YMzA6V26jdUEqVHT/WIlv89WIHFPW Mhi9Wl4ZBdxQnN+1rbLVky+Cjhh3mbJtOonMnXrHctv6ILuu1EaO7gt4USgZ/Gsu TkHxsYgVy652aMwjT4Ihg/tr28g70DnscYbWVzVJqLLQtXhVSaPY015f65TStptv Q7DSkDtW6OtkF/0Eae/FKqxhOjNSM4JSq86Rpc/ahTq45dEQJLlucFK9IsXdh1MA JS2/xvKgJwBa5Ugo1ciC4S2qaldARuOu9j8MCQxxzfveMXuDCYGn7Lw2rqdYCrTI OjCAdDe7GNXq/ypsOtT5M2v7QXAj7RrpIsYg358D4IAj2H5rEPdnT6odldpf+q4O Ov6j2/my1DdB8Mi3u2A+zzMcPFW5jUqC2XvaZDCnhdHS+MvoW4u1Q3HSWNS0Jp4i rEJ2J3FNCWJZ+eEq7f/V4NKwtbcfH/w7Y0WmxeTSQtbzPklBnwK6Ya+EbnZeZs7k xjAY3N9ymNMYco61BdaUjNGHM3JLghmcP8+mQMd+Lz/SsfDIBco2VKA3yjOnEgR5 CbB84/hl8t5NPiXMqGO1 =NTTc -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: tomcat severe error when shutting down service but startup is clean
-Original Message-
From: David kerber [mailto:dcker...@verizon.net]
Sent: Thursday, February 12, 2015 9:40 AM
To: Tomcat Users List
Subject: Re: tomcat severe error when shutting down service but
startup is clean
On 2/12/2015 9:06 AM, Wirth, Kevin wrote:
I keep getting these weird tomcat errors on shutdown on a newly built system
using tomcat 7.0.57 on a windows 2012 server with jdk 1.7 that I can't
figure out. This is the catalina log:
Feb 12, 2015 8:54:31 AM org.apache.catalina.loader.WebappClassLoader
clearReferencesJdbc
SEVERE: The web application [/identityiq] registered the JDBC driver
[com.microsoft.sqlserver.jdbc.SQLServerDriver] but failed to unregister it
when the web application was stopped. To prevent a memory leak, the JDBC
Driver has been forcibly unregistered.
Feb 12, 2015 8:54:31 AM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: The web application [/identityiq] appears to have started a thread
named [Thread-3] but has failed to stop it. This is very likely to create a
memory leak.
DK I ran into this a while back, and it means exactly what it says: the db
driver is being registered (loaded), but not being unloaded. I fixed it by
putting the db driver unload commands in a contextDestroyed method.
cb David
cb
cb I have the same issue as Kevin. What unload commands code did you call
in the contextDestroyed method? Are those methods universal? The reason I
ask is because we use different ODBC drivers for different environments.
DK I call this code from my .contextDestroyed method (I didn't write it, I
copied it from somewhere on the web):
DK public static void unRegisterDrivers() {
DK try {
DKfor ( EnumerationDriver drivers = DriverManager.getDrivers();
DK drivers.hasMoreElements(); ) {
DK DriverManager.deregisterDriver( drivers.nextElement() );
DK}
DK } catch ( Exception e ) {
DK/* log the exception */
DK }
DK }
Thanks David! That solved this error message:
message
org.apache.catalina.loader.WebappClassLoader clearReferencesJdbc
SEVERE: The web application [/irma] registered the JDBC driver
[com.microsoft.sqlserver.jdbc.SQLServerDriver] but failed to unregister it when
the web application
was stopped. To prevent a memory leak, the JDBC Driver has been forcibly
unregistered.
/message
However, the one below still occurs, which I don't understand. Is it saying
that an instance of an object was created outside of java garbage collection
control that is not being released?
message
org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks
SEVERE: The web application [/irma] created a ThreadLocal with key of type
[com.microsoft.sqlserver.jdbc.ActivityCorrelator$1] (value
[com.microsoft.sqlserver.jdbc.ActivityCorrelator$1@dc160cb])
and a value of type [com.microsoft.sqlserver.jdbc.ActivityId] (value
[de6bd261-6408-4336-86e2-375848be61b5-5])
but failed to remove it when the web application was stopped. This is very
likely to create a memory leak.
/message
In the contextDestroyed listener method I added
[System.out.println(String.valueOf(driver));] to try to get more info, but I'm
not sure it provided anything meaningful:
log
sun.jdbc.odbc.JdbcOdbcDriver@49f4bcf7
SQLServerDriver:1
/log
The jdbc driver I am using is in the folder identityiq under the webapps
directory in tomcat. It is the sqljdbc4.jar driver. This driver is not in
the tomcat\lib directory. Please help because I am getting no help from the
vender. Thank you.
Kevin Wirth
[...]
--
Cris Berneburg, Lead Software Engineer
CACI, IRMA Project, 703-679-5313
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
singed code deployment
Hi,
I have signed the ear package using jar signer and start the tomee using
./startup.sh -security and also edit the catalina.policy file looks like
below.
I am confused here, how code sign verification process is done? if the code
sign certificate is not the truststore still the tomcat server will start?
or it stops booting the application?
I haven't seen anything in the log related to code sign, how can i verify
this ?
grant signedBy codesigntest, codeBase
file:${catalina.base}/webapps/manager/- {
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.ha.session;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.manager;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.manager.util;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.util;
};
grant signedBy codesigntest, codeBase
file:${catalina.home}/webapps/manager/- {
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.ha.session;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.manager;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.manager.util;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.util;
};
grant signedBy codesigntest, codeBase
file:${catalina.home}/apps/ams_ear/ams_ear.ear {
permission java.security.AllPermission;
};
grant signedBy codesigntest, codeBase
file:${catalina.home}/apps/ams_ear/* {
permission java.security.AllPermission;
};
Regards,
Sanaullah
Re: [OT] FileNotFoundException for existing JAR files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 2/13/15 1:02 PM, Mark H. Wood wrote: On Fri, Feb 13, 2015 at 11:46:37AM -0500, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Alexander, On 2/12/15 2:26 PM, Alexander Johnson wrote: It looks like that's true. It turns out this wasn't a permissions issue at all. For some reason copying the JAR files out of the directory and back into it caused them to be picked up (I read this in a suggestion somewhere). Reading the 'man' entry for cp I see that it doesn't preserve Access Control Lists (ACLs) and Extended Attributes (EAs), including resource forks unless the -p flag is set (this is on by default when using mv). My guess is that removing this access control information somehow made the files accessible to the tomcat7-maven-plugin. It seems a little sketchy that I don't really know the root cause of the problem, but I'm happy that it's now fixed. Aah, yes: the ACL. That's one of those super-fun *NIX-isms that can ruin your day. $ ls -l - -rwxrwxrwx chris chris 100 a_file $ cat a_file cat: a_file: Permission denied *grumble* The best part is that 'ls' doesn't show you there is a problem, at least not directly. Everyone always forgets about the other commands. The 'ls' that comes as part of Gnu Coreutils will, when built that way, add a + to the mask to show that there is an ACL on the object. (But that's all it does -- I still have to remember to use 'getfacl' to see what the ACL actually *says*.) Yep. - From Alexander's previous message, it did not seem like 'ls' was notifying him about the presence of the acl. I checked the gnu-coreutils man pages and info pages, and neither mention ACLs. Can you give me a reference for the + thing? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJU3kCZAAoJEBzwKT+lPKRYLN0QAJGG8VCnEK/uUQ/be965xT0e gwNKFdAc0+f18a2Cod2Qa5pzUel4n2J/GRdMztx2UrkUH5sJXsU8dkS29Zwp/a8I 53wpV+vSUFtIXku9I/S7qctibxkimF7D5SIIVkSQe8XH67mnlBUIBBgHB1/ZxaKd F4WuWiSBmjuFE1nmPtTbmO+d2z7PvSnceN0TLbrxMQnk+n53HkrNXCHioMFUG4FE uHYF4snDXEALogaIcuDdROEabkaQOy3GFkkShM34sbyScIi9OnvczdebUqtlXrkE pVMg1YXePmqV2mKzkYztFT17ajwcMYxrhnE16mTuHTXJnok/ANxqzESZKqALQyhO 7Y4ctIG1AGlXlaKwxVRxM1IE35VDlkeVyBigpuaC5JecQ3TV8FXii32FgefFIWoe vl4cT1nbLeLr6FOx1J/d7sYu9ky2XAaiEcosPh8Vz+rPrRLPHsLcpnVlddDz02Tc XVfAVGD64UXJJweX2PfYu0coJqJjY54p1r+GZAYFRhWlqbzrFU95SlrS0hBhaq7F V0/7Wz9TpvGJ31HNXqo+kjeVWPaJjUSdkguGGNUxFW4SNdZhp0RId3DD+WgNGWMA Fhtbm1KUcOEt8+fNr/mCb4d+23DKBo/SK8Xc7sh2WTE9KV1G3eZCHGNSk+9ZNn1r e9vpA57ED0vmz/gKkoE+ =rFEN -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: WorkManager replacement
Spring is starting to appear to be the best choice. Thanks for the reference. On 13 February 2015 at 08:04, Daniel Mikusa dmik...@pivotal.io wrote: On Fri, Feb 13, 2015 at 9:49 AM, Kevin Hale Boyes kcbo...@gmail.com wrote: We already use Spring in the project so I'll have a look there. http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#scheduling Dan Thanks On 13 February 2015 at 05:29, Daniel Mikusa dmik...@pivotal.io wrote: On Thu, Feb 12, 2015 at 11:59 PM, Kevin Hale Boyes kcbo...@gmail.com wrote: I currently have an application running on weblogic that I'm moving over to tomcat 8. One of the things the application does is run background jobs using the commonj WorkManager. These jobs are managed by weblogic which seems to be the recommended practice. What is the best/recommended way to run background jobs in Tomcat 8? Personally I'd use Spring, which has a nice and simple way to schedule tasks. I'd also be using Spring for other things though and I'm not sure I'd pull it in just for scheduled tasks. A quick google search came up with this library. http://commonj.myfoo.de/ Haven't personally used it though. I suppose another option would be to just use java.util.concurrent. Dan Thanks, Kevin
Re: WorkManager replacement
On 2/13/2015 8:52 AM, Kevin Hale Boyes wrote:
I'll look into the timers for sure.
I've also noticed that my application (lots of code) also uses Executors
and ExecutorService so I might do something there.
One of the things that WorkManager gave us, and we take advantage of, is a
callback handler that lets us know when the work was accepted for
processing and when it was complete. I'll have to find replacements for
that feature. Maybe that's easily done with Future's in the concurrency
framework.
Thanks for your help.
Kevin
On 13 February 2015 at 06:15, David kerber dcker...@verizon.net wrote:
On 2/13/2015 7:29 AM, Daniel Mikusa wrote:
On Thu, Feb 12, 2015 at 11:59 PM, Kevin Hale Boyes kcbo...@gmail.com
wrote:
I currently have an application running on weblogic that I'm moving over
to
tomcat 8.
One of the things the application does is run background jobs using the
commonj WorkManager. These jobs are managed by weblogic which seems to
be
the recommended practice.
What is the best/recommended way to run background jobs in Tomcat 8?
Personally I'd use Spring, which has a nice and simple way to schedule
tasks. I'd also be using Spring for other things though and I'm not sure
I'd pull it in just for scheduled tasks.
I use java.util.timer for my scheduled jobs in tomcat.
A quick google search came up with this library.
http://commonj.myfoo.de/
Haven't personally used it though.
I suppose another option would be to just use java.util.concurrent.
Dan
Thanks,
Kevin
I've used something similar to the following in the past:
public class AServletContextListener implements ServletContextListener
{
private ScheduledExecutorService executor;
/**
* Constructs AServletContextListener object.
*/
public AServletContextListener()
{
}
/**
* Invoked when context is initialized.
*
* @paramscetriggering ServletContextEvent
*/
public void contextInitialized( ServletContextEvent sce )
{
if ( executor == null )
{
executor = Executors.newSingleThreadScheduledExecutor();
Calendar firstRunTime = new GregorianCalendar();
firstRunTime.set( Calendar.HOUR_OF_DAY, 12 );
firstRunTime.set( Calendar.MINUTE, 0 );
firstRunTime.set( Calendar.SECOND, 0 );
firstRunTime.set( Calendar.MILLISECOND, 0 );
executor.scheduleAtFixedRate(
new ARunnable(),
firstRunTime.getTimeInMillis() -
System.currentTimeMillis(),
1000 * 60 * 60 * 24,
TimeUnit.MILLISECONDS );
}
}
/**
* Invoked when context is destroyed.
*
* @paramscetriggering ServletContextEvent
*/
public void contextDestroyed( ServletContextEvent sce )
{
if ( executor != null )
{
boolean isTerminated = false;
executor.shutdown();
do
{
try
{
isTerminated = executor.awaitTermination(
1, TimeUnit.SECONDS );
}
catch ( InterruptedException ignore )
{
}
}
while ( !isTerminated );
executor = null;
Thread.yield();
}
}
}
It's simple, not very much code and gets the job done. The call to
Thread.yield was added to eliminate an error message in the Tomcat logs.
-Terence Bandoian
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does 'absolute-ordering' in web.xml without 'others' kill classpath scanning?
On 13/02/2015 17:59, Ryan Scharer wrote: Hey folks, I'm not sure if this is a bug or not, but I can't find any relevant information in the spec to suggest the behavior is expected. There's a web-fragment in my classpath that I'd like to skip. The only way to accomplish this that I know of is to put an absolute-ordering stanza in my web.xml and omit an others/. Though this has the desired effect of skipping the web-fragment I don't want, it has the very negative side effect that my ServletContainerInitializer doesn't get handed all instances of WebApplicationInitializer anymore, despite its @HandlesTypes annotation. If I add the others/, classpath scanning works fine, but the undesired web-fragment comes back. I've tested this in the latest 7.x and 8.x Tomcat releases. This begs two questions: 1. Why does specifying an absolute-ordering without an others/ kill classpath scanning, or at least the part of Tomcat responsible for finding types specified by @HandlesTypes and giving it to interested parties? Because the Servlet spec says so. Servlet 3.1, section 8.2.2, 1. d. (page 8-73) ... Irrespective of the setting of metadata-complete, jars excluded by absolute-ordering elements are not scanned for classes to be handled by any ServletContainerInitializer. 2. Is there an alternate way to skip a web-fragment, short of ripping it out of the jar, which I really don't want to do? There is no way I am aware of that allows you to skip the web-fragment.xml but still scan the JAR for SCIs and @HandlesTypes matches to those SCIs. Depending on what is in the web-frgament.xml you might be able to put entries in the main web.xml to override them. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does 'absolute-ordering' in web.xml without 'others' kill classpath scanning?
On 13/02/2015 18:49, Ryan Scharer wrote: Chris, I share your misgivings about magic, though if it exhibits well-documented and predictable behavior I usually just shrug and go along with it. Sadly that doesn't seem to be the case here. It is documented but I'd agree it could be better documented. I'll set aside some time to step through the Tomcat code to try to figure this out, Save yourself the effort and read this from line ~1085. http://svn.eu.apache.org/viewvc/tomcat/tc8.0.x/trunk/java/org/apache/catalina/startup/ContextConfig.java?view=annotate Mark though in the meantime my best bet may be to repackage the 3rd party jar minus its web-fragment. -R On Fri, Feb 13, 2015 at 1:18 PM, Christopher Schultz ch...@christopherschultz.net wrote: Ryan, On 2/13/15 12:59 PM, Ryan Scharer wrote: I'm not sure if this is a bug or not, but I can't find any relevant information in the spec to suggest the behavior is expected. There's a web-fragment in my classpath that I'd like to skip. The only way to accomplish this that I know of is to put an absolute-ordering stanza in my web.xml and omit an others/. Though this has the desired effect of skipping the web-fragment I don't want, it has the very negative side effect that my ServletContainerInitializer doesn't get handed all instances of WebApplicationInitializer anymore, despite its @HandlesTypes annotation. If I add the others/, classpath scanning works fine, but the undesired web-fragment comes back. I've tested this in the latest 7.x and 8.x Tomcat releases. This begs two questions: 1. Why does specifying an absolute-ordering without an others/ kill classpath scanning, or at least the part of Tomcat responsible for finding types specified by @HandlesTypes and giving it to interested parties? 2. Is there an alternate way to skip a web-fragment, short of ripping it out of the jar, which I really don't want to do? It's unclear to me why absolute-ordering affects JAR scanning... absolute-ordering should affect only the processing of web-fragments. The Tomcat documentation for absolute-ordering makes it sounds like you have to mention a JAR name while the spec documentation makes it seem like you need to use the name element from web-fragments that are detected in JAR files. The whole thing is a can of worms, honestly. As for your inability to skip a web-fragment... that seems straightforward to me: if you have others/ specified, then everything else will be processed in that order, including the web-fragment you don't want. There does not seem to be a way to blacklist a web-fragment short of completely removing it from your project's libraries. But the fact that the lack of others causes Tomcat to fail to do JAR scanning is surprising to me. I tend to prefer explicit configuration over all this scanning-related magic so I'm afraid I don't have any experience with this kind of thing. In fact, it's this kind of foolishness that makes me stick with explicitly-specified configurations instead of magic ones. Good luck figuring out how the magic works / is supposed to work! -chris - 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: tomcat severe error when shutting down service but startup is clean
On 2/13/2015 11:21 AM, David kerber wrote:
On 2/13/2015 11:54 AM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
David,
...
public static void unRegisterDrivers() { try { for (
EnumerationDriver drivers = DriverManager.getDrivers();
drivers.hasMoreElements(); ) { DriverManager.deregisterDriver(
drivers.nextElement() ); } } catch ( Exception e ) { /* log
the exception */ } }
This is likely to over-reach in many scenarios. YMMV.
Also, Tomcat already de-registers drivers for you. So, this
probably isn't really changing anything.
We manage the pooling in our application, and don't use any of
TC's connection pooling. This is largely because several years ago
(long enough ago that the then-current version of TC was 5.5.25)
the app was moved from another servlet container that either didn't
have pooling, or it was harder to use than it was to write out own.
I wasn't in on the initial development, but did the port to TC.
And at the time I did the port, I had no idea about TC's connection
pooling, so continued with our own pooling implementation.
Until I did this, I could not get rid of the memory leak warnings.
If there is another way, I couldn't find it at the time I was
messing with it...
I'm not sure at what point Tomcat started de-registering drivers. When
it de-registers a driver, it gives you a warning. By you doing it
yourself, you are avoiding the warning, of course.
But if you de-register all drivers, you are also de-registering any
drivers that were registered by different web applications, Tomcat's
connection-pool, etc. It would be better to only de-register the
driver(s) you actually registered in the first place.
I haven't researched such things, but a reasonable way might be to do
something like this:
ClassLoader cl = Thread.currentThread().getContextClassLoader();
for(Driver driver : DriverManager.getDrivers())
if(cl.equals(driver.getClass().getClassLoader()))
DriverManager.deregisterDriver(driver);
This way, you only remove drivers you load yourself. Alternatively,
you probably already know which drivers you have explicitly loaded, so
you could explicitly unload them instead of flushing the whole
DriverManager.
Note: I have no idea if Driver objects get the proper ClassLoader
assigned, but it's worth a try to get a bit more safety.
If your web application is the only one loaded, feel free to wipe-out
the DriverManager like that. But, if you need to operate in a shared
environment, your technique above might negatively impact other code
that relies on its driver not being forcibly un-loaded out from under
it.
Thanks for the suggestions, Chris! The way we operate our environment
currently there's no danger of killing another app, but I'll look into
your suggestion for future reference. I'm always open to suggestions
on ways to improve my coding.
Something similar to the following worked for me:
public class DbDriver
{
private static Driver jdbcDriver = null;
protected static void loadDriver()
throws ClassNotFoundException, SQLException
{
if ( jdbcDriver == null )
{
synchronized ( DbDriver.class )
{
if ( jdbcDriver == null )
{
Class.forName( com.mysql.jdbc.Driver );
jdbcDriver = DriverManager.getDriver(
jdbc:mysql://127.0.0.1/ );
}
}
}
}
protected static synchronized void deregisterDriver()
throws SQLException
{
if ( jdbcDriver != null )
{
DriverManager.deregisterDriver( jdbcDriver );
jdbcDriver = null;
}
}
}
-Terence Bandoian
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: WorkManager replacement
On Thu, Feb 12, 2015 at 11:59 PM, Kevin Hale Boyes kcbo...@gmail.com wrote: I currently have an application running on weblogic that I'm moving over to tomcat 8. One of the things the application does is run background jobs using the commonj WorkManager. These jobs are managed by weblogic which seems to be the recommended practice. What is the best/recommended way to run background jobs in Tomcat 8? Personally I'd use Spring, which has a nice and simple way to schedule tasks. I'd also be using Spring for other things though and I'm not sure I'd pull it in just for scheduled tasks. A quick google search came up with this library. http://commonj.myfoo.de/ Haven't personally used it though. I suppose another option would be to just use java.util.concurrent. Dan Thanks, Kevin
