tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Getting all JDBC configs from the context
Date Mon, 02 Apr 2018 13:25:08 GMT
Hash: SHA256


On 3/30/18 5:30 PM, Shawn Heisey wrote:
> On 3/30/2018 11:38 AM, Christopher Schultz wrote:
>> No. In Java, the "class" is defined by the ClassLoader (which
>> loaded it) plus the fully-qualified class name. It's entirely
>> possible in
> The subtleties of classloader-related problems make my head hurt.
> :)
>> 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.
> I don't know how much I can influence the deployment process, but
> if I see any issues, I will discuss it with development.  Issues
> will probably be apparent pretty quickly, though.  I am generally
> aware that it's a bad idea to have the same jar (especially if
> they're different versions) loaded more than once.
> Would I be right in thinking that subtle problems will either
> cause compile errors or throw ClassCastException, with the latter
> being much more likely?

The biggest risk is trying to build WITH Tomcat libraries and trying
to deploy WITHOUT them. Anyone can toss "catalina" in as a dependency
to their project using Maven but not everyone knows how to tell Maven
that the catalina.jar file shouldn't be bundled with the application.
For example, I have no idea how to do that. Then again, I have no idea
how to use Maven at all.

If you compile against Tomcat and also make sure not to bundle
catalina.jar with your application, then you should be okay. I just
think there are better ways to skin this particular cat.

> I thought I had ensured that if the runflag goes false, the thread 
> should only run for a maximum of one second before it exits.

Sorry, I missed the "runFlag.get()". I ignored it because it's not a
simple flag but an AtomicInteger and got lost in the noise of the code
(in my eyes).

> Is that a case of premature optimization? :)

I'm not sure. In my case, I use a crontab-scheduled line of curl that
logs directly to my monitoring system. No Java code required, no extra
threads, etc. Yes, you have to deploy the Manager application. But
now, I can instrument anything available via JMX just by adding more
lines to my crontab. If you want to check your heap health, or
session-count, or anything like that, you might be tempted to
duplicate your existing code and replace the "logging" with logging
something else. That requires a re-build and redeploy. With JMX, you
just ask for a different address and get different data.

- -chris
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message