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.

31Jul/080

Java remote debugging

This one was evil. I have an Windows XP box with a Virtual Box installed and a virtualized Xubuntu. I have a Java process running on Windows and my NetBeans is on Xubuntu, and I wanted to debug that Java process. An ugly problem, but it was really easy to solve. I've just added this option to the process JVM parameters:

-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=6543,server=y,suspend=n

After this, I can use NB's "Attach Debugger" feature to connect to the remote JVM. Works like a charm!