Web application scoped DataSource exposed as a JNDI resource.
EAR application scoped DataSource exposed as a JNDI resource.
Application server/cluster scoped DataSource exposed as a JNDI resource.
Should DataSource configurations in Tomcat be context scope or server scoped?
Ultimately, every major application should be using a separate DataSource and corresponding user name and password. The user name and password information should not be stored in any of the application configuration files.
Tomcat used to only be used for development in my organization. Although, Tomcat is increasingly being leveraged for production environments.
Regardless of sever or context scoping the Spring DataSource shall still be configured as a JNDI DataSource
When using Spring to inject DataSources into an application consider that names are looked up a little differently in different containers. When deploying to Weblogic the JNDI names are relative to the java:comp/env/ context so short names may be used (like simply jdbc/myDataSource). When deploying to Tomcat the full JNDI name needs to be used (like java:comp/env/jdbc/myDataSource).
The application's web.xml does not need to include resource reference elements to access resources that are configured as described below.
Either of the following two approaches can be utilized:
Modify both the server.xml and the context.xml. This is the most realistic approach for an acurate production configuration.
Add a Resource (data source) configuration to the server.xml file to expose a resource to the container.
A data source is configured with a new Resource element under the Server and GlobalNamingResources elements
The resource element contains the typical attributes to configure a data source.
An example element
<Resource name="jdbc/TestDBGlobal" auth="Container" type="javax.sql.DataSource" maxActive="100" maxIdle="30" maxWait="10000" username="me" password="mine" driverClassName="org.apache.derby.jdbc.ClientDriver" url="jdbc:derby://localhost:1527/sample;create=true" />
Another example element
<Resource name="jdbc/oracleDevelopment" auth="Container" type="javax.sql.DataSource" maxActive="100" maxIdle="30" maxWait="10000" username="XXX" password="XXX" driverClassName="oracle.jdbc.driver.OracleDriver" url="jdbc:oracle:thin:@enbossfxdb01.caci.com:1521:usardev1" />
Add a resource link to the context.xml file to expose the container resource to all contexts in the container.
The resource link element contains the following attributes:
ResourceLink.name: the name to expose the container resource as to each context
ResourceLink.global: the name of the resource in the container
ResourceLink.type: the type of the resource to expose
An example element
<ResourceLink name="jdbc/TestDB" global="jdbc/TestDBGlobal" type="javax.sql.DataSource" />
Modify only the context.xml. This is appealing for a development environment.
Modify only the context.xml to contain the resource that was added to the server.xml described above (just the resource not the resource link).
Add a resource link to the context.xml file to expose the container resource to all contexts in the container.
Need a script to add a everything to a tomcat installation necessary to expose a DataSource to all applications in a container (add driver, update server.xml and update context.xml)
configured explicitly as a Driver This really stinks due to the having to embed user name and password information in the DataSource url.
configured indirectly by JNDI
All DataSources should be configured in JNDI to allow spring bean JNDI string property to be configured with a property place holder and/or change the DataSource configuration separately from the application.
We currently are forced to create separate builds for each of the environments (development, integration, test, production) for several of our applications. We need an approach that allows generating a single build artifact the does not need to change based on the target deployment environment.
Need to consider how this is going to execute within the context of junit tests.
It appeared that Tomcat and Eclipse need to be restarted for changes to context.xml and server.xml to take effect when using eclipse WTP. I didn't find any documentation to address this issue. But, with a little experimentation, I found that the process to get Tomcat to recognize the context and server changes was simple to publish to the server and restart it. (simple eh?)