Hi,
no, there was no PEAR involved.
The situation was something like that:
We have integration tests for components, which use some parent class
that initialized an JCas using JCasFactory in a threadlocal. Here,
uimaFIT created internally a new ResourceManager with an
UIMAClassLoader. Then, the test class has some fixtures, which creates
an aggregated analysis engine description for the annotator to test and
all of its required preprocessing analysis engines. Then, an analysis
engine is created. In this process, several ResourceManager are created
with their own UIMA ClassLoader. When the actual test calls the
process() method, two UIMAClassLoader survive and alternate for each
analysis engine. I am not sure which class loader, but I'd guess the one
of the JCas and the one of the aggregated analysis engine, as the
classloader for example of type priorities should not matter at all.
My problem was mainly that the symptoms were completely misleading. I
even checked the classloaders as I knew that could be a problem but they
were the same. I was looking to much in the sub map instead of the
actual map. I compared the wrong instance ids. Then, I also missed the
code "hidden" in the hasNext() method. -> bad debugging.
The solution for me was just to ensure that there is only one resource
manager used in the uimaFIT factories. A thing that is actually well
known to me. I simply added this before I create the JCas for the thread
local:
final ResourceManager resourceManager =
ResourceManagerFactory.newResourceManager();
ResourceManagerCreator resourceManagerCreator = new
ResourceManagerCreator() {
@Override
public ResourceManager newResourceManager() throws
ResourceInitializationException {
return resourceManager;
}
};
ResourceManagerFactory.setResourceManagerCreator(resourceManagerCreator);
Best,
Peter
Am 17.05.2017 um 20:32 schrieb Marshall Schor:
> This is usually due to the following use case:
>
> A pipeline is being run which has some components that are
> "classpath-isolated",
> by having them run as a PEAR.
>
> The PEAR implementation implements classpath isolation to allow things inside
> the PEAR to have different Java class definitions for identically-named java
> classes in the surrounding context. This includes JCas files (if any are
> defined within the PEAR.
>
> The result of this is that JCas class definitions that are defined within a
> PEAR
> cannot be seen outside of the PEAR (the actual Java class is "invisible" due
> to
> the classloader isolation). Just like you observed, the JCas cover class
> instance for these are created anew in the outer context, with the outer
> context
> definition of the JCas class.
>
> Is it possible (I don't know the details) that the inner uimaFIT analysis
> engine
> is running in a classpath isolation boundary, like a PEAR does?
>
> (Or perhaps, was the uimaFIT pipeline using a PEAR?)
>
> -Marshall
>
> On 5/16/2017 12:06 PM, Peter Kluegl wrote:
>> Hi,
>>
>>
>> I am currently stuck at a problem and do not find a way to debug it
>> successfully.
>>
>>
>> I have several analysis engines, some of them are ruta engines. In one
>> of them, another uimaFIT analysis engine is called/executed within the
>> rules. This causes somehow that the JCasGen annotation object are
>> created anew after the engine since no object is found in the submap. As
>> a result, the internal information of the RutaBasic annotations is lost.
>> I does not matter what the analysis engine does as it also happens if it
>> is empty, and it happens after the process method is called (The
>> RutaBasic annotation is still fine within the process method). I was not
>> able to identify the reason why the objects are required to be created
>> again.
>>
>> Can someone can give me a hint where/how I could debug it?
>>
>> What can influence the table in JCasHashMapSubMap?
>>
>>
>> I can provide more information what I already tried, e.g., it does not
>> seem to be a CL problem, but I was not able to create a small
>> reproducible example yet.
>>
>>
>> Best,
>>
>>
>> Peter
>>
>>
>>
