Hi all,
Yesterday while looking at the JBC code, I spotted that
CommandInterceptor caches log.isTraceEnabled() as instance variable and
that pretty much all classes extending this use it.
In a standalone world, where JBC runs on its own this is fine. However,
when running within AS, log4j settings could change at runtime
(conf/jboss-log4j.xml is hot deployable) and therefore, someone could
enable TRACE logging for org.jboss.cache at runtime which wouldn't have
any effect with the current JBC code.
As far as I can remember, it's generally recommended not to cache things
like this in code running within AS. Then again, I can see how
convenient caching such value is rather than calling
log.isTraceEnabled() all the time. I doubt using an instance variable or
calling log.isTraceEnabled() would have a real impact performance wise
when TRACE is not enabled.
Thinking about this, I wonder whether any callback(s) could be
implemented when the log4j settings are updated after a hot deployment
and within this callback, update interceptors' trace settings...
Thoughts?
--
Galder ZamarreƱo
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat