You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Marshall Schor <ms...@schor.com> on 2016/08/18 21:16:24 UTC
Re: Deep classloader switching fails Ruta tests - some thoughts
Some other things to consider:
The way Ruta is using uimaFIT in the failing case results in multiple analysis
engines created with different resource managers, but the CAS from one is (I
think - didn't check this...) sent through the AE of another.
When multiple AEs are used this way with a common CAS, then the type system,
type priorities and indexes definition associated with this common CAS are used.
So it makes sense to share these parts of the Resource Manager.
And, if the intent is to have JCas cover classes produced by one of the AEs
usable by the other AEs, then there should not be extra UIMA Class loaders, and
class loader switching. This is because one of the things that class loader
switching does is to swap in/ out different JCasHashMaps. These are maps that
associated already created JCas instances with specific Cas Feature Structures.
This could be important, if the JCas instance was carrying along extra
information (not in the CAS) that you wanted shared with other
class-loading-contexts (e.g., an "outer" AE, or an "application").
-Marshall
Re: Deep classloader switching fails Ruta tests - some thoughts
Posted by Peter Klügl <pe...@averbis.com>.
ruta-core was built successfully on jenkins :-)
Am 19.08.2016 um 11:09 schrieb Peter Klgl:
> Thanks Richard, I forgot that there are no problems at all if I use
> uimaFIT "correctly".
>
>
> +1 I will adapt ruta to use descriptions
>
>
> I do already some stuff you mention below, but the part with the inlined
> analysis engines was a bit neglected.
>
>
> Best,
>
>
> Peter
>
>
> Am 19.08.2016 um 10:08 schrieb Richard Eckart de Castilho:
>> I have been thinking a bit about this.
>>
>>> On 19.08.2016, at 09:57, Peter Klgl <pe...@averbis.com> wrote:
>>>
>>> What are our options concerning the three projects? The functionality in
>>> ruta calling analysis engines is needed (preferable without switching in
>>> future).
>> With the present release versions of UIMA/uimaFIT, the following should
>> be done when creating analysis engines inside other analysis engines:
>>
>> // use createEngineDescription instead of createEngine
>> AnalysisEngineDescription aed = createEngineDescription(MyNestedAE.class);
>>
>> // Obtain resource manager from enclosing AE
>> ResourceManager mgr = ((UimaContextAdmin) getContext()).getResourceManager();
>>
>> // Use that resource manager when creating the actual engine
>> AnalysisEngine engine = UIMAFramework.produceAnalysisEngine(aed, mgr, null);
>>
>>> Yes, uimaFIT should not create a resource manager, or at least there
>>> should be an option to reuse a given one...
>> There is no uimaFIT method for this because it can easily be
>> accomplished using UIMAFramework.
>>
>>> or at least a given classloader. The switching is somewhat problematic
>>> for me and Ruta, but did not cause too serious problems yet.
>> You could also do that by creating your own resource manager and using
>> it when creating the engine:
>>
>> ResourceManager resMgr = UIMAFramework.newDefaultResourceManager();
>> resMgr.setExtensionClassPath(myClassLoader, "", true);
>>
>>> There is of course ResourceManagerFactory.setResourceManagerCreator().
>>> With this, I could delegate the existing/ruta resource manager to the
>>> uimaFIT factories, but I do not know if I should really do this in a
>>> static manner.
>> I don't think that makes sense in this case. I added that function in
>> case somebody wants to use uimaFIT with the original UIMA behavior
>> (i.e. without using the Thread context classloader) or to experiment
>> with other classloading scenarios.
>>
>> What do you think?
>>
>> Cheers,
>>
>> -- Richard
>>
>>
Re: Deep classloader switching fails Ruta tests - some thoughts
Posted by Peter Klügl <pe...@averbis.com>.
Thanks Richard, I forgot that there are no problems at all if I use
uimaFIT "correctly".
+1 I will adapt ruta to use descriptions
I do already some stuff you mention below, but the part with the inlined
analysis engines was a bit neglected.
Best,
Peter
Am 19.08.2016 um 10:08 schrieb Richard Eckart de Castilho:
> I have been thinking a bit about this.
>
>> On 19.08.2016, at 09:57, Peter Klgl <pe...@averbis.com> wrote:
>>
>> What are our options concerning the three projects? The functionality in
>> ruta calling analysis engines is needed (preferable without switching in
>> future).
>
> With the present release versions of UIMA/uimaFIT, the following should
> be done when creating analysis engines inside other analysis engines:
>
> // use createEngineDescription instead of createEngine
> AnalysisEngineDescription aed = createEngineDescription(MyNestedAE.class);
>
> // Obtain resource manager from enclosing AE
> ResourceManager mgr = ((UimaContextAdmin) getContext()).getResourceManager();
>
> // Use that resource manager when creating the actual engine
> AnalysisEngine engine = UIMAFramework.produceAnalysisEngine(aed, mgr, null);
>
>> Yes, uimaFIT should not create a resource manager, or at least there
>> should be an option to reuse a given one...
>
> There is no uimaFIT method for this because it can easily be
> accomplished using UIMAFramework.
>
>> or at least a given classloader. The switching is somewhat problematic
>> for me and Ruta, but did not cause too serious problems yet.
>
> You could also do that by creating your own resource manager and using
> it when creating the engine:
>
> ResourceManager resMgr = UIMAFramework.newDefaultResourceManager();
> resMgr.setExtensionClassPath(myClassLoader, "", true);
>
>> There is of course ResourceManagerFactory.setResourceManagerCreator().
>> With this, I could delegate the existing/ruta resource manager to the
>> uimaFIT factories, but I do not know if I should really do this in a
>> static manner.
> I don't think that makes sense in this case. I added that function in
> case somebody wants to use uimaFIT with the original UIMA behavior
> (i.e. without using the Thread context classloader) or to experiment
> with other classloading scenarios.
>
> What do you think?
>
> Cheers,
>
> -- Richard
>
>
Re: Deep classloader switching fails Ruta tests - some thoughts
Posted by Richard Eckart de Castilho <re...@apache.org>.
I have been thinking a bit about this.
> On 19.08.2016, at 09:57, Peter Klügl <pe...@averbis.com> wrote:
>
> What are our options concerning the three projects? The functionality in
> ruta calling analysis engines is needed (preferable without switching in
> future).
With the present release versions of UIMA/uimaFIT, the following should
be done when creating analysis engines inside other analysis engines:
// use createEngineDescription instead of createEngine
AnalysisEngineDescription aed = createEngineDescription(MyNestedAE.class);
// Obtain resource manager from enclosing AE
ResourceManager mgr = ((UimaContextAdmin) getContext()).getResourceManager();
// Use that resource manager when creating the actual engine
AnalysisEngine engine = UIMAFramework.produceAnalysisEngine(aed, mgr, null);
> Yes, uimaFIT should not create a resource manager, or at least there
> should be an option to reuse a given one...
There is no uimaFIT method for this because it can easily be
accomplished using UIMAFramework.
> or at least a given classloader. The switching is somewhat problematic
> for me and Ruta, but did not cause too serious problems yet.
You could also do that by creating your own resource manager and using
it when creating the engine:
ResourceManager resMgr = UIMAFramework.newDefaultResourceManager();
resMgr.setExtensionClassPath(myClassLoader, "", true);
> There is of course ResourceManagerFactory.setResourceManagerCreator().
> With this, I could delegate the existing/ruta resource manager to the
> uimaFIT factories, but I do not know if I should really do this in a
> static manner.
I don't think that makes sense in this case. I added that function in
case somebody wants to use uimaFIT with the original UIMA behavior
(i.e. without using the Thread context classloader) or to experiment
with other classloading scenarios.
What do you think?
Cheers,
-- Richard
Re: Deep classloader switching fails Ruta tests - some thoughts
Posted by Peter Klügl <pe...@averbis.com>.
Yes, uimaFIT should not create a resource manager, or at least there
should be an option to reuse a given one... or at least a given
classloader. The switching is somewhat problematic for me and Ruta, but
did not cause too serious problems yet.
There is of course ResourceManagerFactory.setResourceManagerCreator().
With this, I could delegate the existing/ruta resource manager to the
uimaFIT factories, but I do not know if I should really do this in a
static manner.
I do not know if we should/need support multiple levels of nesting.
What are our options concerning the three projects? The functionality in
ruta calling analysis engines is needed (preferable without switching in
future). The next uimaFIT release is not planned yet, right? If we keep
the exception in uimaj before the switching is addressed in uimaFIT,
then I have a serious problem in Ruta.
Best,
Peter
Am 19.08.2016 um 07:53 schrieb Richard Eckart de Castilho:
> Hm, I think this could also be addressed via the UimaContextHolder that was
> discussed elsewhere. uimaFIT could check if there is an active context
> and re-use its resource manager instead of creating a new one.
>
> What do you think?
>
> Cheers,
>
> -- Richard
>
>> On 18.08.2016, at 23:16, Marshall Schor <ms...@schor.com> wrote:
>>
>> Some other things to consider:
>>
>> The way Ruta is using uimaFIT in the failing case results in multiple analysis
>> engines created with different resource managers, but the CAS from one is (I
>> think - didn't check this...) sent through the AE of another.
>>
>> When multiple AEs are used this way with a common CAS, then the type system,
>> type priorities and indexes definition associated with this common CAS are used.
>> So it makes sense to share these parts of the Resource Manager.
>>
>> And, if the intent is to have JCas cover classes produced by one of the AEs
>> usable by the other AEs, then there should not be extra UIMA Class loaders, and
>> class loader switching. This is because one of the things that class loader
>> switching does is to swap in/ out different JCasHashMaps. These are maps that
>> associated already created JCas instances with specific Cas Feature Structures.
>> This could be important, if the JCas instance was carrying along extra
>> information (not in the CAS) that you wanted shared with other
>> class-loading-contexts (e.g., an "outer" AE, or an "application").
>>
>> -Marshall
Re: Deep classloader switching fails Ruta tests - some thoughts
Posted by Richard Eckart de Castilho <re...@apache.org>.
Hm, I think this could also be addressed via the UimaContextHolder that was
discussed elsewhere. uimaFIT could check if there is an active context
and re-use its resource manager instead of creating a new one.
What do you think?
Cheers,
-- Richard
> On 18.08.2016, at 23:16, Marshall Schor <ms...@schor.com> wrote:
>
> Some other things to consider:
>
> The way Ruta is using uimaFIT in the failing case results in multiple analysis
> engines created with different resource managers, but the CAS from one is (I
> think - didn't check this...) sent through the AE of another.
>
> When multiple AEs are used this way with a common CAS, then the type system,
> type priorities and indexes definition associated with this common CAS are used.
> So it makes sense to share these parts of the Resource Manager.
>
> And, if the intent is to have JCas cover classes produced by one of the AEs
> usable by the other AEs, then there should not be extra UIMA Class loaders, and
> class loader switching. This is because one of the things that class loader
> switching does is to swap in/ out different JCasHashMaps. These are maps that
> associated already created JCas instances with specific Cas Feature Structures.
> This could be important, if the JCas instance was carrying along extra
> information (not in the CAS) that you wanted shared with other
> class-loading-contexts (e.g., an "outer" AE, or an "application").
>
> -Marshall