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 Mon, 14 Sep 2015 19:36:05 GMT
Re: the phase 2 and the UIMAClassLoader.

When this is created, the code creating it gets to specify the parent class.

I'm wondering if that's the right time / place to stick in additional defaulting
along the lines you suggest. I think, for instance, that PEAR classloader
isolation would work better (it relies on the parent being the outer pipeline's
classloader, whatever that may be, and that is set up when the PEAR wrapper is
initialized, if I recall correctly).

One aspect of using the Context Class Loader by default is that any code can
change this, per Thread (assuming it has security permissions).   (Even
retrieving the ContextClassLoader requires security permissions.)

Also, I'm not sure it's a good idea to use the Application class loader if the
context class loader is not set, in preference to the UIMAClassLoader's parent;
this could break some class path isolation a user might have intended to set up
(assuming they were not using the ContextClassLoader conventions).

-Marshall


On 9/1/2015 9:25 AM, Richard Eckart de Castilho wrote:
> On a first throw, I'd approach this with a two phase refactoring
>
> Phase 1: factor out classloading
>
> I searched for "classloader" in the code and found quite a few occurrences.
> Not all of them appear to be relevant through (e.g. getters, setters, CL usage
> in CAS). The relevant places appear to be where an appropriate classloader is
> chosen. So we have several places like this
>
>       // get UIMA extension ClassLoader if available
>       final ClassLoader cl = getUimaContextAdmin().getResourceManager().getExtensionClassLoader();
>
>       if (cl != null) {
>         // use UIMA extension ClassLoader to load the class
>         annotatorClass = cl.loadClass(annotatorClassName);
>       } else {
>         // use application ClassLoader to load the class
>         annotatorClass = Class.forName(annotatorClassName);
>       } 
>
> So first, I'd propose creating a utility method that is called that basically
> covers the lines above. Optionally, such a method could be added directly into the
> resource manager (e.g. RM.getClassloader());
>
> Of course I only did a very superficial scan right now just to get the idea rolling.
>
>
> Phase 2: add support for context classloader
>
> Hopefully after phase 1 we'd have a reduced the places that handle the choosing of a
classloader.
> At that point, I'd extend the "else" case above to use the context classloader if available,
> otherwise the application classloader. 
>
> Likewise, the code of the UimaClassloader would at that point be changed to take the
context classloader
> into account. I guess the appropriate place to inject it would be if a class cannot be
found in the
> extension classpath and before forwarding to super.loadClass().
>
>
> Is there anything obvious that I missed (very likely)? ;)
>
> Cheers,
>
> -- Richard
>
> On 01.09.2015, at 15:11, Marshall Schor <msa@schor.com> wrote:
>
>> 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 :-) ).
>>
>> -Marshalol
>>
>> 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
>


Mime
View raw message