This is a "feature" of the XADataSourceLoader: it tries to help you by checking if a connection can be made when it is started. The ConnectionFactoryLoader version of things doesn't do this. So, you could comment out the lines that make this check, or if you are using jboss 2.4.4 or later, use ConnectionFactoryLoader. (There is one line, something like ds.getConnection().close() that you'd need to remove.)
I think that you need to also tell jaws not to create your tables on deploy of beans... that would also need a connection.
If you find other dependencies like this please let us know.
Thanks for the reply, I'm now trying the ConnectionFactoryLoader approach as we are using JBoss 2.4.4. However I can't get it to work - I assume I'm doing something stupid while trying to "convert" my XADataSourceLoader into a ConnectionFactoryLoader:
my understanding is, the jndi lookup string should be the same, that is java:/<factory-name> as mentioned in the book.
Upon starting, JBoss finds my ConnectionFactoryLoader, "DBKnown" :
2002-02-18 19:48:20,738 [org.jboss.resource.ConnectionFactoryLoader.DBKnown] Starting
2002-02-18 19:48:20,740 [org.jboss.resource.ConnectionFactoryLoader.DBKnown] Started
But the lookup fails:
javax.naming.NameNotFoundException: DBKnown not bound
Is my lookup correct, or what else could I be doing wrong ?
My config follows:
-- BEFORE (XADataSourceLoader) --
-- AFTER (ConnectionFactoryLoader) --
(it's probably a copying typo, but maxSize=0 is probably not what you want)
I'm sorry, I don't remember exactly what things are called in 2.4.4 so I might give you the wrong name.
You need jbosscx.jar and jbosspool.jar (and your driver) in lib/ext, and the .rar containing the "JDBC ResourceAdapter" in deploy or deploy/lib.
On startup, you should see the ConnectionFactoryLoader init and start, and later the RARDeployer deploy the JDBC ResourceAdapter rar. When it is deployed, the RARDeployer notifies (through jmx) the ConnectionFactoryLoader that its rar is available, and it then sets itself up and binds to jndi (as you think, the name should be the same).
So... check the log carefully, see if these steps are happening.
(in 3.0 the deployment sequence uses an mbean dependency mechanism to result in slightly less convoluted actions)