You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by David kerber <dc...@verizon.net> on 2010/03/10 17:20:08 UTC
Not getting an error that I though I should be getting
As part of my migration from tc 5.5.x to 6.0.x, I'm reviewing my
deployment scripts, and noticed that in one of them, I'm deleting the
jdbc driver jar, jodbc.jar from the WEB-INF/lib folders, because it's
already on the system in jre/lib/ext.
However, I hadn't put that script into use on my TC 6 test box, so both
of my webapps still have the jodbc.jar in their WEB-INF/lib folder, and
I discovered that I can successfully run both of them at the same time
without running into the "already loaded" error I had been getting in
5.5 (which is what caused me to put that stuff in the deployment script
in the first place).
Is this a behavior change in 6.0, or is this error something that
requires something else to trigger it?
Thanks!
D
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Not getting an error that I though I should be getting
Posted by David kerber <dc...@verizon.net>.
Caldarale, Charles R wrote:
>> From: David kerber [mailto:dckerber@verizon.net]
>> Subject: Re: Not getting an error that I though I should be getting
>>
>> Could you clarify what "a given branch of the classloader tree" means?
>
> There's a nice picture in the docs:
>
> Bootstrap
> |
> System
> |
> Common
> / \
> Webapp1 Webapp2 ...
>
> http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html
>
> So it's ok to have the same classes in each webapp, but not ok to have them in a webapp and Tomcat's lib directory or visible to the system classloader (or combination thereof).
>
>> I've got my jdbc driver jar (along with 5 or 6 others) in
>> WEB-INF/lib for each webapp.
>
> That's fine and proper.
Great; thanks for clarifying!!
D
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Not getting an error that I though I should be getting
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: David kerber [mailto:dckerber@verizon.net]
> Subject: Re: Not getting an error that I though I should be getting
>
> Could you clarify what "a given branch of the classloader tree" means?
There's a nice picture in the docs:
Bootstrap
|
System
|
Common
/ \
Webapp1 Webapp2 ...
http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html
So it's ok to have the same classes in each webapp, but not ok to have them in a webapp and Tomcat's lib directory or visible to the system classloader (or combination thereof).
> I've got my jdbc driver jar (along with 5 or 6 others) in
> WEB-INF/lib for each webapp.
That's fine and proper.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Not getting an error that I though I should be getting
Posted by David kerber <dc...@verizon.net>.
Caldarale, Charles R wrote:
>> From: David kerber [mailto:dckerber@verizon.net]
>> Subject: Re: Not getting an error that I though I should be getting
>>
>> Is it still considered good practice to put the jdbc driver jars into
>> the common lib location (catalina_home/lib on tc6)?
>
> If Tomcat is managing the connection pool, it's required, not just good practice. If your webapp is handling the connection pool, then the JDBC driver jar should be in the webapp's WEB-INF/lib directory.
That's clear; thanks. My webapp is doing the pool management.
>
>> It sounds like you're saying that I'm probably ok with the way I'm set
>> up now, but if I change some things, it's possible that something may
>> come back to bite me in the future. Is that a correct interpretation?
>
> That's unclear, since we don't have a good explanation of why you were getting the errors on the previous level. It is dangerous to have the same classes located in multiple places in a given branch of the classloader tree; all sorts of subtle errors can occur.
Could you clarify what "a given branch of the classloader tree" means?
Are multiple webapps that have the same library jars in their
WEB-INF/lib considered to be the same branch? I didn't think so, but
considering your statement, now I'm not so sure. I've got my jdbc
driver jar (along with 5 or 6 others) in WEB-INF/lib for each webapp.
I'm not going to go back and try to create the errors I was getting a
few years ago which I was able to resolve by moving my jdbc driver jar
file around. So I guess I'll go with what works for now unless I find
another good reason to change it during my migration testing, since I'm
moving away from the version in which I got those errors.
D
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Not getting an error that I though I should be getting
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: David kerber [mailto:dckerber@verizon.net]
> Subject: Re: Not getting an error that I though I should be getting
>
> Is it still considered good practice to put the jdbc driver jars into
> the common lib location (catalina_home/lib on tc6)?
If Tomcat is managing the connection pool, it's required, not just good practice. If your webapp is handling the connection pool, then the JDBC driver jar should be in the webapp's WEB-INF/lib directory.
> It sounds like you're saying that I'm probably ok with the way I'm set
> up now, but if I change some things, it's possible that something may
> come back to bite me in the future. Is that a correct interpretation?
That's unclear, since we don't have a good explanation of why you were getting the errors on the previous level. It is dangerous to have the same classes located in multiple places in a given branch of the classloader tree; all sorts of subtle errors can occur.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Not getting an error that I though I should be getting
Posted by David kerber <dc...@verizon.net>.
Pid wrote:
> On 10/03/2010 16:20, David kerber wrote:
>> As part of my migration from tc 5.5.x to 6.0.x, I'm reviewing my
>> deployment scripts, and noticed that in one of them, I'm deleting the
>> jdbc driver jar, jodbc.jar from the WEB-INF/lib folders, because it's
>> already on the system in jre/lib/ext.
>>
>> However, I hadn't put that script into use on my TC 6 test box, so both
>> of my webapps still have the jodbc.jar in their WEB-INF/lib folder, and
>> I discovered that I can successfully run both of them at the same time
>> without running into the "already loaded" error I had been getting in
>> 5.5 (which is what caused me to put that stuff in the deployment script
>> in the first place).
>>
>> Is this a behavior change in 6.0, or is this error something that
>> requires something else to trigger it?
>
> If there's nothing like a Realm configured above the web app classloader
> level which would require the driver to be accessible, then you probably
> won't see an error because the one in the web app is loaded first.
No, no realms to worry about (at least not right now).
Is it still considered good practice to put the jdbc driver jars into
the common lib location (catalina_home/lib on tc6)?
It sounds like you're saying that I'm probably ok with the way I'm set
up now, but if I change some things, it's possible that something may
come back to bite me in the future. Is that a correct interpretation?
D
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Not getting an error that I though I should be getting
Posted by Pid <pi...@pidster.com>.
On 10/03/2010 16:20, David kerber wrote:
> As part of my migration from tc 5.5.x to 6.0.x, I'm reviewing my
> deployment scripts, and noticed that in one of them, I'm deleting the
> jdbc driver jar, jodbc.jar from the WEB-INF/lib folders, because it's
> already on the system in jre/lib/ext.
>
> However, I hadn't put that script into use on my TC 6 test box, so both
> of my webapps still have the jodbc.jar in their WEB-INF/lib folder, and
> I discovered that I can successfully run both of them at the same time
> without running into the "already loaded" error I had been getting in
> 5.5 (which is what caused me to put that stuff in the deployment script
> in the first place).
>
> Is this a behavior change in 6.0, or is this error something that
> requires something else to trigger it?
If there's nothing like a Realm configured above the web app classloader
level which would require the driver to be accessible, then you probably
won't see an error because the one in the web app is loaded first.
If there was, then the connection wouldn't work because the driver isn't
accessible.
p
> Thanks!
> D
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org