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 2010/06/25 18:02:12 UTC

Self-Contained Web Applications

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

All,

While reading another thread ("What's going on ... ?"), I started to
think about how inconvenient it is to have to put your JDBC driver into
the server's lib directory. As it stands, now, all webapps must share
the same version of the same driver, and the main installation of Tomcat
(or scion, when using CATALINA_BASE) must be modified from the default
in order to deploy your application :(

It would seem to me that, if the webapps's META-INF/context.xml file
defines a JNDI <Resource>, that the server could use the context's
libraries to initialize those resources.

If the above were possible, then a web application could really be
self-contained. That would allow different webapps deployed onto the
same server to use different JDBC drivers for the same (type of)
database, which would be really nice.

Can any of the Tomcat wonks comment on the possibility of using the
WebappClassLoader to initialize JNDI resources? I suppose this would
also touch on the subject of JNDI DataSources never being closed, since
using the WebappClassLoader without closing those resources would create
a costly resource leak.

Thanks,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwk0wQACgkQ9CaO5/Lv0PC1CACglg/R97/A6aZ5DD90g4gEM72M
mu4An3CYQVCgVgHVwkD3Pw4HpuDE5g1Z
=n95V
-----END PGP SIGNATURE-----

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


RE: Self-Contained Web Applications

Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Subject: Re: Self-Contained Web Applications
> 
> 1. Just but mysql-connector-j.x.y.z.jar into WEB-INF/lib

But still use container-provided connection pooling when the container classes are loaded by the common classloader.  This is what I was referring to when I said the webapp classloader would have to get its own copies of Tomcat classes.  Might be doable by extending the classpath of the webapp classloader to include some directory containing jars/classes that would be available to each webapp (eg, commons-dbcp or tomcat-dbcp) but still loaded by each webapp rather than some shared classloader.  Doesn't sound like too much work, but does introduce potential versioning complications.

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


Re: Self-Contained Web Applications

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chuck,

On 6/25/2010 6:01 PM, Caldarale, Charles R wrote:
>> From: Pid [mailto:pid@pidster.com]
>> Subject: Re: Self-Contained Web Applications
>>
>> We can define a DataSource inside a Context already, hook up a locally
>> configured Realm, and it'll use a driver from the web app ClassLoader,
>> which makes the app completely self contained.
>>
>> I don't understand what Chris is getting at.  :s
> 
> What I interpreted his posting to mean was he wanted
> container-managed connection pooling (and all other JNDI-based
> resource usage) done without placing any classes in any global
> directory space.

Exactly.

> In other words, the Tomcat classes would use the
> webapp's classloader first before looking in any global locations for
> necessary driver libraries.  This might require having the webapp
> classloader get its own copies of the Tomcat classes, but it sounds
> doable with a bit of re-plumbing.

Today, the install process for a webapp that needs MySQL connections is:

1a. Copy mysql-connector-j.x.y.z.jar into CATALINA_BASE/lib
1b. Make sure you don't have mysql-connector-j.x.y.z.jar in WEB-INF/lib
2. Configure DataSource in META-INF/context.xml
3. Use JNDI to locate and use the DataSource

I'm trying to replace step #1 with:

1. Just but mysql-connector-j.x.y.z.jar into WEB-INF/lib

This would alleviate several irritating issues:

1. People always do what I want to do anyway, and want to know why they
get that weird "Cannot load JDBC driver 'null'" message

2. The webapp is not self-contained if it requires MySQL and yet does
not include the MySQL JDBC driver library

3. All webapps (that want to use container-provided DataSource services)
are forced to use the same version of the MySQL driver

4. The DataSource currently outlives the Context, which is kind of silly
if the context itself defines the DataSource

Is there an architectural reason why Tomcat has historically done JNDI
DataSources in this way? Is it because of the historical use of "global"
resources defined in server.xml?

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxGSMQACgkQ9CaO5/Lv0PCXaQCgsI6mGrHyY+UmH/q7PUO7T4lR
c9sAoJTlaBZIfeC4k1AYDb0hO3dx3ZyF
=XPWU
-----END PGP SIGNATURE-----

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


RE: Self-Contained Web Applications

Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Pid [mailto:pid@pidster.com]
> Subject: Re: Self-Contained Web Applications
> 
> We can define a DataSource inside a Context already, hook up a locally
> configured Realm, and it'll use a driver from the web app ClassLoader,
> which makes the app completely self contained.
> 
> I don't understand what Chris is getting at.  :s

Chris didn't mention anything about realms in his initial message.  What I interpreted his posting to mean was he wanted container-managed connection pooling (and all other JNDI-based resource usage) done without placing any classes in any global directory space.  In other words, the Tomcat classes would use the webapp's classloader first before looking in any global locations for necessary driver libraries.  This might require having the webapp classloader get its own copies of the Tomcat classes, but it sounds doable with a bit of re-plumbing.

 - 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: Self-Contained Web Applications

Posted by Pid <pi...@pidster.com>.
On 25/06/2010 22:29, Jon Brisbin wrote:
> 
> On Jun 25, 2010, at 3:59 PM, Pid wrote:
> 
>> Which part of the container hierarchy would the DataSource be attached to?
> 
> Wouldn't it make sense to scope it to the Context, since you'd be using the webapp's classloader?

We can define a DataSource inside a Context already, hook up a locally
configured Realm, and it'll use a driver from the web app ClassLoader,
which makes the app completely self contained.

I don't understand what Chris is getting at.  :s


p

> Jon Brisbin
> Portal Webmaster
> NPC International, Inc.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 



Re: Self-Contained Web Applications

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chuck,

On 7/20/2010 11:14 PM, Caldarale, Charles R wrote:
>> From: Christopher Schultz [mailto:chris@christopherschultz.net]
>> Subject: Re: Self-Contained Web Applications
>>
>> Well, having to include commons-dbcp is a bit of an implementation
>> detail, here. I should be able to include only my own JDBC driver and
>> have Tomcat figure out that commons-dbcp should be available elsewhere
>> (say, in the lib directory).
> 
> But now you're asking commons-dbcp classes (loaded by the common
> classloader) to look _downwards_ in the classloader hierarchy to find
> the JDBC driver they're using for the connections.  I don't think
> that's going to happen - ever.

