Load jars only from package

[niemand23 (N 23)]

Hi there,

I have the task of migrating a custom webMethods adapter from 9.9 to 10.7 and have some issues when compiling the Java code as I get below error message:

com.wm.app.b2b.server.ServiceException: java.lang.NoClassDefFoundError: Could not initialize class org.apache.commons.configuration.FileSystem

In the code/jars location I have following jars: commons-configuration-1.10.jar, commons-lang.jar, commons-logging.jar, log4j.jar (beside the jar having the code for the custom adapter)

I also added below entry in the manifest.v3 file so that the jars from /code/jars are loaded first:

<value name="classloader">package</value>

However, it is still not working.

After an extended investigation, I extracted the exact code which throws the exception in a Java service and also wrapped it inside a try catch block to extract the Throwable info:

try{
		FileSystem fileSystem = FileSystem.getDefaultFileSystem();
		}
		catch(Throwable t){
			throw new ServiceException(t);
		}

Below you have the real error detail that I managed to get when running the Java service on the 10.7 server:
Caused by: org.apache.commons.logging.LogConfigurationException: The chosen LogFactory implementation does not extend LogFactory. Please check your configuration. (Caused by java.lang.ClassCastException: The application has specified that a custom LogFactory implementation should be used but Class 'org.apache.logging.log4j.jcl.LogFactoryImpl' cannot be converted to 'org.apache.commons.logging.LogFactory'. The conflict is caused by the presence of multiple LogFactory classes in incompatible classloaders.

On the 9.9 server, the same Java service works.

Could this be caused because of the built in log4j jars found on the global server classpaths on the 10.7 server? If so, is there a setting so that at runtime only the jars from code/jars are to be taken into consideration?

Best regards,
n23

[Holger_von_Thomsen]

Hi,

in general all jars which are only used by this package (and its dependents) should be placed under code/jars of this package as long as they do not have native dependents.

While some commons jars were updated or newly introduced in or to the global classpath it should be checked they can be removed from the package itself and just rely on the current versions being present in the global classpath.

Beside this it should be checked if log4j can be migrated to log4j2.

Might be an option to check if there is a newer version of your custom API jar for this adapter as well.

Cascading Exceptions here:
org.apache.commons.configuration.FileSystem is not found as it seems to rely on the LogFactory which could not be loaded due to the incompatible classloader issue.

Regards,
Holger

[Nagendra_Prasad]

Found an explanation , Apache Commons Logging - Troubleshooting Guide , section The Incompatible LogFactory Issue.
As a possible solution , it talks about using another classloading policy which I believe is already being done here. Posting the link in the hope that someone else can make more sense of this than I could

-NP

[niemand23 (N 23)]

Hi guys,

Thanks for the hints I have solved it by removing jar commons-logging.jar from code/jars.

Br,
23

[Nagendra_Prasad]

Great to know! Please mark your post as the solution for this topic ,may help others in the future.