Log4j error when using Botsing

[MaelAudren]

Characteristics

• Issue Type: [bug, test report]
• Reproducibility: [always]
• Severity: [minor]
• Tool/Service/Component: [Botsing, v1.0.3]
• Execution Environment: [Ubuntu 18.04]
• Reporter: [Mael Audren, [email protected]]

Description

Error logs appears in Botsing during its run.

log4j:ERROR A "org.apache.log4j.ConsoleAppender" object is not assignable to a "org.apache.log4j.Appender" variable.
log4j:ERROR The class "org.apache.log4j.Appender" was loaded by 
log4j:ERROR [org.evosuite.instrumentation.InstrumentingClassLoader@7408eac5] whereas object of type 
log4j:ERROR "org.apache.log4j.ConsoleAppender" was loaded by [org.gradle.internal.classloader.MutableURLClassLoader@3d646c37].
log4j:ERROR Could not instantiate appender named "CONSOLE".

Steps to reproduce

https://github.com/STAMP-project/evocrash-usecases-output/tree/master/Activeeon/Botsing/v1.0.3/scheduling

Other files and URLs

Log file: https://github.com/STAMP-project/evocrash-usecases-output/blob/master/Activeeon/Botsing/v1.0.3/scheduling/SpaceNotFoundException/SpaceNotFound.log

[xdevroey]

Hi @MaelAudren,

From the error message, there seems to be a conflict in the classloaders. The same class loaded by two different class loaders. The shadowing performed when building the project (introduced in botsing-1.0.3) addresses this problem.

I saw that there is now also a shadowing step in the Gradle build, but it does not seem to work properly. When building the plugin with Gradle. I decompressed the fat .jar file and the packages are not relocated to avoid conflicts in the class loaders.

I think this https://imperceptiblethoughts.com/shadow/configuration/relocation/#filtering-relocation and the list of relocated packages might help:

botsing/pom.xml

Lines 288 to 399 in fb6e611

	<relocations>
	<relocation>
	<pattern>org.objectweb.asm</pattern>
	<shadedPattern>org.evosuite.shaded.org.objectweb.asm</shadedPattern>
	</relocation>
	<relocation>
	<pattern>org.hibernate</pattern>
	<shadedPattern>org.evosuite.shaded.org.hibernate</shadedPattern>
	</relocation>
	<relocation>
	<pattern>org.hsqldb</pattern>
	<shadedPattern>org.evosuite.shaded.org.hsqldb</shadedPattern>
	</relocation>
	<relocation>
	<pattern>org.jboss</pattern>
	<shadedPattern>org.evosuite.shaded.org.jboss</shadedPattern>
	</relocation>
	<relocation>
	<pattern>org.springframework</pattern>
	<shadedPattern>org.evosuite.shaded.org.springframework</shadedPattern>
	</relocation>
	<relocation>
	<pattern>org.apache.commons.logging</pattern>
	<shadedPattern>org.evosuite.shaded.org.apache.commons.logging</shadedPattern>
	</relocation>
	<relocation>
	<pattern>javassist</pattern>
	<shadedPattern>org.evosuite.shaded.javassist</shadedPattern>
	</relocation>
	<relocation>
	<pattern>antlr</pattern>
	<shadedPattern>org.evosuite.shaded.antlr</shadedPattern>
	</relocation>
	<relocation>
	<pattern>org.antlr</pattern>
	<shadedPattern>org.evosuite.shaded.org.antlr</shadedPattern>
	</relocation>
	<relocation>
	<pattern>org.dom4j</pattern>
	<shadedPattern>org.evosuite.shaded.org.dom4j</shadedPattern>
	</relocation>
	<!--
	<relocation>
	<pattern>org.xml</pattern>
	<shadedPattern>org.evosuite.shaded.org.xml</shadedPattern>
	</relocation>
	<relocation>
	<pattern>org.w3c</pattern>
	<shadedPattern>org.evosuite.shaded.org.w3c</shadedPattern>
	</relocation>
	-->
	<relocation>
	<pattern>org.aopalliance</pattern>
	<shadedPattern>org.evosuite.shaded.org.aopalliance</shadedPattern>
	</relocation>
	<relocation>
	<pattern>org.mockito</pattern>
	<shadedPattern>org.evosuite.shaded.org.mockito</shadedPattern>
	</relocation>
	<relocation>
	<pattern>net.bytebuddy</pattern>
	<shadedPattern>org.evosuite.shaded.net.bytebuddy</shadedPattern>
	</relocation>
	<relocation>
	<!-- This is special. Originally we wanted to handle it directly, but
	did not turn out to be a good idea. However, too early to remove
	that code, so we just shade this package to avoid backward
	compatibility issues
	-->
	<pattern>javax.servlet</pattern>
	<shadedPattern>org.evosuite.shaded.javax.servlet</shadedPattern>
	</relocation>
	<relocation>
	<pattern>org.apache</pattern>
	<shadedPattern>org.evosuite.shaded.org.apache</shadedPattern>
	<excludes>
	<!-- Important, otherwise AntInitializingListener would not work in Ant -->
	<exclude>org.apache.tools.ant.taskdefs.optional.junit.JUnitResultFormatter</exclude>
	<exclude>org.apache.tools.ant.taskdefs.optional.junit.JUnitTest</exclude>
	<exclude>org.apache.tools.ant.BuildException</exclude>
	<exclude>org.apache.logging.log4j.core.config.plugins.processor.PluginProcessor</exclude>
	</excludes>
	</relocation>
	<relocation>
	<pattern>org.hamcrest</pattern>
	<shadedPattern>org.evosuite.shaded.org.hamcrest</shadedPattern>
	</relocation>
	<relocation>
	<pattern>org.objenesis</pattern>
	<shadedPattern>org.evosuite.shaded.org.objenesis</shadedPattern>
	</relocation>
	<relocation>
	<pattern>be.vibes</pattern>
	<shadedPattern>org.evosuite.shaded.be.vibes</shadedPattern>
	</relocation>
	<relocation>
	<pattern>be.yami</pattern>
	<shadedPattern>org.evosuite.shaded.be.yami</shadedPattern>
	</relocation>
	<relocation>
	<pattern>com.google</pattern>
	<shadedPattern>org.evosuite.shaded.com.google</shadedPattern>
	</relocation>
	<!--<relocation>-->
	<!--<pattern>org.slf4j</pattern>-->
	<!--<shadedPattern>org.evosuite.shaded.org.slf4j</shadedPattern>-->
	<!--</relocation>-->
	<!--<relocation>-->
	<!--<pattern>ch.qos.logback</pattern>-->
	<!--<shadedPattern>org.evosuite.shaded.ch.qos.logback</shadedPattern>-->
	<!--</relocation>-->
	</relocations>

[MaelAudren]

@xdevroey thanks for the help. How do you know if a package is reallocated or not ?

[xdevroey]

I saw it by decompressing the fat .jar file produced by the plugin and checking that the directories tree does not contain the original packages hierarchy.

In the example I provided, you have the package prefix and the relocation (in org.evosuite.shaded). I strongly recommend you keep that same name because the EvoSuite library seems to have some hardcoded packages names comparison.

The Gradle plugin you are using seems to follow the same usage pattern as Maven (cf. link to the documentation).

[MaelAudren]

@xdevroey Those errors also appears when I launch Botsing manually however they are absolutely not the cause of the Botsing crash. The crash was provoked by an issue on the plugin I have just misunderstood the logs. I have updated the description to reflect better the issue.