uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: JCas cover class instance fields, classloaders and uimaFIT
Date Tue, 01 Sep 2015 13:11:38 GMT
I'm not against using the context class loader appropriately; can someone draft
a proposed change to support this?  I suspect the devil is in the details (if
you know that turn of phrase :-) ).


On 8/28/2015 2:56 PM, Richard Eckart de Castilho wrote:
> On 28.08.2015, at 20:09, Marshall Schor <msa@schor.com> wrote:
>> On 8/25/2015 8:42 AM, Richard Eckart de Castilho wrote:
>>> On 25.08.2015, at 12:00, Peter Kl├╝gl <peter.kluegl@averbis.com> wrote:
>>>> The problems are gone... I should learn how to use uimaFIT correctly. Oh
>>>> dear, so much trouble for nothing...
>>>> On the other hand, this will not solve my problems when I enforce the
>>>> usage of Ruta as a java library. However, I think I can take care of the
>>>> upcoming problems on the Ruta side of the code, e.g., with the factory
>>>> you mentioned.
>>> @Marshall: would it really be (so) bad to change UIMA to use a Thread
>>> classloader if one is defined?
>> I vaguely recall some previous discussion about it; see uima.markmail.org and
>> search on thread classloader.
>> A concern I have is that the Thread classloader use is sort of by convention,
>> perhaps depending on the framework you might be embedding into (I'm not an
>> expert here, so please feel free to correct!); because of this, I think UIMA
>> intentionally takes the approach of having this be "outside" the UIMA
>> framework.  I think at some point we added an api to allow an embedding to set
>> the class loader to use, and it could of course use the thread local one.
> I'm not sure what your reservations against taking the context classloader
> into account are. I've been googling around a bit and that confirms what I
> was already thinking: it is a commonly used mechanism all over the place.
> It allows a calling function to provide the called function with access 
> to its classloading context even through caller and callee come from different
> classloaders. 
> Here is one article on this:
> http://www.z2-environment.net/blog/2012/07/for-techies-protecting-java-in-a-modular-world-context-classloaders/
> In fact, I do believe that using the context classloader could even be the
> better approach for UIMA instead of juggling around with PEAR classloaders etc.
> Since I don't know what reservations you have exactly, I also don't know how
> to refute them. But maybe a glance at the article linked above might give
> you some more context on the context classloaders ;)
> Cheers,
> -- Richard

View raw message