From dev-return-43008-apmail-uima-dev-archive=uima.apache.org@uima.apache.org Tue Jul 2 13:04:03 2019 Return-Path: X-Original-To: apmail-uima-dev-archive@www.apache.org Delivered-To: apmail-uima-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by minotaur.apache.org (Postfix) with SMTP id 23DB91982D for ; Tue, 2 Jul 2019 13:04:03 +0000 (UTC) Received: (qmail 4178 invoked by uid 500); 2 Jul 2019 13:04:02 -0000 Delivered-To: apmail-uima-dev-archive@uima.apache.org Received: (qmail 4156 invoked by uid 500); 2 Jul 2019 13:04:02 -0000 Mailing-List: contact dev-help@uima.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@uima.apache.org Delivered-To: mailing list dev@uima.apache.org Received: (qmail 4109 invoked by uid 99); 2 Jul 2019 13:04:02 -0000 Received: from mailrelay1-us-west.apache.org (HELO mailrelay1-us-west.apache.org) (209.188.14.139) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Jul 2019 13:04:02 +0000 Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 60660E062E for ; Tue, 2 Jul 2019 13:04:01 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id BBB992623F for ; Tue, 2 Jul 2019 13:04:00 +0000 (UTC) Date: Tue, 2 Jul 2019 13:04:00 +0000 (UTC) From: "Marshall Schor (JIRA)" To: dev@uima.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Comment Edited] (UIMA-6057) Avoid falsely switching classloader MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/UIMA-6057?page=3Dcom.atlassian.= jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D16876= 944#comment-16876944 ]=20 Marshall Schor edited comment on UIMA-6057 at 7/2/19 1:03 PM: -------------------------------------------------------------- Hi, thanks for responding; classloader things I find take a lot of thinking= :). Here's a failing use case that I'm worried about: 1) you have a main pipeline, it defines some JCas class Foo. 2) you have some other "special" pipeline, it too defines some JCas class f= oo, but is run in such a way that it has its own classloader.=C2=A0=20 Assuming it's using a Uima class loader, these have the property that they= first check if a class being requested to be loaded can be found in its se= t of URLs, and then only if it is not, does it delegate to its parent (whic= h typically would be the main pipeline's class loader.=C2=A0 This behavior = is intentional, to allow the special components to have its own versions of= classes that supersede those that might be found through its parent. 3) Now suppose the special pipeline makes some instances of Foo and puts th= em in the CAS 4) Now suppose the main pipeline wants to use those "results" - so it itera= tes over the cas looking for that type, and attempts to assign any instance= it finds to its JCas class Foo,=C2=A0 e.g.=C2=A0 Foo myFoo =3D iterator.ge= tNext();=C2=A0 The assignment will fail, saying class cast error cannot cas= t "Foo" to "Foo", which, besides being true, is a hard-to-understand error! This all can be avoided, if the intent is to share a common class loader, b= y intentionally creating the "special" pipelines in a way that shares the c= lass loader, so it seems (since as far as I can tell, that is the intent), = that would be the much better approach to fixing this issue. I think I do see one sub-case where the proposed change would work out - bu= t it seem fragile to me.=C2=A0 It's this case: Same 1 and 2, but then add one more caveat - the main pipeline makes no ref= erence at all to any JCas class that will be loaded by the "special" pipeli= ne, before calling it.=C2=A0 In that case, the main pipeline has not loaded= the shared JCas class, so when it finally gets around to loading it, it wi= ll load the same one.=C2=A0=C2=A0 Another way to say this: the special pipe= line cannot define and load any JCas class that the main pipeline might hav= e referred to before running the special pipeline. My current summary: * I think doing this change would be dangerous, and it would depend on beh= aviors in other pipelines that might or might not be present. * There seems to be an easy, viable alternative (namely, letting the simpl= e-pipeline run with the same classloader as the main, if sharing is wanted.= ) But I'm willing to be convinced depending on learning more about other use = cases... was (Author: schor): Hi, thanks fore responding; classloader things I find take a lot of thinkin= g :). Here's a failing use case that I'm worried about: 1) you have a main pipeline, it defines some JCas class Foo. 2) you have some other "special" pipeline, it too defines some JCas class f= oo, but is run in such a way that it has its own classloader.=C2=A0=20 Assuming it's using a Uima class loader, these have the property that they = first check if a class being requested to be loaded can be found in its set= of URLs, and then only if it is not, does it delegate to its parent (which= typically would be the main pipeline's class loader.=C2=A0 This behavior i= s intentional, to allow the special components to have its own versions of = classes that supersede those that might be found through its parent. 3) Now suppose the special pipeline makes some instances of Foo and puts th= em in the CAS 4) Now suppose the main pipeline wants to use those "results" - so it itera= tes over the cas looking for that type, and attempts to assign any instance= it finds to its JCas class Foo,=C2=A0 e.g.=C2=A0 Foo myFoo =3D iterator.ge= tNext();=C2=A0 The assignment will fail, saying class cast error cannot cas= t "Foo" to "Foo", which, besides being true, is a hard-to-understand error! This all can be avoided, if the intent is to share a common class loader, b= y intentionally creating the "special" pipelines in a way that shares the c= lass loader, so it seems (since as far as I can tell, that is the intent), = that would be the much better approach to fixing this issue. I think I do see one sub-case where the proposed change would work out - bu= t it seem fragile to me.=C2=A0 It's this case: Same 1 and 2, but then add one more caveat - the main pipeline makes no ref= erence at all to any JCas class that will be loaded by the "special" pipeli= ne, before calling it.=C2=A0 In that case, the main pipeline has not loaded= the shared JCas class, so when it finally gets around to loading it, it wi= ll load the same one.=C2=A0=C2=A0 Another way to say this: the special pipe= line cannot define and load any JCas class that the main pipeline might hav= e referred to before running the special pipeline. My current summary: * I think doing this change would be dangerous, and it would depend on beh= aviors in other pipelines that might or might not be present. * There seems to be an easy, viable alternative (namely, letting the simpl= e-pipeline run with the same classloader as the main, if sharing is wanted.= ) But I'm willing to be convinced depending on learning more about other use = cases... > Avoid falsely switching classloader > ----------------------------------- > > Key: UIMA-6057 > URL: https://issues.apache.org/jira/browse/UIMA-6057 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework > Reporter: Matthias Koch > Priority: Major > Attachments: UIMA-6057.diff > > > In some cases the classloader is switched back, although it hasn't be swi= tched before processing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)