If a plain BasicConfigurator.configure() is called in an application after the HierarchyMBean is instantiated, then an exception is thrown trying to create an ObjectName for the appender based on the Appender's name property, which is initialised to null, and is not allowed. Instead, the LoggerDynamicMBean class should be defensive when creating a Appender MBean's by detecting a null/empty string name and at least trying to use .toString() to construct a logical display name.
I have a simple patch for this that I'm just testing, it basically resorts to defensively using the Appender.toString() in an attempt to get at least a value for the JMX namespace. If that fails, well, then you're screwed still.
You'll find here http://d.cr.free.fr/wswebconsulterfichiers.php?projet=demojava_log4j&mode=res&fichier=org.apache.log4j.jmx.LoggerDynamicMBean.java.res&fichierxsl= a collection of mistakes and errors. Most are easy to fix. The entire log4j project is available here : http://d.cr.free.fr/wswebconsulterfichiers.php?projet=demojava_log4j If of interest for you, thanks for your (positive..) feedback. Coming soon : CWE identification of bugs.
Paul, do you want to submit your patch?
Created attachment 23112 [details] Patch that fixes the null appender name Note: This is a direct diff of my workspace, which also includes a change to test/build.xml to remove the ErrorHandler test that just doesn't pass on my computer for some unknown reason (before and after my change). We've been using this change in production for 2 months now with no problems.
Committed changes in rev 734480. I did a few things different than Paul's patch. First, Paul's patch used a package visible static method to handle the logic to get a name from the appender. I moved the function into a common ancestor and made it protected. Also, Paul's patch removed use of the layout from the AppenderDynamicMBean name. That may be a desirable change, but it wasn't part of this bug report.