You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2018/04/02 13:25:08 UTC

Re: Getting all JDBC configs from the context

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Shawn,

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
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlrCLzQACgkQHPApP6U8
pFj4XBAAlXRgBZAfELarYHhqRmNOitV+fdHdVdPF8xPcYl2/TkOsi7CiN3aQwAFo
tBlxFyleNApjW7wAm7nr9+u13VKxVlWwRbAKak0exW8xfzkNGRZGDq2aSAxooeMZ
Ckl5HSQ3srpzhkTSBhd44pxbvae5JwlKAvtUqAcFWUbl1byAwe4SsMVcdQEPv6bd
ge5k/wB9TYgcAFgQTVIeGAR2K7HXhM9HFV1QFG/qJL3eul2YvdafMtHU4ly+0AHW
QpBHNv0TQl/MZM1KFoKn5Y1uMKrY1qCZRccQBt5KTto55zHXXZXOiNGXacZ9pEbn
/5KvmAVhKZHjzFSBpS8RtDu04HIFVL0fYA/eySWTdYem2wAtSN23ZfZ9NFRwKYMW
TE0MAOO4naWtE6mGUrgZuGIx4j3HSVHg2lh9k/sZjMM0vpsP43YMXL2aHetUp+Vc
fw7L1t0O0m7Mz0s7ow9EmF5obZf5euaXa2gXJOd4Yy6dd8OTaFqQFK6jVw+R0aq5
OVjAXI/t5uJLu1XRQlNGDxQ9xw+L00j57lpqA8+xjxgVaOtWy5KxyDcfDIwEoNAj
LxZ+fktW6HUBonTYwrIfjBBMO0zaNq/gX821KJS2Z40Ls9j4FLuoezXkVUGkvpqv
2Rr+KXD5aVaY0+fNeVotDgSOIUHcucEYJosnqR60e/3vSKL6Q7Q=
=QRoQ
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org