When setting up HornetQ through a jboss-beans.xml deployment, the HornetQImpl class gets classloaded, causing a Logger to be assigned, before it loads any hornetq-configuration.xml which might set the logging delegate to something besides JULLogDelegateFactory.

The workaround/solution is to explicitly set the LogDelegateFactory through Java invokation before loading the jboss-beans.xml that ends up instantiating HornetQ components.

Re-opening as a bug because currently if just the factory in Configuration, then on startup, the HornetQServerImpl class gets it's static logger at static initialisation time, before initialiseLogging() is called, so ends up with the JUL logger even if another is specified.

Which should implement some kind of proxy mechanism so the real loggers can be swapped out and nulled even if the factory is changed after the proxy has been obtained by a class

I'd really like to see this fixed, so I wrote a quick patch that shows one way to do it. I didn't include unit tests (it really calls for mocks and I didn't want to add a mocking library dependency to your project), but it doesn't seem to break the build. Adding the ability to change the delegate for an existing logger means there is now an invariant between the log delegate factory and the log delegates contained by the logger objects, so I added synchronization where necessary. The common case of when the logger already exists does not require synchronization.