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 > > >
