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 <[email protected]> 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 <[email protected]> wrote:
>>
>>> On 8/25/2015 8:42 AM, Richard Eckart de Castilho wrote:
>>>> On 25.08.2015, at 12:00, Peter Klügl <[email protected]> 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
>
