[
https://issues.apache.org/jira/browse/UIMA-6057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16876761#comment-16876761
]
Peter Klügl commented on UIMA-6057:
-----------------------------------
It's maybe better to put the SimplePipeline aside. It's just a situation where
the problem can occur, but it also easily solvable in three different spots.
Let me try to summarize the scenario from my perspective.
You have a pipeline with different components. Some of them are "special" as
they initialize additional components within their implementation. They are not
aggregated analysis engines, they are still simple anlaysis engines. These
components also call the process() method for executing the internal analysis
engines (which can of course again delegate to others). There are different
reasons why one should create those "special" components, e.g., rapid
prototyping in Ruta, Java functionality in Ruta, complex parameter mapping,
external resource management and so on. This approach is not supported by the
framework, but it does not cause any problems *IF* there is not class loader
switch. The switch can happen for different reasons, e.g., the JCas and the
analysis engines have been created using different UIMA class loader wrappers
for the same class loader, which is the example of simple-pipline in uimaFIT
(not really a problem anymore). However, the switch will happen if PEARs are
involved. Then, the wrong class loader is set and class cast exceptions and so
on will be thrown.
I think the problem is easily solved by extending the logic for the class
loader switching a bit, e.g., with the patch, or by using a class loader stack
or similar solutions.
What do you think?
> 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 processing.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
