Extreme Java When vanilla Java is not enough

20Jul/090

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.

Comments (0) Trackbacks (0)

No comments yet.


Leave a comment

(required)


*

No trackbacks yet.