-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Shawn,
On 3/29/18 3:29 PM, Shawn Heisey wrote: > On 3/29/2018 10:00 AM, Christopher Schultz wrote: >> I don't bother with any of that garbage. I use Tomcat's Manager >> application and the JMXProxyServlet. It's an HTTP-to-JMX bridge, >> so your client just has to speak HTTP. > > I'm not sure that the manager application is active on our > install. No sane production install should have it available unless (a) it's necessary and (b) it's been enabled "with care" (e.g. locked-down). We operate ours in a localhost-only configuration. >> You may also run into ClassLoader problems where BasicDataSource >> (as loaded by your ClassLoader) != BasicDataSource (as >> instantiated by Tomcat). > > Are these problems mitigated by my usage of the fully qualified > class name in the object declaration and the cast? No. In Java, the "class" is defined by the ClassLoader (which loaded it) plus the fully-qualified class name. It's entirely possible in Java to have this: Object a = [something]; Object b = [something]; System.out.println(a.getClass().getName()); System.out.println(b.getClass().getName()); System.out.println(a.getClass().isAssignableFrom(b.getClass())); print this: org.apache.tomcat.dbcp.dbcp.BasicDataSource org.apache.tomcat.dbcp.dbcp.BasicDataSource false If objects a and b were instantiated using different ClassLoaders (which independently loaded the class). This would only happen if you did this: 1. Copy tomcat-dbcp.jar into your app's WEB-INF/lib directory 2. Let Tomcat create the DataSource (loaded from its ClassLoader) 3. Instantiated a new DataSource yourself (loaded from your webapp's ClassLoader) You'd have to take care to build against Tomcat, but deploy without adding Tomcat JARs to your application. > That part of the code actually came from one of our developers ... > I probably would have imported the class and used the bare class > name. The compiled code would be identical in either case. "Imports" are just a shorthand way to tell the compiler what the FQCN is for the classes you actually reference in your code. > Maybe I should use getCanonicalName instead of getName on the > DataSource object. When I can finally run the code for the first > time, I'll have a better idea of whether I need to make any > changes. Using the class's canonical name won't change anything. >> Have a look. It will probably be (slightly) more efficient than >> the code you wrote, and hey, you'll have less code to babysit. It >> also gives you trivial "shutdown" semantics... > > I will do my own searching later, but do you happen to know of some > good documentation that covers the basics of implementing > ExecutorService? I would just search Google for "how to use java executor services" or something similar. >> ServletContextListener is the way to go. In fact, you should >> probably be using a ServletContextListener to *launch* this >> thread in the first place. So, in your init() method, >> create+launch the thread (or ExecutorService), and in the >> destroy() method, shut it all down. > > You may have noticed the new reply where I included a paste for > new code, using ServletContextListener. It's now *complete* code, > instead of a fragment. It's more fleshed-out, but I still think it's more code than necessary. You also have the problem that if you want to shut-down your application, Tomcat will claim you have a memory leak because that thread will continue to run during the 5-minute delay. If you used an ExecutorService (which just runs Runnables), you could instantiate the service and schedule a series of jobs beginning in 5 minutes and executing every 5 minutes after that. On app shutdown, you shut-down the ExecutorService and cancel all fuure jobs immediately, so there is no waiting-around for the thread to stop or anything. (You could also simulate this yourself by adding a check to your 5-minute-loop that also checks to see if "runFlag" has been tripped.) The point is, yes: you can do all of this and it will work. But if you use existing code, you can rely on code that is probably better-written and maintained (no offense intended) and focus your OWN code on what you NEED to get done, instead of mixing it all up with the plumbing of waiting, launching threads, checking for the "done" flag, etc. Hope that helps, - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlq+dgsACgkQHPApP6U8 pFiP8g/7BArFaIXH0tnIOv2b6PVNrWbWw9vaF0YlHe4/DUE6NsPRtkyRY1I/9TuL QULtVRFAPOAzVLQkEIruelNscGnSvXOokEvpkRF1ClekBLB8pr67iCt1SFUTY0ce ANhfSKD0BSRa80P4obrmWTKFVktx3L7Uf1v8Hj1aFa+mLdSNV5B4smwRt+W7k9WK UQb6wt68nhpHQjePksJvh2/w3rc4SKVKyWFVWaWImZ9yJgTXTtTFD5TEcVOGZA6I 1RsO9tvdu3O86tSIwhb1pOvqbMYt8uVjIsDEG24vHXw7dr63TVPW2ByHRBAP8xn6 aggOYLwitx2J+k3Dj03cgMEfajWmuIqiDHcRkk1G2Dc5Zr8CwXqXGZfhzCzY64AI +Uu2zgOAx8QNNcw0RnGKRdLGsuJLPoA1Vd0oc/NRv3qr1W7DJOODbkOFG/XUZwqT UKji+xBORjjbL0uW7lDQ/Bz1YQdSaNZqWZBjyURlK/51aQJBmFAuI+m+W6WoI81A lNVO3L+vvkZD93SCKpHeCn/j+oaap2Faxhhg75g0ZeQ6lnuVKbnn/WDw9h8G/1+c MXqzvgqy2uOvxxxxf7efXYayWtjcMoklUCds+ihrrwq3d3ZQd7GF9BhMwpP3OlzH m2pNObVM4o0SvwU+oSVNN670aUX2dwJTijAfmsM5kDb/2Tot+rg= =6zuk -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org