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 56DE3F129 for ; Thu, 25 Apr 2013 16:38:28 +0000 (UTC) Received: (qmail 92555 invoked by uid 500); 25 Apr 2013 16:38:28 -0000 Delivered-To: apmail-cxf-dev-archive@cxf.apache.org Received: (qmail 92498 invoked by uid 500); 25 Apr 2013 16:38:28 -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 92490 invoked by uid 99); 25 Apr 2013 16:38:27 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 25 Apr 2013 16:38:27 +0000 Received: from localhost (HELO mail-wi0-f169.google.com) (127.0.0.1) (smtp-auth username coheigea, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Thu, 25 Apr 2013 16:38:27 +0000 Received: by mail-wi0-f169.google.com with SMTP id h11so9437838wiv.4 for ; Thu, 25 Apr 2013 09:38:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=Ad4uK3LGHapZl+QDl3yCbM/Mi5FGrk64OStqTeDFfQk=; b=FKLYK6iuP/rSQmormWtS1XjsUMfhPEFjwUi0nxIDhK4V14TbAfcgPjqElpGo+22eMN xzWjDuWYoqg1Hnzk2tPcCTvcgdCKzyK7N4ryNC0g201WGlnMSOVOJRvla3A8XsyEe9d6 GXmPw2bOk8hof3/xt43iPKBhyTz417QKjled5UUn6A0+MpfvDfiXYWbpDDLbBI0cb4RG W1+uZpTr/3aMPt0zjmwbxZZj0EDz2+c5dyXxySFcJ9HXK60L4zzC+mwS2UiWsNeQTX8D 5YnLJ8rD4L54pEOyybLbAwG0JDq9ARODbT0iln8XR2vJOIaVJNgPV95irFQIktKSNyEA BCVw== MIME-Version: 1.0 X-Received: by 10.194.103.72 with SMTP id fu8mr76883247wjb.42.1366907906132; Thu, 25 Apr 2013 09:38:26 -0700 (PDT) Reply-To: coheigea@apache.org Received: by 10.195.18.36 with HTTP; Thu, 25 Apr 2013 09:38:26 -0700 (PDT) In-Reply-To: <5177B2C3.2060708@redhat.com> References: <5177B2C3.2060708@redhat.com> Date: Thu, 25 Apr 2013 17:38:26 +0100 Message-ID: Subject: Re: On classloading and EH-Cache availability checks From: Colm O hEigeartaigh To: "dev@cxf.apache.org" Content-Type: multipart/alternative; boundary=089e010d86102f922304db320c4c --089e010d86102f922304db320c4c Content-Type: text/plain; charset=ISO-8859-1 Hi Alessio, No objections here. Colm. On Wed, Apr 24, 2013 at 11:24 AM, Alessio Soldano wrote: > Hi, > I think I might have noticed an issue (at least in my environment) with > the way EHCache availability checks are performed in ReplayCacheFactory > and TokenStoreFactory. The ClassLoaderUtils#loadClass method is used in > static blocks for checking if a class from EHCache is available; if > that's the case, a EHCache-based factory will later be used when a new > instance is required. Now, the factory instance is actually built using > the defining classloader of the ReplayCacheFactory / TokenStoreFactory > class, despite the EHCache availability check having been performed > using the current Thread context classloader (TCCL) first. If EHCache is > visible in the TCCL that is set when initialising the abstract classes > and not visible in their defining classloader, the newInstance > invocation will fail. > I would suggest performing the EHCache availability check using the > defining classloader only in the static block; additionally, if we > really want to try relying on stuff coming from the TCCL only, we could > perform a new check on it when actually required to build a newInstance > and actually use the TCCL to build the EHCache based factory through > reflection. > Any opinion on this? > Cheers > Alessio > > -- > Alessio Soldano > Web Service Lead, JBoss > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com --089e010d86102f922304db320c4c--