uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marshall Schor (JIRA)" <...@uima.apache.org>
Subject [jira] [Commented] (UIMA-6057) Avoid falsely switching classloader
Date Tue, 02 Jul 2019 13:04:00 GMT

    [ https://issues.apache.org/jira/browse/UIMA-6057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16876944#comment-16876944

Marshall Schor commented on UIMA-6057:

Hi, thanks fore 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 foo, but is run
in such a way that it has its own classloader.  
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.  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 them in the CAS

4) Now suppose the main pipeline wants to use those "results" - so it iterates over the cas
looking for that type, and attempts to assign any instance it finds to its JCas class Foo, 
e.g.  Foo myFoo = iterator.getNext();  The assignment will fail, saying class cast error
cannot cast "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, by intentionally
creating the "special" pipelines in a way that shares the class 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 - but it seem fragile
to me.  It's this case:

Same 1 and 2, but then add one more caveat - the main pipeline makes no reference at all to
any JCas class that will be loaded by the "special" pipeline, before calling it.  In that
case, the main pipeline has not loaded the shared JCas class, so when it finally gets around
to loading it, it will load the same one.   Another way to say this: the special pipeline
cannot define and load any JCas class that the main pipeline might have referred to before
running the special pipeline.

My current summary:
 * I think doing this change would be dangerous, and it would depend on behaviors in other
pipelines that might or might not be present.
 * There seems to be an easy, viable alternative (namely, letting the simple-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 switched before

This message was sent by Atlassian JIRA

View raw message