J'ai trouvé le piège, et ce n'est pas lié au code.
Le nullSafeGet approprié dans le type d'utilisateur Hibernate, comme indiqué dans la réponse référencée est :
public void nullSafeSet(PreparedStatement st, Object value, int index, SessionImplementor session) throws HibernateException, SQLException {
if (logger.isTraceEnabled()) {
logger.trace(" nullSafeSet: " + value + ", ps: " + st + ", index: " + index);
}
try {
XMLType xmlType = null;
if (value != null) {
xmlType = XMLType.createXML(getOracleConnection(st.getConnection()), (String)value);
}
st.setObject(index, xmlType);
} catch (Exception e) {
throw new SQLException("Could not convert String to XML for storage: " + (String)value);
}
}
PROBLÈME : lors de l'utilisation d'une colonne SECUREFILE BINARY XML (pas CLOB), vous devez utiliser la distribution la plus récente (11.2.0.2+) de xdb*.jar, qui dans ce cas est xdb6.jar (~257kb). L'ancien xdb*.jar (~136 Ko pour 10.x) fonctionnera toujours, sans aucune exception, même en cas de décodage incorrect du XML BINAIRE.
TL;DR :Téléchargez xdb6.jar (~257kb) depuis le Page des pilotes JDBC Oracle 11gR2 (11.2.0.3) . Les anciens fichiers jar xdb échouent silencieusement et vous rendront triste.
