MDB connected to Oracle AQ via a datasource

Question

Im trying to create a MDB (JBoss AS 6) that connect to an Oracle AD queue.

I got the following example to work:

@MessageDriven(name = "TestMdb", activationConfig = {
    @ActivationConfigProperty(propertyName="destinationType", propertyValue = "javax.jms.Queue"),
    @ActivationConfigProperty(propertyName="connectionFactoryProperties", propertyValue="jdbc_connect_string=jdbc:oracle:thin:XXXXX@XXX:1521:XXX,host=XXXX,user=XXXX,password=XXXX,port=XXXX,sid=XXXX,driver=XXXX"),
    @ActivationConfigProperty(propertyName="destinationProperties", propertyValue="owner=XXXXX,name=jms_text_que"),
    @ActivationConfigProperty(propertyName="userName", propertyValue="XXXX"),
    @ActivationConfigProperty(propertyName="password", propertyValue="XXXX"),
    @ActivationConfigProperty(propertyName="ConnectionFactoryClassName", propertyValue="oracle.jms.AQjmsConnectionFactory"),
    @ActivationConfigProperty(propertyName="QueueConnectionFactoryClassName", propertyValue="oracle.jms.AQjmsQueueConnectionFactory")
    })
@ResourceAdapter("XXXXXX-ear.ear#genericjmsra.rar")
@TransactionManagement(TransactionManagementType.BEAN)
public class TestMdb  implements MessageListener {

    public void onMessage(Message message) {
    ...
    }
}

The problem is that I need to specify the connection properties directly in the code (including DB host, username and password). Does anyone know a way to use a datasource from a jndi lookup?

Thanks

Answer 1

It is infuriating that the textbook implementation of MDB annotation configuration dictates the hard coding of environment and security specific values. Annotation processing in Java is also devilishly clever about making sure you are not sneaking in some non-constant value like a final String MyConfig = System.getProperty(....).

At any rate, you can configure some or all of the MDB configuration to an XML deployment descriptor which is a bit more friendly (although a bit more complex to build and deploy). JBoss XML deployment descriptors can have values assigned in ${} tokens that reference system properties so they're a bit more manageable from a configuration perspective.