4.1.2, DefaultContext, ResourceLink

[st...@illinoispower.com]

As part of testing 4.1.12, we have started using DBCP for pooling and have
defined a pool in the GlobalNamingResources tag in server.xml.  There is
also a context tag in server.xml that looks like this:

<Context path="/CCS" docBase="CCS" debug="0" reloadable="true" crossContext
="false">
  <ResourceLink name="jdbc/DB2TEST" global="jdbc/DB2TEST" type
="javax.sql.DataSource"/>
  <ResourceLink name="mail/Session" global="mail/Session" type
="javax.mail.Session"/>
</Context>

This worked fine.  It is a manually deployed WAR in the webapps directory,
and admin deployment tools were not used for this test.  I then tried to
remove the hardcoded Context definition and replaced it with a
DefaultContext:

<DefaultContext>
  <ResourceLink name="jdbc/DB2TEST" global="jdbc/DB2TEST" type
="javax.sql.DataSource"/>
  <ResourceLink name="mail/Session" global="mail/Session" type
="javax.mail.Session"/>
</DefaultContext>

The intent was that these resourc links to the global definitions would
then be available to any deployed contexts.  However, it looks like in this
configuration the ResourceLink back to the global definition doesn't work,
because the first connect fails with this (abbreviated) call stack:

java.sql.SQLException: Cannot load JDBC driver class 'null'
      at
org.apache.commons.dbcp.BasicDataSource.createDataSource(BasicDataSource.java:529)
      at
org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:312)
      .
      .
      .

The resource definition in GlobalNamingResources is identical, and has the
proper driver for DB2 Connect defined.  Since it works in the explicit
context case, I'm pretty sure it's correct for the default context case.

I did some searches and didn't get any hits on this particular issue.  It's
obviously not a major issue, but I am hoping someone knows if this is
working as designed or not.  If DefaultContext is intended to support
resource link definitions, then I'll dig into it, post a bug, and maybe a
fix.


Thanks in advance!



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>