Obviously, the classes themselves have no knowledge of the class loading
hierarchy. As long as the WebappClassLoader is the context ClassLoader
for the thread that creates the DataSource, all should be well.

Am I missing something tremendous, here?

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxHCkQACgkQ9CaO5/Lv0PALxQCeLCCNOSBJWPaeqoq1aF3RI27N
3GAAnjm3UvsCVUyYee4w6x3CBxMznrWb
=e5Sm
-----END PGP SIGNATURE-----

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


RE: Self-Contained Web Applications

Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Subject: Re: Self-Contained Web Applications
> 
> Well, having to include commons-dbcp is a bit of an implementation
> detail, here. I should be able to include only my own JDBC driver and
> have Tomcat figure out that commons-dbcp should be available elsewhere
> (say, in the lib directory).

But now you're asking commons-dbcp classes (loaded by the common classloader) to look _downwards_ in the classloader hierarchy to find the JDBC driver they're using for the connections.  I don't think that's going to happen - ever.

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


Re: Self-Contained Web Applications

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chuck,

(I mist have missed these replies... I'm resurrecting this thread).

On 6/25/2010 5:44 PM, Caldarale, Charles R wrote:
>> From: Jon Brisbin [mailto:jon.brisbin@npcinternational.com]
>> Subject: Re: Self-Contained Web Applications
>>
>> Wouldn't it make sense to scope it to the Context, since 
>> you'd be using the webapp's classloader?
> 
> Correct.  Note that the desired effect should be achievable by
> including commons-dbcp in its WEB-INF/lib, and coding the application
> to use that.  Completely self-contained, and not dependent on any
> container behavior or capabilities.

Well, having to include commons-dbcp is a bit of an implementation
detail, here. I should be able to include only my own JDBC driver and
have Tomcat figure out that commons-dbcp should be available elsewhere
(say, in the lib directory).

That should work even if the WebappClassLoader is being used to
initialize the DataSource, since it will call up the ClassLoader chain
to find classes not available "locally".

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxGRyIACgkQ9CaO5/Lv0PD4bwCgkw/zD0zmMJbjROvneYT0ZCFw
whcAoMBZ8RL2iN2SdFoUqy+3q5LtTIPf
=p0vo
-----END PGP SIGNATURE-----

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


RE: Self-Contained Web Applications

Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Jon Brisbin [mailto:jon.brisbin@npcinternational.com]
> Subject: Re: Self-Contained Web Applications
> 
> Wouldn't it make sense to scope it to the Context, since 
> you'd be using the webapp's classloader?

Correct.  Note that the desired effect should be achievable by including commons-dbcp in its WEB-INF/lib, and coding the application to use that.  Completely self-contained, and not dependent on any container behavior or capabilities.

 - 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: Self-Contained Web Applications

Posted by Jon Brisbin <jo...@npcinternational.com>.
On Jun 25, 2010, at 3:59 PM, Pid wrote:

> Which part of the container hierarchy would the DataSource be attached to?

Wouldn't it make sense to scope it to the Context, since you'd be using the webapp's classloader?


Jon Brisbin
Portal Webmaster
NPC International, Inc.


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


Re: Self-Contained Web Applications

Posted by Pid <pi...@pidster.com>.
On 25/06/2010 19:06, Christopher Schultz wrote:
> Pid,
> 
> On 6/25/2010 12:44 PM, Pid wrote:
>> On 25/06/2010 17:02, Christopher Schultz wrote:
>>> All,
>>>
>>> While reading another thread ("What's going on ... ?"), I started to
>>> think about how inconvenient it is to have to put your JDBC driver into
>>> the server's lib directory. As it stands, now, all webapps must share
>>> the same version of the same driver, and the main installation of Tomcat
>>> (or scion, when using CATALINA_BASE) must be modified from the default
>>> in order to deploy your application :(
> 
>> You can define a lib dir under CATALINA_BASE and Tomcat will load jars
>> from there by preference over CATALINA_HOME, no?
> 
> Only if you modify catalina.policy.
> 
>> If it doesn't do it by default you can modify catalina.properties so it
>> does.
> 
> Right: I'm trying to avoid this. It would be cool if a WAR file using
> container-managed DataSource could be deployed into a factory-fresh
> Tomcat install. Specifically, without dropping the JDBC library JAR file
> into the server's lib directory, and instead using the WAR's WEB-INF/lib
> directory.

Which part of the container hierarchy would the DataSource be attached to?


p

> -chris

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




Re: Self-Contained Web Applications

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Pid,

On 6/25/2010 12:44 PM, Pid wrote:
> On 25/06/2010 17:02, Christopher Schultz wrote:
>> All,
>>
>> While reading another thread ("What's going on ... ?"), I started to
>> think about how inconvenient it is to have to put your JDBC driver into
>> the server's lib directory. As it stands, now, all webapps must share
>> the same version of the same driver, and the main installation of Tomcat
>> (or scion, when using CATALINA_BASE) must be modified from the default
>> in order to deploy your application :(
> 
> You can define a lib dir under CATALINA_BASE and Tomcat will load jars
> from there by preference over CATALINA_HOME, no?

Only if you modify catalina.policy.

> If it doesn't do it by default you can modify catalina.properties so it
> does.

Right: I'm trying to avoid this. It would be cool if a WAR file using
container-managed DataSource could be deployed into a factory-fresh
Tomcat install. Specifically, without dropping the JDBC library JAR file
into the server's lib directory, and instead using the WAR's WEB-INF/lib
directory.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwk8BcACgkQ9CaO5/Lv0PDptgCgjn5SZcUE4eD4h3oPc2kX8MHZ
U8oAn3Y1EPtzHBHM6uLKlztmvQu9HgNe
=7YyJ
-----END PGP SIGNATURE-----

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


Re: Self-Contained Web Applications

Posted by Pid <pi...@pidster.com>.
On 25/06/2010 17:02, Christopher Schultz wrote:
> All,
> 
> While reading another thread ("What's going on ... ?"), I started to
> think about how inconvenient it is to have to put your JDBC driver into
> the server's lib directory. As it stands, now, all webapps must share
> the same version of the same driver, and the main installation of Tomcat
> (or scion, when using CATALINA_BASE) must be modified from the default
> in order to deploy your application :(

You can define a lib dir under CATALINA_BASE and Tomcat will load jars
from there by preference over CATALINA_HOME, no?

If it doesn't do it by default you can modify catalina.properties so it
does.


> It would seem to me that, if the webapps's META-INF/context.xml file
> defines a JNDI <Resource>, that the server could use the context's
> libraries to initialize those resources.

You can define a DataSource in context.xml - that's why Realm has
localDataSource.  Or do you mean something else?


p

> If the above were possible, then a web application could really be
> self-contained. That would allow different webapps deployed onto the
> same server to use different JDBC drivers for the same (type of)
> database, which would be really nice.
> 
> Can any of the Tomcat wonks comment on the possibility of using the
> WebappClassLoader to initialize JNDI resources? I suppose this would
> also touch on the subject of JNDI DataSources never being closed, since
> using the WebappClassLoader without closing those resources would create
> a costly resource leak.
> 
> Thanks,
> -chris

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