Christopher Schultz schrieb:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jens,

On 11/19/2009 5:22 PM, Jens Greven wrote:
Christopher Schultz schrieb:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jens,

On 11/19/2009 2:59 PM, Jens Greven wrote:
is there a way of having a writeable JNDI context in Tomcat? I need one
to place dataSources in it, because I have a perfectly running
DataSourceFactory that is used in other applications as well, so I'd
prefer to use this one above everything else to avoid database
configurations in multiple places. Or is there a way of telling
hibernate to get connections from my DataSourceFactory, thus avoiding
the JNDI hassle?
What about using Tomcat's <Resource> configuration in context.xml which
results in putting a DataSource into the JNDI context. Is there a
compelling reason to use your own DataSourceFactory? If so, I believe
you can configure <Resource> to use that.

See http://tomcat.apache.org/tomcat-6.0-doc/jndi-resources-howto.html
for more information.

- -chris
Chris,

The main reason for using my own DataSourceFactory is to have all
configuration in one place so in case of any changes to configuration
only one class has to be updated no matter what application uses the
DSF. As we have quite a heterogenous infrastructure, it currently
contains connection information for 7 Databases with individual
ConnectionCustomizers etc. (and changes appear quite frequently...). I
will try with the &lt;Resource&gt;, thanks a lot for the hint ;-)

I believe you can set shared configuration either in conf/context.xml
(the default context.xml for all webapps, and will therefore be
inherited by all deployed webapps) or you can put <Resource> elements
into server.xml under <GlobalNamingResources> and then map them to each
webapp you deploy.

See http://tomcat.apache.org/tomcat-6.0-doc/config/globalresources.html
for more information, here.


My problem is that I do not only deal with web applications, but also common desktop applications using JDBC connections and partly hibernate. If it were only for webapps I would certainly use the Tomcat context ;-)

My approach was to create my own DSF as mentioned above, for the desktop applications using hibernate I initialize the DataSources and bind them to a JNDI context, so I can access them for JDBC access as well as use them with my hibernate SessionFactory (which uses DataSources from JNDI context as well, of course). It worked well so far, just when I wanted to initialize the DataSources in my web app, I became aware of the fact that the Tomcat JNDI context is "read only"... Which explains my fist approach (as you can find in the subject ;-) to replace it with a writeable JNDI context.


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

Reply via email to