-----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

Reply via email to