[HORNETQ-406] Difficulty in setting the LogDelegate effectively Created: 03/Jun/10 Updated: 12/Feb/13 Resolved: 12/Feb/13
|Reporter:||Bob McWhirter||Assignee:||Andy Taylor|
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
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.
|Comment by Tim Fox [ 03/Jun/10 ]|
You need to
after you create your config.
|Comment by Tim Fox [ 04/Jun/10 ]|
Bob - did this solve your problem?
If so, I'll close it
|Comment by Bob McWhirter [ 04/Jun/10 ]|
Yah, I initially set it only in the hornetq-configuration.xml, and it was ineffective there for affecting the logger on HornetQImpl, so I had to do the explicit setDelegateFactory(...) call.
Sounds like either explicit setDelegateFactory(...) or hornetq-configuration.xml is not sufficient, but both are required (at least in my environment).
I'm all good. NOTABUG.
|Comment by Tim Fox [ 05/Jun/10 ]|
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
|Comment by Marshall Pierce [ 17/Sep/10 ]|
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.
|Comment by Andy Taylor [ 12/Feb/13 ]|
closing as 2.3 now uses JBoss Logging