Question

I’m having trouble understanding why I would use a context.xml file to declare a resource, in my case a database connection pool. Hopefully I’ve got my facts straight in the following arguments against using context.xml

1. As far as I can tell, resources
   declared in /META-INF/context.xml
   are only available within the
   context, so there’s no reason to do
   so to share resources.

2. Declaring a connection
   pool resource in this way creates a
   dependency on the container’s
   classloader, so if I do so and, for example, wish
   to change my database drivers, I
   must restart the container, not just
   my context.

3. I also create a dependency on
   containery things like JNDI, which
   makes standlone testing tricker.

4. Finally, I have to jump through
   build-time hoops to switch resources
   between test and production
   resources for example.

None of these issues are insurmountable, but it certainly seems on paper much more straightforward to just create a connection pool and hook it into my context scope.

I’d like to know under what circumstances are context.xml files the right answer?

Answer 1

The only valid reason I have seen is if you want Tomcat to be able to use your connection pool for something like it’s basic user authentication calls, if you had it setup to do use a JDBC UserAuth context then you may want Tomcat to have connection pooling.