Our team is fairly standardized on using log4j2 over log4j, commons-logging or any other framework.
This had presented some issues with jboss-eap which does not support log4j2. Nevertheless, for applications running on the jboss-server it was fairly easy, and even a good thing to package log4j2 as a jboss module and do all our application logging through that. Let JBoss use jboss-logging for its internal use. I believe this pattern has now broken down over a standalone client application that talks to the EJBs we deploy on another server. Although I can easily put log4j2 on the runtime classpath of this application, the client libraries that one must also include in order to talk to JBoss, need jboss-logging. So I have both sets of jars on my classpath. I believe that this has resulted in java.lang.NoClassDefFoundError: Could not initialize class org.jboss.ejb.client.EJBClientContext errors at runtime. I am not sure that the logging conflict is the reason, but at this point I am "liking" this theory as my #1 suspect. I have looked at all the dependency graphs and find that nothing is missing, so what else could it be? I could switch to log4j1 for the client app, but some of our code must run on jboss so that isn't a good solution. Is there a standard way to handle this that I could try to prevent any conflicts? --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
