[AXIS2-5792] EnableChildFirstClassLoading not working on Windows

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.6.3, 1.7.3
• Fix Version/s: 1.7.4
• Component/s: deployment
• Environment: Windows 8.1 x64 Prof., Tomcat 7.0.68, JDK 1.8.0_92 x64
• Assignee: Andreas Veithen
• Reporter: Thorsten Schöning
• Created: 25/Jun/16 06:31
• Updated: 02/Jul/16 15:44
• Resolved: 02/Jul/16 15:44

Description

I have a web service based on Axis2 1.6.3 currently and Axis2 provides httpcore-4.0. In my service I want to use HttpCore 4.4.5 and HttpClient 4.5.2 and both core packages provide the class BasicLineFormatter, but some classes new in HttpCore 4.4.5 need a newer version of that class than HttpCore 4.0 can provide. This leads to exceptions like the following:

Caused by: java.lang.NoSuchFieldError: INSTANCE
	at org.apache.http.impl.io.DefaultHttpRequestWriterFactory.<init>(DefaultHttpRequestWriterFactory.java:53)
	at org.apache.http.impl.io.DefaultHttpRequestWriterFactory.<init>(DefaultHttpRequestWriterFactory.java:57)
	at org.apache.http.impl.io.DefaultHttpRequestWriterFactory.<clinit>(DefaultHttpRequestWriterFactory.java:47)
	at org.apache.http.impl.conn.ManagedHttpClientConnectionFactory.<init>(ManagedHttpClientConnectionFactory.java:82)
	at org.apache.http.impl.conn.ManagedHttpClientConnectionFactory.<init>(ManagedHttpClientConnectionFactory.java:95)
	at org.apache.http.impl.conn.ManagedHttpClientConnectionFactory.<init>(ManagedHttpClientConnectionFactory.java:104)
	at org.apache.http.impl.conn.ManagedHttpClientConnectionFactory.<clinit>(ManagedHttpClientConnectionFactory.java:62)
	at org.apache.http.impl.conn.PoolingHttpClientConnectionManager$InternalConnectionFactory.<init>(PoolingHttpClientConnectionManager.java:572)
	at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.<init>(PoolingHttpClientConnectionManager.java:174)
	at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.<init>(PoolingHttpClientConnectionManager.java:158)
	at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.<init>(PoolingHttpClientConnectionManager.java:149)
	at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.<init>(PoolingHttpClientConnectionManager.java:125)
	at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.<init>(PoolingHttpClientConnectionManager.java:116)

Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.apache.http.impl.conn.ManagedHttpClientConnectionFactory
	at org.apache.http.impl.conn.PoolingHttpClientConnectionManager$InternalConnectionFactory.<init>(PoolingHttpClientConnectionManager.java:572)
	at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.<init>(PoolingHttpClientConnectionManager.java:174)
	at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.<init>(PoolingHttpClientConnectionManager.java:158)
	at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.<init>(PoolingHttpClientConnectionManager.java:149)
	at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.<init>(PoolingHttpClientConnectionManager.java:125)
	at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.<init>(PoolingHttpClientConnectionManager.java:116)

The problem is that when my service is about to be started, Axis2 used the BasicLineFormatter (indirectly) on its own already, loaded it and DeploymentClassLoader.loadClass finds that class in its own cache afterwards. This way the newer version of that class bundled with my service will never be used by default. Because the class is in the cache, using "EnableChildFirstClassLoading" doesn't change a thing here because the cache is always queried first.

I could work around that problem by changing the class loader of my service in ServiceLifeCycle.startUp: The new class loader is just another instance of DeploymentClassLoader which I put all the URLs needed for Jars and classes and such into, use "EnableChildFirstClassLoading" by default and provide the already available class loader as the new parent:

class WsAxis2SvcCl extends DeploymentClassLoader
[...]
	private static boolean shouldWrap(AxisService service)
	{
		String	paramValue = (String) service.getParameterValue("EnableSvcFirstClassLoading");
				paramValue = StringUtils.defaultIfBlank(paramValue, "false");

		if (!JavaUtils.isTrueExplicitly(paramValue.trim()))
		{
			return false;
		}

		return true;
	}
[...]
	protected WsAxis2SvcCl(	Set<URL>	urls,
							ClassLoader	parent)
	{
		super(urls.toArray(new URL[urls.size()]), null, parent, true);
	}
[...]
	static void wrapIf(AxisService service)
	{
		if (!WsAxis2SvcCl.shouldWrap(service))
		{
			return;
		}

		ClassLoader	origCl	= service.getClassLoader();
		Path		svcDir	= Axis2ServiceConf.getSvcDir(service);
		Set<URL>	clUrls	= ClNdClassLoaderUrlsProv.getUrlsRe(svcDir.toFile());
		ClassLoader	newCl	= new WsAxis2SvcCl(clUrls, origCl);

		service.setClassLoader(newCl);
	}

This way the classes and jars of my service are always considered first and only things not found in there are forwarded to the default Axis2 class loader used before. In the end, my classes using HttpCore 4.4.5 get their BasicLineFormatter and Axis2 keeps using its own. The "trick" is that DeploymentClassLoader.findLoadedClass only searches the current instance, no parent or such, and by providing a new instance I get a clean start for loading the service classes without interfering with the former already present Axis2 loader.

As I understand DeploymentClassLoader, such problems can't be addressed without another classloader like mine, so I woudl like to suggest exactly such an approach like I implemented now to be added. As I did already, one could configure the use of that class loader on a per service level and would therefore don't introduce any problems with backwards compatibility. If interested, I could provide more of my implementation.

Or is there any other approach I have missed to deal with same classes in incompatible versions like in my case?