0

We tried adding Rampart to our module's POM file and after doing so our ear can no longer start with the following exception:

java.lang.IllegalAccessError: tried to access method org.apache.log4j.Logger.<init>(Ljava/lang/String;)V from class org.apache.log4j.spi.RootLogger
        at org.apache.log4j.spi.RootLogger.<init>(RootLogger.java:43)
        at org.apache.log4j.LogManager.<clinit>(LogManager.java:78)
        at org.apache.log4j.xml.XMLWatchdog.doOnChange(DOMConfigurator.java:862)
        at org.apache.log4j.helpers.FileWatchdog.checkAndConfigure(FileWatchdog.java:88)
        at org.apache.log4j.helpers.FileWatchdog.<init>(FileWatchdog.java:57)
        at org.apache.log4j.xml.XMLWatchdog.<init>(DOMConfigurator.java:853)
        at org.apache.log4j.xml.DOMConfigurator.configureAndWatch(DOMConfigurator.java:584)

org.apache.log4j.Logger is defined in two jars - log4j and log4j-over-slf4j. In log4j - there is a constructor:

protected Logger(String name)

In log4j-over-slf4j there is a constructor:

Logger(String name) //Package access only

It seems that for some reason Rampart triggered a bad classpath order and placed log4j-over-slf4j before log4j.

However, the most troubling problem is that we were unable to change our ear's manifest to change the order - so eventually we "solved" it by adding the log4j jar to the System Classpath

My question has two parts:

  1. Is the Rampart problem familiar and does it have a solution?
  2. What reason could it be that changing the manifest of the ear would not effect the classpath? (I'm not that experienced with application servers - so obvious answers are welcome)

We are using Weblogic 10.3, and Rampart 1.5.1. We are using Maven to compile and build the ear file - and I just learned today of a mar file, so any inputs about that will also be welcomed.

RonK
  • 9,472
  • 8
  • 51
  • 87

2 Answers2

2

log4j-over-slf4j is replacement of log4j that proxies to slf4j. This means in your class path you have classes with same name and package, but very different implementation.

Since you use log4j in your system, it is safe to remove log4j-over-slf4j. in that case the library that needs log4j-over-slf4j will actually use the original log4j.

Op De Cirkel
  • 28,647
  • 6
  • 40
  • 53
  • Thanks for the clarification - the problem is that we can't remove `log4j-over-slf4j`, it comes from a 3rd party we must use. – RonK Jun 02 '11 at 11:59
  • I had the same issue and this solved my problem. I think it's the correct solution. OP's log4j-over-slf4j can probably be excluded via the pom file. – jewbix.cube Sep 02 '20 at 00:37
2

Eventually we modified the pom.xml manually and changed the order of dependencies to put log4j before rampart - which solved the classpath order problem.

RonK
  • 9,472
  • 8
  • 51
  • 87
  • I believe even though your log4j-over-slf4j comes from a third-party dependency, you should be able to exclude transitive dependencies via the pom file. – jewbix.cube Sep 02 '20 at 00:39