Using JBoss as a remote datasource provider
After some trial-and-error, I managed to use a JBoss 5 as a JNDI server and a Tomcat as a JNDI client. If you plan to make a JBoss DataSource public, just add a “<use-java-context>false</use-java-context>” to your “<local-tx-datasource>”.
Tomcat is easy to configure. You need to add a resource like this one (”look mom! no password!”):
<Resource name="jdbc/myds" auth="Container" type="javax.sql.DataSource" factory="org.jnp.interfaces.NamingContextFactory" URL="jnp://jboss-host:1099/jdbc/mydsOnJboss" />
The “jdbc/mydsOnJBoss” part is the same as the “<jndi-name>” on JBoss datasource. The real trick is the classpath. Go to JBOSS_HOME/client and copy these files:
- jboss-logging-jdk (or jboss-logging-log4j)
- jboss-logging-spi
- jnp-client
- jboss-client
- jboss-common-core
- jboss-integration
- jboss-remoting
- jboss-security-spi
- jboss-serialization
- jbosscx-client
- jboss-javaee (optional if your Tomcat has the javax.transation.* already)
The first three (jnp-client, jboss-logging-*) are obvious, since they are explicit dependencies (i.e. you receive a “ClassNotFoundException”). The others are implicit - you don’t receive a CNFE, you get a “ClassCastException” (cannot cast javax.naming.Reference to javax.sql.Datasource). It is evil - no docs, no log, only “-verbose:class” helped me.
With the right libs and the right configuration, you can use @Resource (or Spring’s JNDI lookup) the same way as a locally defined datasource - without any sensitive information exposed.
As a final note, you don’t need the JDBC driver on client.
Tags: datasource, JBoss, naming, remote