[hibernate-issues] [Hibernate-JIRA] Updated: (HHH-4111) Unable to hot-swap logger configuration for Hibernate types due to local cache

Unable to hot-swap logger configuration for Hibernate types due to local cache ------------------------------------------------------------------------------- Key: HHH-4111 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4111 Project: Hibernate Core Issue Type: Improvement Components: core Affects Versions: 3.2.6 Environment: Hibernate 3.2.6.ga Reporter: Baptiste MATHUS Attachments: hhh4111-confreload.zip Hi, Like a lot of people, I guess, we added in our app the possibility to be able to change logging (logback/log4j) configuration without having to restart the server. This works very fine, but we recently noticed that trying to activate the binding logs (via the org.hibernate.type=trace option) doesn't have any effect. After some investigation, we found out what's the cause of this problem. In NullableType, the "logger.isTraceEnabled()" value is cached in a static final boolean... So, when you start the server without any binding log and then trigger the NullableType class loading, you won't be able to see any binding log until server is restarted. It would be great if you could propose a clean solution for this use case (remove the cache?). For example, we currently are trying to debug a running production server. And we cannot see the values sent in the query we're interested in. Is the performance improvement really so significant as Gavin stated in the javadoc? Cannot we just not cache this value and trust the logging implementor for this performance aspect? As a reminder, here's the corresponding code excerpt: public abstract class NullableType extends AbstractType { /** * This is the old scheme where logging of parameter bindings and value extractions * was controlled by the trace level enablement on the 'org.hibernate.type' package... * <p/> * Originally was cached such because of performance of looking up the logger each time * in order to check the trace-enablement. Driving this via a central Log-specific class * would alleviate that performance hit, and yet still allow more "normal" logging usage/config.. */ private static final boolean IS_VALUE_TRACING_ENABLED = LogFactory.getLog( StringHelper.qualifier( Type.class.getName() ) ).isTraceEnabled(); private transient Log log; private Log log() { if ( log == null ) { log = LogFactory.getLog( getClass() ); } return log; } Thanks a lot!