Why use Tomcat's context.xml files to declare DBCP resources?

Question

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