Description

Running the test XAJNDITest (from old xaJNDI.java) with network server fails because the XADataSource as bound to JNDI, and then fetch from JNDI are not identical.
This is what the test does to get the XADataSource & to bind & get it from JNDI:
----------------
...
XADataSource xads = J2EEDataSource.getXADataSource();
String dbName = TestConfiguration.getCurrent().getDefaultDatabaseName();
JDBCDataSource.setBeanProperty(xads, "databaseName", dbName);
JDBCDataSource.setBeanProperty(xads, "createDatabase", "create");
JDBCDataSource.setBeanProperty(xads, "description", "XA DataSource");

Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
// using a system property - these will have to be passed in somehow.
env.put(Context.PROVIDER_URL, "ldap://" + ldapServer + ":" + ldapPort);
env.put(Context.SECURITY_AUTHENTICATION, "simple");

Further checking showed that the fetched datasource has a String with value "null" rather than a null value for the following properties:
dataSourceName, connectionAttributes, traceDirectory, traceFile.

The embedded data sources only add the non-null properties to the object returned by getReference(), and there's a comment saying that the string "null" will be returned if a null is added. The attached patch makes the client data sources use the same logic and removes the workaround for the null/"null" issue in XAJNDITest.

I have only run XAJNDITest on the patch so far. Will run the rest of the regression test suite soon.

Knut Anders Hatlen
added a comment - 06/Jul/09 14:49 The embedded data sources only add the non-null properties to the object returned by getReference(), and there's a comment saying that the string "null" will be returned if a null is added. The attached patch makes the client data sources use the same logic and removes the workaround for the null/"null" issue in XAJNDITest.
I have only run XAJNDITest on the patch so far. Will run the rest of the regression test suite soon.