Re: Self-Contained Web Applications
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, On 7/20/2010 11:14 PM, Caldarale, Charles R wrote: From: Christopher Schultz [mailto:ch...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Self-Contained Web Applications
-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.bris...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Self-Contained Web Applications
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, On 6/25/2010 6:01 PM, Caldarale, Charles R wrote: From: Pid [mailto:p...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Self-Contained Web Applications
From: Christopher Schultz [mailto:ch...@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
From: Christopher Schultz [mailto:ch...@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.
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Self-Contained Web Applications
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org signature.asc Description: OpenPGP digital signature
Re: Self-Contained Web Applications
-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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Self-Contained Web Applications
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org signature.asc Description: OpenPGP digital signature
Re: Self-Contained Web Applications
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Self-Contained Web Applications
From: Jon Brisbin [mailto:jon.bris...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Self-Contained Web Applications
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org signature.asc Description: OpenPGP digital signature
RE: Self-Contained Web Applications
From: Pid [mailto:p...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
