I'm a colleague of Amod. Yes, we do have a session customizer. This is
legacy code, and we're not using the standard JPA configuration. The only
thing I can think of that might be relevant here is the code we have for
determining the DataSourcePlatform for us:
Platform datasourcePlatform =
session.getDatasourceLogin().getDatasourcePlatform();
DatabasePlatform newPlatform;
if (DBUtils.isMsSqlConnection()) {
// Use customized SQLServerPlatform to resolve Unicode issues.
newPlatform = new SQLServerPlatform();
} else if (DBUtils.isOracleConnection()) {
// Use the Oracle10Platform which is currently identical to
the Oracle9Platform.
// This is required to handle DATE fields properly.
// We no longer support Oracle8.
newPlatform = new Oracle10Platform();
// Oracle has a limit of 4000 characters for String constants.
This enables
// SQL binding for CLOBs.
newPlatform.setUsesStringBinding(true);
newPlatform.setStringBindingSize(4000);
// Byte array binding is required for persisting BLOBs
newPlatform.setUsesByteArrayBinding(true);
} else if (DBUtils.isDB2()) {
newPlatform = new DB2Platform();
} else {
throw new
DataAccessException("err.dataAccess.unsupportedDatabase",
new Object[] {""}, null);
}
newPlatform.setDefaultSequence(datasourcePlatform.getDefaultSequence());
newPlatform.setSequences(datasourcePlatform.getSequences());
newPlatform.setTableQualifier(datasourcePlatform.getTableQualifier());
session.getDatasourceLogin().setDatasourcePlatform(newPlatform);
In any case, what I found is that even though we're using a J2EE
DataSource and no password is required, the class DataSourceLogin is still
always decrypting the empty password. The decryptPassword method in
TopLink was synchronized, but now it is not. I recommended to Amod that
we simply call DataSourceLogin.setEncryptedPassword("") to circumvent the
unnecessary decryption. Does that sound plausible? If that's not
sufficient, then I would try overriding the decryptPassword method to
check for the empty string.