Return-Path: X-Original-To: apmail-cxf-dev-archive@www.apache.org Delivered-To: apmail-cxf-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 AC8EB10E1A for ; Wed, 2 Apr 2014 16:48:59 +0000 (UTC) Received: (qmail 51519 invoked by uid 500); 2 Apr 2014 16:48:57 -0000 Delivered-To: apmail-cxf-dev-archive@cxf.apache.org Received: (qmail 51141 invoked by uid 500); 2 Apr 2014 16:48:56 -0000 Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cxf.apache.org Delivered-To: mailing list dev@cxf.apache.org Received: (qmail 51109 invoked by uid 99); 2 Apr 2014 16:48:54 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Apr 2014 16:48:54 +0000 X-ASF-Spam-Status: No, hits=-5.0 required=5.0 tests=RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of asoldano@redhat.com designates 209.132.183.28 as permitted sender) Received: from [209.132.183.28] (HELO mx1.redhat.com) (209.132.183.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Apr 2014 16:48:50 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s32GmLpv023756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 2 Apr 2014 12:48:21 -0400 Received: from localhost.localdomain (vpn1-7-112.ams2.redhat.com [10.36.7.112]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s32GmJ7U015298 for ; Wed, 2 Apr 2014 12:48:20 -0400 Message-ID: <533C3F4E.502@redhat.com> Date: Wed, 02 Apr 2014 18:48:14 +0200 From: Alessio Soldano User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: dev@cxf.apache.org Subject: Re: JAXWS client proxy classloading with CXF 3.0 References: <533BFBCA.3050309@redhat.com> <533C1D62.7080400@redhat.com> In-Reply-To: <533C1D62.7080400@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 X-Virus-Checked: Checked by ClamAV on apache.org For the records: https://issues.apache.org/jira/browse/CXF-5668 On 02/04/14 16:23, Alessio Soldano wrote: > Thanks, > will do soon. > > On 02/04/14 16:17, Daniel Kulp wrote: >> >> That seems reasonable to me. Feel free to apply it. >> >> >> Dan >> >> >> On Apr 2, 2014, at 8:00 AM, Alessio Soldano wrote: >> >>> Hi, >>> I've started testing the JBossWS integration with Apache CXF 3 and >>> I'm currently dealing with a classloading issue on client side. >>> A relevant difference between 2.7.x and 3 when it comes to JAXWS >>> client proxies is that on 3 they implement the >>> org.apache.cxf.endpoint.Client interface [1], while on 2.7.x they >>> don't. >>> When building up a JAXWS client, the >>> org.apache.cxf.common.util.ProxyHelper is used to decide which >>> classloader will later be passed to the JDK Proxy for building the >>> proxy instance. If the classloader that loaded the user service >>> class has visibility over all the interfaces the proxy has to >>> implement, that classloader is used, otherwise a ProxyClassloader is >>> built. The ProxyClassloader is basically a combination of the >>> classloaders that loaded each specific interface class. >>> Now, with Apache CXF 2.7.x, the user application needs to have >>> visibility over the JAX-WS api only, while with 3.0 it also needs to >>> "see" the Apache CXF classes, because of the check for >>> org.apache.cxf.endpoint.Client interface. When running JAX-WS >>> applications on WildFly using the JBossWS integration, the user is >>> not *required* to set a dependency to Apache CXF modules, even if >>> they're internally used to serve JAX-WS functionalities. For this >>> reason, the service class classloader, which is a JBoss Module >>> classloader, won't usually allow loading the >>> org.apache.cxf.endpoint.Client *directly* (that is is by doing >>> Class.forName("org.apache.cxf.endpoint.Client", true, loader)). For >>> this reason, the ProxyHelper will go the combined classloader approach. >>> The problem with such an approach on WildFly / JBoss AS is that >>> later the JDK Proxy will try to load the interfaces using the >>> ProxyClassloader, whose parent is the boot classloader. On recent >>> JDK version, the boot classloader is able to load the JAX-WS api >>> classes (because they're included in the JDK); however, the >>> javax.xml.ws.BindinProvider interface class that was retrieved from >>> the service class is a different class, having been loaded by a >>> specific module part of the service class classloader. This makes a >>> check fail in the JDK Proxy, effectively preventing creating the >>> jaxws client proxy. >>> To me, the CXF ProxyClassloader should have an explicit parent >>> classloader set to the same classloader instance that was provided >>> (the application classloader, that is the service class >>> classloader). That in turn *might* have the boot classloader as >>> parent (not in the case of JBoss / WildFly, due to the modular >>> approach). >>> If you have nothing against this, I'll create a JIRA and commit the >>> following patch: >>> >>> diff --git >>> a/core/src/main/java/org/apache/cxf/common/util/ProxyClassLoader.java b/core/src/main/java/org/apache/cxf/common/util/ProxyClassLoader.java >>> >>> index f7de519..c4baa17 100644 >>> --- >>> a/core/src/main/java/org/apache/cxf/common/util/ProxyClassLoader.java >>> +++ >>> b/core/src/main/java/org/apache/cxf/common/util/ProxyClassLoader.java >>> @@ -32,10 +32,12 @@ public class ProxyClassLoader extends ClassLoader { >>> private final Set loaders = new >>> HashSet(); >>> private boolean checkSystem; >>> >>> - public ProxyClassLoader() { >>> + public ProxyClassLoader(ClassLoader parent) { >>> + super(parent); >>> classes = null; >>> } >>> - public ProxyClassLoader(Class[] cls) { >>> + public ProxyClassLoader(ClassLoader parent, Class[] cls) { >>> + super(parent); >>> classes = cls; >>> } >>> >>> diff --git >>> a/core/src/main/java/org/apache/cxf/common/util/ProxyHelper.java >>> b/core/src/main/java/org/apache/cxf/common/util/ProxyHelper.java >>> index c252574..27f2c56 100644 >>> --- a/core/src/main/java/org/apache/cxf/common/util/ProxyHelper.java >>> +++ b/core/src/main/java/org/apache/cxf/common/util/ProxyHelper.java >>> @@ -58,7 +58,7 @@ public class ProxyHelper { >>> if (canSeeAllInterfaces(loader, interfaces)) { >>> return loader; >>> } >>> - ProxyClassLoader combined = new ProxyClassLoader(interfaces); >>> + ProxyClassLoader combined = new ProxyClassLoader(loader, >>> interfaces); >>> for (Class currentInterface : interfaces) { >>> combined.addLoader(currentInterface.getClassLoader()); >>> } >>> >>> Thanks >>> Alessio >>> >>> >>> >>> [1] >>> https://fisheye6.atlassian.com/changelog/cxf?cs=3898dbb3e29202c0d2942fb903fa29a7c16418a7 >>> >>> -- >>> Alessio Soldano >>> Web Service Lead, JBoss >>> > > -- Alessio Soldano Web Service Lead, JBoss