Note that there are some explanatory texts on larger screens.

plurals
  1. POjava.lang.LinkageError on jBoss while running app with log4j custom layout class
    primarykey
    data
    text
    <p>I am trying to configure a custom layout class to Log4J as described in <a href="https://stackoverflow.com/questions/2461726/how-to-mask-credit-card-numbers-in-log-files-with-log4j">my previous post</a>. The class uses <code>java.util.regex.Matcher</code> to identify potential credit card numbers in log messages. It works perfectly in unit tests, also in a minimal web app containing a single servlet. However when I try to deploy it with our app in JBoss, I get the following error:</p> <pre><code>--- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM --- ObjectName: jboss.web.deployment:war=MyWebApp-2010_02-SNAPSHOT.war,id=476602902 State: FAILED Reason: java.lang.LinkageError: java/util/regex/Matcher </code></pre> <p>I couldn't even find any info on this form of the error - typically LinkageError seems to show up with a "loader constrain violation" message, like in <a href="https://stackoverflow.com/questions/244482/how-to-deal-with-linkageerrors-in-java">here</a>.</p> <p>Technical details: we use JBoss 4.2, Java 5, Log4J 1.2.12. We deploy our app in an .ear, which contains (among others) the above mentioned .war file, and the custom layout class in a separate jar file (let's call it Commons). We override the default settings in <code>jboss-log4j.xml</code> with our own <code>log4j.properties</code> located in a different folder, which is added to the classpath at startup, and is provided via <a href="http://carbon.sourceforge.net/" rel="nofollow noreferrer">Sapient's Carbon framework</a>.</p> <p><strong>Update</strong> to @skaffman's answer:</p> <p>The reason we have a separate log4j.properties file is the scheme propagated by Sapient Carbon. This basically decouples the configuration and data files from the application server environment, so that they are accessible via Carbon's lookup functionality and they can be stored in a directory external to the app server. We inherited this setup, and we hate it because it causes us lots of trouble with deployment, classpath issues etc. since it does not adhere to the JEE conventions. We aim to get rid of it in the long run, but it's gonna take time :-(</p> <p>Even though the separate log4j.properties file is not best practice, it certainly works. It has been functioning in our app for years, and I could also make it work with a minimalist web app containing a single servlet (not using Sapient Carbon). If log4j.properties is put into the classpath, Log4J reads it properly when the web app is launched, and reconfigures logging accordingly.</p> <p><strong>Update#2:</strong> An interesting finding is that <code>Matcher</code> is not even used in MyWebApp, only in the Commons module (and another module, in a separate jar). In Commons, it has been used before, in a class called StringHelper, which is used indirectly by MyWebApp, via other modules.</p> <p>I guess this rules out the possibility of two different Matcher class versions loaded by different classloaders. So my only remaining guess is that Matcher is loaded by two different classloaders when it is used from the jar and the war, and then attempted to pass from one to the other. This is explained by <a href="http://frankkieviet.blogspot.com/2009/03/javalanglinkageerror-loader-constraint.html" rel="nofollow noreferrer">Frank Kieviet's excellent article</a>. However, I believe that such a setup would cause a "loader constraint violation" rather than this form of the error.</p> <p><strong>Update#3: If I add <a href="http://www.redhat.com/docs/manuals/jboss/jboss-eap-4.2/doc/Server_Configuration_Guide/LinkageErrors___Making_Sure_You_Are_Who_You_Say_You_Are-Debugging_Class_Loading_Issues.html#Debugging_Class_Loading_Issues-An_example_log4j.xml_configuration_fragment_for_enabling_verbose_class_loading_logging" rel="nofollow noreferrer">this appender (example 3.8)</a> to jboss-log4j.xml, the error disappears, and the server runs perfectly</strong> :-o This obviously has to do something with loading log4j.jar, because this setup requires the jar to be present in the server lib directory. It works also if I change the appender type to <code>org.jboss.logging.appender.FileAppender</code>, and set log level to <code>WARN</code>, which results in an empty <code>ucl.log</code> file. This may suit as a temporary workaround, but I am still eager to fully understand what's going on here.</p> <p><strong>What does this error message mean, and how can I fix it properly?</strong></p> <hr> <h2>Epilogue</h2> <p>After a long wait, I finally got to eliminate Carbon from the logging process and migrate our logging config into <code>server/conf/jboss-log4j.xml</code>. This required that I publish our custom log filter class in a separate jar in the <code>server/lib</code> directory. After this, the class loading works again, without the workaround described in Update#3 above :-)</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload