Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Tue, 20 Jun 2017 14:50:00 +0000 (UTC)
From: "Uwe Schindler (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: <JIRA.13078290.1496921931000.58882.1497970200086@Atlassian.JIRA>
In-Reply-To: <JIRA.13078290.1496921931000@Atlassian.JIRA>
References: <JIRA.13078290.1496921931000@Atlassian.JIRA> <JIRA.13078290.1496921931531@jira-lw-us.apache.org>
Subject: [jira] [Comment Edited] (LUCENE-7870) Use cl.loadClass(...) instead
 of Class.forName(..., cl) in SPIClassIterator
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Tue, 20 Jun 2017 14:50:06 -0000


    [ https://issues.apache.org/jira/browse/LUCENE-7870?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D160=
55874#comment-16055874 ]=20

Uwe Schindler edited comment on LUCENE-7870 at 6/20/17 2:49 PM:
----------------------------------------------------------------

Hi Andreas,
this issue should be solved in Lucene 7.0. We will not backport this as it =
breaks backwards compatibility: We no longer use the context class loader f=
or looking up services. It takes the class loader that defined the interfac=
e. If you require another one (e.g. in OSGI without using buddy classloadin=
g) you can call Codec.reloadCodecs(ClassLoader) and similar methods. See th=
e MIGRATE.txt in Lucene 7.


was (Author: thetaphi):
Hi Andreas,
this issue should be solved in Lucene 7.0. We will not backport this as it =
breaks backwards compatibility: We no longer use the context class loader f=
or looking up services. It takes the class loader that defined the interfac=
e. If you require another one (e.g. in OSGI without using buddy classloadin=
g) you can call Codec.reloadCodes(ClassLoader) and similar methods. See the=
 MIGRATE.txt in Lucene 7.

> Use cl.loadClass(...) instead of Class.forName(..., cl) in SPIClassIterat=
or
> -------------------------------------------------------------------------=
--
>
>                 Key: LUCENE-7870
>                 URL: https://issues.apache.org/jira/browse/LUCENE-7870
>             Project: Lucene - Core
>          Issue Type: Bug
>    Affects Versions: 5.2.1, 6.1
>         Environment: Eclipse Equinox 4.7
>            Reporter: Andreas Sewe
>
> This issue is initially described in [Eclipse Bug 517935|https://bugs.ecl=
ipse.org/bugs/show_bug.cgi?id=3D517935] and prevents multiple versions of L=
ucene Core coexisting in an Equinox environment (FYI, Equinox is the OSGi c=
ontainer used by the Eclipse IDE).
> Here=E2=80=99s how the problem manifests: While Equinox cleanly separates=
 two versions of the same Lucene Core bundle (e.g., {{org.apache.lucene.cor=
e_5.2.1}} and  {{org.apache.lucene.core_6.1.0}}) using two different bundle=
 class loaders, it uses a single context classloader for all threads: the [=
{{ContextFinder}}|https://wiki.eclipse.org/Context_Class_Loader_Enhancement=
s#Context_Finder_2]. When asked to load a class, the {{ContextFinder}} *ini=
tiates* a search through all bundle class loaders currently=C2=A0=E2=80=9Co=
n=E2=80=9C the call stack; the class to be loaded is then *defined* by the =
respective bundle=E2=80=99s class loader.
> And here is where the use of {{Class.forName(..., classLoader)}} rather t=
han {{classLoader.loadClass(...)}} causes problems. Consider the following =
sequence of events:
> # The {{NamedSPILoader}} of bundle {{o.a.l.core_5.2.1}} (re)loads some se=
rvice (e.g., the {{Lucene50PostingFormat}}).
> ## It (through {{SPIClassIterator}}) first uses {{Class.forName}} with th=
e bundle class loader of {{o.a.l.core_5.2.1}} (as per LUCENE-4713) to succe=
ssfully load {{Lucene50PostingFormat}} from the {{o.a.l.core_5.2.1}} bundle=
.
> ## Then (through another {{SPIClassIterator}}) it uses {{Class.forName}} =
with the thread=E2=80=99s context class loader (here: {{ContextFinder}}) to=
 load {{Lucene50PostingFormat}}. The {{ContextFinder}} delegates loading to=
 the {{o.a.l.core_5.2.1}} bundle=E2=80=99s class loader, as that bundle is =
topmost on the call stack. This bundle class loader (again) successfully lo=
ads {{Lucene50PostingFormat}} from the {{o.a.l.core_5.2.1}} bundle.
> # Later, the {{NamedSPILoader}} of *another* bundle {{o.a.l.core_6.1.0}} =
loads the {{Lucene50PostingFormat}} service.
> ## It (through {{SPIClassIterator}}) first uses {{Class.forName}} with th=
e bundle class loader of {{o.a.l.core_6.1.0}} to successfully load {{Lucene=
50PostingFormat}} from the {{o.a.l.core_6.1.0}} bundle.
> ## Then (through another {{SPIClassIterator}}) it uses {{Class.forName}} =
with the thread=E2=80=99s context class loader (the same {{ContextFinder}} =
again) to load {{Lucene50PostingFormat}}. As {{Class.forName}} remembers th=
at the {{ContextFinder}} has successfully initiated the loading of {{Lucene=
50PostingFormat}} before, it simply returns the {{Class}} instance defined =
earlier in step _1.2_. But that class was defined by a different bundle cla=
ss loader, namely that of {{o.a.l.core_5.2.1}}! This cache look up happens =
in native code; the {{ContextFinder}}=E2=80=98s {{loadClass}} method isn=E2=
=80=99t even called, so there=E2=80=99s no way it can load the class from t=
he {{o.a.l.core_6.1.0}} bundle, even though it now is topmost on the stack.
> ## Casting the {{Lucene50PostingFormat}} loading from bundle {{o.a.l.core=
_5.2.1}} to {{PostingFormat}} from bundle {{o.a.l.core_6.1.0}} then fails, =
leaving the {{o.a.l.core_6.1.0}} bundle in a broken state.
> It {{SPIClassIterator.next()}} would use {{classLoader.loadClass(...)}} r=
ather than {{Class.forName(..., classLoader}}), then class loading in step =
_1.2_ wouldn=E2=80=99t *lock in* the {{Lucene50PostingFormat}} class from {=
{org.apache.lucene.core_5.2.1}}; instead, step _2.2_ would perform a comple=
tely independent look up that retrieves the class from the correct bundle. =
The cast in step _2.3_ would then succeed.
> At Eclipse Orbit, we plan to distribute a [patched version|https://git.ec=
lipse.org/r/98804/] of Lucene Core, but obviously we would like to see the =
(one-line) change included in the upstream project.
> BTW, if you fear that bypassing {{Class.forName}} =E2=80=9Ccaching=E2=80=
=9D affects performance, then there=E2=80=99s no need to worry: Most {{Clas=
sLoader}} implementations cache as well ({{findLoadedClass}}); it=E2=80=99s=
 only {{ContextFinder}} that [overrides {{loadClass}} wholesale|https://git=
.eclipse.org/c/equinox/rt.equinox.framework.git/tree/bundles/org.eclipse.os=
gi/container/src/org/eclipse/osgi/internal/framework/ContextFinder.java?h=
=3DR4_7_maintenance], as it dynamically (based on the current call stack) d=
elegates to the (caching) bundle class loaders.


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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