OK, so missing or conflicting logging between my client code and JBoss's client library is not the CAUSE of the NoClassDefFoundError.
Still, maybe it would be useful to see the logging emitted by the JBoss EJB Client library code, in an attempt to find the cause. The JBoss EJB Client library code has import org.jboss.logging.Logger; This is an abstract class. I previously said that JBoss does not support log4j2 but this may not be entirely true. I notice in looking at the JBoss source code, a class called org.jboss.logging.Log4j2Logger, which extends org.jboss.logging.Logger. Now how do I make use of this? This Hibernate document provided what I needed to know: http://docs.jboss.org/hibernate/orm/4.3/topical/html/logging/Logging.html Since version 4.0, Hibernate has used the JBoss Logging library for its logging needs. Like SLF4J and Jakarta’s commons-logging, JBoss Logging is a "logging bridge" providing integration with numerous logging frameworks. JBoss Logging was chosen because of its i18n support and its support for "message ids". This is largely the seminal documentation of JBoss Logging since JBoss Logging currently provides no documentation of its own. Supported Back-ends JBoss Logging understands the following back-ends as first-class citizens: JBoss LogManager (mainly used only inside the WildFly app server) Log4j 2 Log4j 1 Slf4j JDK logging And voila, the logging output by JBoss showed me what I needed to see to solve my problem. Very useful, and not in the general JBoss documentation, as far as I could see. -----Original Message----- From: Apache [mailto:[email protected]] Sent: Monday, January 16, 2017 2:16 PM To: Log4J Users List <[email protected]> Subject: Re: jboss-logging vs log4j2 in ejb-client application That can be tough to solve because frequently you will get a NoClassDefFoundError on Class A even though it is there because it has a reference to Class B or something in Class B and it isn’t there. Unfortunately, the JVM isn’t very good about letting you know what is actually missing. Ralph > On Jan 16, 2017, at 12:25 PM, COHEN, STEVEN M <[email protected]> wrote: > > 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:[email protected]] > Sent: Monday, January 16, 2017 10:43 AM > To: Log4J Users List <[email protected]> > 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 <[email protected]> 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: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
