Return-Path: X-Original-To: apmail-axis-java-dev-archive@www.apache.org Delivered-To: apmail-axis-java-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 2ED7EFA4B for ; Thu, 13 Nov 2014 10:03:34 +0000 (UTC) Received: (qmail 36521 invoked by uid 500); 13 Nov 2014 10:03:31 -0000 Delivered-To: apmail-axis-java-dev-archive@axis.apache.org Received: (qmail 36369 invoked by uid 500); 13 Nov 2014 10:03:31 -0000 Mailing-List: contact java-dev-help@axis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-dev@axis.apache.org Delivered-To: mailing list java-dev@axis.apache.org Received: (qmail 36359 invoked by uid 99); 13 Nov 2014 10:03:31 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 13 Nov 2014 10:03:31 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [195.245.230.173] (HELO mail1.bemta3.messagelabs.com) (195.245.230.173) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 13 Nov 2014 10:03:24 +0000 Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id D1/92-27623-5D184645; Thu, 13 Nov 2014 10:03:01 +0000 X-Env-Sender: ds@cdrator.com X-Msg-Ref: server-7.tower-31.messagelabs.com!1415872981!11075336!1 X-Originating-IP: [195.184.101.4] X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6864 invoked from network); 13 Nov 2014 10:03:01 -0000 Received: from unknown (HELO CDRSRVEX.cdrator.internal) (195.184.101.4) by server-7.tower-31.messagelabs.com with SMTP; 13 Nov 2014 10:03:01 -0000 Received: from CDRSRVEX.cdrator.internal ([127.0.0.1]) by CDRSRVEX ([127.0.0.1]) with mapi; Thu, 13 Nov 2014 11:03:01 +0100 From: Davide Silvestre To: "java-dev@axis.apache.org" Date: Thu, 13 Nov 2014 11:02:58 +0100 Subject: Issue with JarFileClassLoader.getResources() Thread-Topic: Issue with JarFileClassLoader.getResources() Thread-Index: Ac//JqDKhsB4vnciRRG/a97vRMy54AAAHKUwAAB4rjA= Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: Iu0= P78= qj4= AeDs B4ix CFcb EylE E8Ts F71r G9jG IIqX J7PE KSCj KqS6 KvVl Kwsk;1;agBhAHYAYQAtAGQAZQB2AEAAYQB4AGkAcwAuAGEAcABhAGMAaABlAC4AbwByAGcA;Sosha1_v1;7;{59116BCB-2B5A-484C-A771-FB3FCACE0D95};ZABzAEAAYwBkAHIAYQB0AG8AcgAuAGMAbwBtAA==;Thu, 13 Nov 2014 10:02:58 GMT;SQBzAHMAdQBlACAAdwBpAHQAaAAgAEoAYQByAEYAaQBsAGUAQwBsAGEAcwBzAEwAbwBhAGQAZQByAC4AZwBlAHQAUgBlAHMAbwB1AHIAYwBlAHMAKAApAA== x-cr-puzzleid: {59116BCB-2B5A-484C-A771-FB3FCACE0D95} acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D4EC96AC4947594DB8EA4A9CEEA957BA73FB515BDECDRSRVEX_" MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org --_000_D4EC96AC4947594DB8EA4A9CEEA957BA73FB515BDECDRSRVEX_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have an axis2 application (axis version 1.6.2 and Java7u51) that is inter= nally using the ServiceLoader. The ServiceLoader needs to retrieve the impl= ementation files as resouces from the META-INF/services folders inside any = of the jars. As the ServiceLoader is scanning the ContextClassLoader to retrieve this ki= nd of resources I have set the context class loader to be of type "service"= . In this way it will contain all the jars of the aar package. The classloader used is of type JarFileClassLoader and I think I have found= a bug in the findResources(String name) method. This method will load the resources from the parent classloader and from th= e classloader itself in an order that can be changed by configuration. When the resources are retrieved from the parent classloader then it is jus= t invoking: parent.getResources(name); When it tries to retrieve the resources from the urls of the classloader it= self then it invokes: super.findResources(name); and this will invoke the findResources(String name) implementation in the j= ava.net.URLClassLoader class. This method is not scanning directly the urls= of the classloader, but it delegates to an object of type URLClassPath tha= t is initialized in the constructor. The problem is that in the JarFileClassLoader the constuctor methods do inv= oke the super contructor in the URLClassLoader that has to initialize the U= RLClassPath, but it does that using an emtpy url array and not the original= array. public JarFileClassLoader(URL[] urls) { super(EMPTY_URLS); this.acc =3D AccessController.getContext(); addURLs(urls); } I also tried with different version of Java but because of this bug I am ne= ver able to successfully invoke getResources() or findResources() if I use = a JarFileClassLoader. Anybody has experieced the same? Is there a fix for this? Thanks Davide --_000_D4EC96AC4947594DB8EA4A9CEEA957BA73FB515BDECDRSRVEX_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I have an axis2 application (axis version 1.6.2 and Java7u51) that is internally using the ServiceLoader. The ServiceLoader nee= ds to retrieve the implementation files as resouces from the META-INF/services folders inside any of the jars.

As the ServiceLoader is scanning the ContextClassLoade= r to retrieve this kind of resources I have set the context class loader to be o= f type "service". In this way it will contain all the jars of the a= ar package.

The classloader used is of type JarFileClassLoader and= I think I have found a bug in the findResources(String name) method.

This method will load the resources from the parent classloader and from the classloader itself in an order that can be changed= by configuration.

 

When the resources are retrieved from the parent class= loader then it is just invoking:

parent.getResources(name);

 

When it tries to retrieve the resources from the urls = of the classloader itself then it invokes:

super.findResources(name);

and this will invoke the findResources(String name) implementation in the java.net.URLClassLoader class. This method is not scanning directly the urls of the classloader, but it delegates to an objec= t of type URLClassPath that is initialized in the constructor.

The problem is that in the JarFileClassLoader the cons= tuctor methods do invoke the super contructor in the URLClassLoader that has to initialize the URLClassPath, but it does that using an emtpy url array and = not the original array.

 

    public= JarFileClassLoader(URL[] urls) {

       = ; super<= /b>(<= span style=3D'font-size:10.0pt;font-family:Consolas;color:#0000C0'>EMPTY_URLS);

       = ; this.acc =3D AccessCont= roller.getContext();

       = ; addURLs(urls);

    }

 

I also tried with different version of Java but becaus= e of this bug I am never able to successfully invoke getResources() or findResou= rces() if I use a JarFileClassLoader.

 

Anybody has experieced the same? Is there a fix for th= is?

 

Thanks

Davide

--_000_D4EC96AC4947594DB8EA4A9CEEA957BA73FB515BDECDRSRVEX_--