Mailing-List: contact java-dev-help@axis.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@axis.apache.org
Date: Sat, 2 Jul 2016 15:45:11 +0000 (UTC)
From: "Andreas Veithen (JIRA)" <jira@apache.org>
To: java-dev@axis.apache.org
Message-ID: <JIRA.12983007.1466836319000.12246.1467474311057@Atlassian.JIRA>
In-Reply-To: <JIRA.12983007.1466836319000@Atlassian.JIRA>
References: <JIRA.12983007.1466836319000@Atlassian.JIRA> <JIRA.12983007.1466836319888@arcas>
Subject: [jira] [Resolved] (AXIS2-5792) EnableChildFirstClassLoading not
 working on Windows
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Sat, 02 Jul 2016 15:45:13 -0000


     [ https://issues.apache.org/jira/browse/AXIS2-5792?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andreas Veithen resolved AXIS2-5792.
------------------------------------
       Resolution: Fixed
         Assignee: Andreas Veithen
    Fix Version/s: 1.7.4

> EnableChildFirstClassLoading not working on Windows
> ---------------------------------------------------
>
>                 Key: AXIS2-5792
>                 URL: https://issues.apache.org/jira/browse/AXIS2-5792
>             Project: Axis2
>          Issue Type: Bug
>          Components: deployment
>    Affects Versions: 1.6.3, 1.7.3
>         Environment: Windows 8.1 x64 Prof., Tomcat 7.0.68, JDK 1.8.0_92 x=
64
>            Reporter: Thorsten Sch=C3=B6ning
>            Assignee: Andreas Veithen
>             Fix For: 1.7.4
>
>         Attachments: AXIS2-5792 src 1.7.3.zip, AXIS2-5792 src.zip, Axis2_=
5792 1.7.3.zip, Axis2_5792.zip
>
>
> I have a web service based on Axis2 1.6.3 currently and Axis2 provides ht=
tpcore-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 clas=
ses 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:
> {CODE}
> Caused by: java.lang.NoSuchFieldError: INSTANCE
> =09at org.apache.http.impl.io.DefaultHttpRequestWriterFactory.<init>(Defa=
ultHttpRequestWriterFactory.java:53)
> =09at org.apache.http.impl.io.DefaultHttpRequestWriterFactory.<init>(Defa=
ultHttpRequestWriterFactory.java:57)
> =09at org.apache.http.impl.io.DefaultHttpRequestWriterFactory.<clinit>(De=
faultHttpRequestWriterFactory.java:47)
> =09at org.apache.http.impl.conn.ManagedHttpClientConnectionFactory.<init>=
(ManagedHttpClientConnectionFactory.java:82)
> =09at org.apache.http.impl.conn.ManagedHttpClientConnectionFactory.<init>=
(ManagedHttpClientConnectionFactory.java:95)
> =09at org.apache.http.impl.conn.ManagedHttpClientConnectionFactory.<init>=
(ManagedHttpClientConnectionFactory.java:104)
> =09at org.apache.http.impl.conn.ManagedHttpClientConnectionFactory.<clini=
t>(ManagedHttpClientConnectionFactory.java:62)
> =09at org.apache.http.impl.conn.PoolingHttpClientConnectionManager$Intern=
alConnectionFactory.<init>(PoolingHttpClientConnectionManager.java:572)
> =09at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.<init>=
(PoolingHttpClientConnectionManager.java:174)
> =09at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.<init>=
(PoolingHttpClientConnectionManager.java:158)
> =09at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.<init>=
(PoolingHttpClientConnectionManager.java:149)
> =09at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.<init>=
(PoolingHttpClientConnectionManager.java:125)
> =09at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.<init>=
(PoolingHttpClientConnectionManager.java:116)
> {CODE}
> {CODE}
> Caused by: java.lang.NoClassDefFoundError: Could not initialize class org=
.apache.http.impl.conn.ManagedHttpClientConnectionFactory
> =09at org.apache.http.impl.conn.PoolingHttpClientConnectionManager$Intern=
alConnectionFactory.<init>(PoolingHttpClientConnectionManager.java:572)
> =09at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.<init>=
(PoolingHttpClientConnectionManager.java:174)
> =09at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.<init>=
(PoolingHttpClientConnectionManager.java:158)
> =09at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.<init>=
(PoolingHttpClientConnectionManager.java:149)
> =09at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.<init>=
(PoolingHttpClientConnectionManager.java:125)
> =09at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.<init>=
(PoolingHttpClientConnectionManager.java:116)
> {CODE}
> The problem is that when my service is about to be started, Axis2 used th=
e BasicLineFormatter (indirectly) on its own already, loaded it and Deploym=
entClassLoader.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 "EnableChildFirst=
ClassLoading" doesn't change a thing here because the cache is always queri=
ed first.
> I could work around that problem by changing the class loader of my servi=
ce in ServiceLifeCycle.startUp: The new class loader is just another instan=
ce of DeploymentClassLoader which I put all the URLs needed for Jars and cl=
asses and such into, use "EnableChildFirstClassLoading" by default and prov=
ide the already available class loader as the new parent:
> {CODE}
> class WsAxis2SvcCl extends DeploymentClassLoader
> [...]
> =09private static boolean shouldWrap(AxisService service)
> =09{
> =09=09String=09paramValue =3D (String) service.getParameterValue("EnableS=
vcFirstClassLoading");
> =09=09=09=09paramValue =3D StringUtils.defaultIfBlank(paramValue, "false"=
);
> =09=09if (!JavaUtils.isTrueExplicitly(paramValue.trim()))
> =09=09{
> =09=09=09return false;
> =09=09}
> =09=09return true;
> =09}
> [...]
> =09protected WsAxis2SvcCl(=09Set<URL>=09urls,
> =09=09=09=09=09=09=09ClassLoader=09parent)
> =09{
> =09=09super(urls.toArray(new URL[urls.size()]), null, parent, true);
> =09}
> [...]
> =09static void wrapIf(AxisService service)
> =09{
> =09=09if (!WsAxis2SvcCl.shouldWrap(service))
> =09=09{
> =09=09=09return;
> =09=09}
> =09=09ClassLoader=09origCl=09=3D service.getClassLoader();
> =09=09Path=09=09svcDir=09=3D Axis2ServiceConf.getSvcDir(service);
> =09=09Set<URL>=09clUrls=09=3D ClNdClassLoaderUrlsProv.getUrlsRe(svcDir.to=
File());
> =09=09ClassLoader=09newCl=09=3D new WsAxis2SvcCl(clUrls, origCl);
> =09=09service.setClassLoader(newCl);
> =09}
> {CODE}
> This way the classes and jars of my service are always considered first a=
nd 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 B=
asicLineFormatter and Axis2 keeps using its own. The "trick" is that Deploy=
mentClassLoader.findLoadedClass only searches the current instance, no pare=
nt 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 Ax=
is2 loader.
> As I understand DeploymentClassLoader, such problems can't be addressed w=
ithout another classloader like mine, so I woudl like to suggest exactly su=
ch an approach like I implemented now to be added. As I did already, one co=
uld configure the use of that class loader on a per service level and would=
 therefore don't introduce any problems with backwards compatibility. If in=
terested, 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?


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org