Well, I did finally manage to get this working with AS 6.1.0 Final. I'll try to outline what I did...
First off, as this thread mentions, there were some logging changes that were supposed to make it into AS 6.1 that didn't. Those changes can be found in this bug report. So the first step is to take the 3 jar files attached to the bug and replace the ones shipped with AS 6.1. That bug report also mentions upgrading ant to 1.2.16, which isn't necessary in AS 6.1 since it already ships with 1.2.16 (I believe AS 6.0 used 1.2.14?). This step gets jboss-logmanager playing nice(r) with log4j.
Another issue that has always plagued the JMS appender setup has been when JMS endpoints get deployed, but this seems to be fixed in AS 6.1. With 6.1 my JMS endpoints are deployed as part of the bootstrap process before the main logging framework kicks in, which is great. This means that configuring the JMS appender in the typical jboss-logging.xml file works and you don't have to do the MBean trick like I explained in my first post. In my case I get my JMS endpoints deployed by adding a someapp-hornetq-jms.xml file into server/<whatever>/deploy-hasingleton/jms directory. That file looks like this:
{code:xml}
<configuration xmlns="urn:hornetq"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:hornetq /schema/hornetq-jms.xsd">
<topic name="logMessages">
<entry name="/topic/logMessages" />
</topic>
</configuration>
{code}
The settings needed in jboss-logging.xml are the same as what I posted originally. Brian's note about the appender name wasn't required for me to get the appender working, but it did aid in the debugging processes.
After making these changes I started receiving logging events in my topic.
Now on to the message consumers... My first consumer was a typical MDB (no, I would not do this in a production environment) that subscribed to the topic. When the onMessage() method fired in the MDB I'd start seeing these messages in the logs:
{noformat}
2012-01-26 12:04:47,444 ERROR [STDERR] log4j:WARN Level deserialization failed, reverting to default.
2012-01-26 12:04:47,445 ERROR [STDERR] java.lang.NoSuchMethodException: org.jboss.logmanager.log4j.handlers.Log4jJDKLevel.toLevel(int)
2012-01-26 12:04:47,445 ERROR [STDERR] at java.lang.Class.getDeclaredMethod(Class.java:1937)
2012-01-26 12:04:47,445 ERROR [STDERR] at org.apache.log4j.spi.LoggingEvent.readLevel(LoggingEvent.java:436)
2012-01-26 12:04:47,445 ERROR [STDERR] at org.apache.log4j.spi.LoggingEvent.readObject(LoggingEvent.java:464)
2012-01-26 12:04:47,446 ERROR [STDERR] at sun.reflect.GeneratedMethodAccessor399.invoke(Unknown Source)
2012-01-26 12:04:47,446 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
2012-01-26 12:04:47,446 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:597)
2012-01-26 12:04:47,446 ERROR [STDERR] at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
2012-01-26 12:04:47,447 ERROR [STDERR] at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1848)
2012-01-26 12:04:47,447 ERROR [STDERR] at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
2012-01-26 12:04:47,447 ERROR [STDERR] at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
2012-01-26 12:04:47,450 ERROR [STDERR] at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)
2012-01-26 12:04:47,451 ERROR [STDERR] at org.hornetq.jms.client.HornetQObjectMessage.getObject(HornetQObjectMessage.java:158)
2012-01-26 12:04:47,451 ERROR [STDERR] at com.someapp.mdb.LogMessageProcessorBean.onMessage(LogMessageProcessorBean.java:34)
2012-01-26 12:04:47,452 ERROR [STDERR] at sun.reflect.GeneratedMethodAccessor398.invoke(Unknown Source)
2012-01-26 12:04:47,454 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
2012-01-26 12:04:47,455 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:597)
2012-01-26 12:04:47,455 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122)
{noformat}
So it looks like it is expecting to find a toLevel(int) method and isn't finding it. This is coming from the org.apache.log4j.spi.LoggingEvent class in the readLevel() method. This method has in its comments:
{code}
// Note that we use Class.getDeclaredMethod instead of
// Class.getMethod. This assumes that the Level subclass
// implements the toLevel(int) method which is a
// requirement. Actually, it does not make sense for Level
// subclasses NOT to implement this method. Also note that
// only Level can be subclassed and not Priority.
{code}
The jboss-logmanager code subclasses Level in the Log4jJDKLevel.java class (can be found here), but it does not implement the toLevel(int) method. So I used the git URL at the top of that page to clone the jboss-logmanager-log4j project and then made the following changes. I should note there that I'm not sure that this particlar patch does the right thing... I just modeled the method after one from the log4j source. After that I did a rebuild with maven.
{code}
diff --git a/src/main/java/org/jboss/logmanager/log4j/handlers/Log4jJDKLevel.java b/src/main/java/org/jboss/logmanager/log4j/handlers/Log4jJDKLevel.java
index 7e847a8..dcbf5ef 100644
--- a/src/main/java/org/jboss/logmanager/log4j/handlers/Log4jJDKLevel.java
+++ b/src/main/java/org/jboss/logmanager/log4j/handlers/Log4jJDKLevel.java
@@ -110,4 +110,26 @@ public final class Log4jJDKLevel extends Level {
final Level level = levelMapping.get(name.trim().toUpperCase());
return level != null ? level : Level.toLevel(name);
}
-}
\ No newline at end of file
+
+ public static Level toLevel(int val) {
+ switch(val) {
+ case Level.ALL_INT: return Level.ALL;
+ //case Level.DEBUG_INT: return Level.DEBUG;
+ //case Level.INFO_INT: return Level.INFO;
+ //case Level.WARN_INT: return Level.WARN;
+ //case Level.ERROR_INT: return Level.ERROR;
+ case Level.FATAL_INT: return Level.FATAL;
+ case Level.OFF_INT: return Level.OFF;
+ //case Level.TRACE_INT: return Level.TRACE;
+ case Level.ERROR_INT: return SEVERE;
+ case Level.WARN_INT: return WARNING;
+ case Level.INFO_INT: return INFO;
+ case (Level.INFO_INT - 5000): return CONFIG;
+ case Level.DEBUG_INT: return FINE;
+ case (Level.DEBUG_INT - 2500): return FINER;
+ case Level.TRACE_INT: return FINEST;
+ default: return INFO;
+ }
+ }
+}
+
{code}
After the build I replaced the jboss-logmangager-log4j.jar file in JBoss with the one I just build with maven. After this JBoss didn't see any errors in the MDB.
The 2nd consumer was a remote program that just connected to the JMS topic and consumed messages. This was pretty straightforward as its nothing more than a typical JMS client program. The only issue I had here was due to missing classes. Apparently when the jboss logging mechanism sends a logging event over to log4j it converts it to a ConvertedLoggingEvent object, and this class is not in the jboss-logging.jar client jar file (found in JB_HOME/client). This class is in the jboss-logmanager-log4j.jar file that I just rebuilt with maven and end up living in JB_HOME/common/lib. After adding that to my client program classpath it errored out with not finding the ExtLogRecord class. This one also is not in the client jar, but can be found in JB_HOME/lib/jboss-logmanager.jar. After getting those 2 additional jars (in addition to the typical jars needed for a JMS client program) in my classpath my client program works fine as well.
I've not done extensive testing with these changes, but so far its working well in my development environment. I'll attach the jboss-logmanager-log4j.jar file that was built with the toLevel(int) method along with the patch that you can use to roll your own jar. Hopefully this will help someone in the future!
Chris