[
https://issues.apache.org/jira/browse/UIMA-6057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16865415#comment-16865415
]
Peter Klügl commented on UIMA-6057:
-----------------------------------
> I presume in some Ruta context, it is set false to block the switching back.
> Is that correct?
Yes. However, in our cases it's not only Ruta.
This switch is just one possible solution to the problem. It could also be
implemented with a stack of classloaders.
Here's an example where I first met the problem:
You have a ruta script that calls an additional uimaFIT analysis engine. You
create description for the RutaEngine and some other annotators and execute
them in SimplePipeline.iteratePipeline() without setting the resource manager
creator in the respective factory. Then, you will have different uima
classloader wrapper for the same classloader, for the JCas and the analysis
engines. This means that the framework will switch the classloader for every
analsysis engine which also replaces all JCas cover classes. As a result, Ruta
need to reindex its internal information all the time. Now, when Ruta calls an
additional engine from within the script, it can happen that a single JCas
cover class RutaBasic object is not updated in the index with the final result
that a single rule somewhere is now able to match correctly. I was not able yet
to identify the real source of this problem, but solved always the symptoms,
e.g., setting the creator in the factory avoiding the classloader switch.
Now for pears you have an actual classloader switch where this problem could
appear, but you also get class cast exceptions and other more serious problems
when a primitive analysis engine manages other engines.
> Avoid falsely switching classloader
> -----------------------------------
>
> Key: UIMA-6057
> URL: https://issues.apache.org/jira/browse/UIMA-6057
> Project: UIMA
> Issue Type: Bug
> Reporter: Matthias Koch
> Priority: Major
> Attachments: UIMA-6057.diff
>
>
> In some cases the classloader is switched back, although it hasn't be
> switched before processing.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
