Thanks, Ralph, for busting my theory of the case. :-) I built a test application, from one of the examples floating around on the Internet, added log4j2 to it, built the client and ran it on my server. It worked without incident, disproving my theory.
Ugh, now to figure out how to debug java.lang.NoClassDefFoundError. -----Original Message----- From: Apache [mailto:ralph.go...@dslextreme.com] Sent: Monday, January 16, 2017 10:43 AM To: Log4J Users List <log4j-user@logging.apache.org> Subject: Re: jboss-logging vs log4j2 in ejb-client application Can you provide a test application along with a link to the JBoss version you are using? I haven’t worked with JBoss in several years but would happy to take a look - if for no other reason than to do something with LOG4J2-18. Ralph > On Jan 16, 2017, at 9:11 AM, COHEN, STEVEN M <sc1...@att.com> wrote: > > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
