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 2017/05/26 19:50:20 UTC
looking for possible issues in fixing
https://issues.apache.org/jira/browse/UIMA-5435
https://issues.apache.org/jira/browse/UIMA-5435 fixes the getResources() API of
the UIMAClassLoader to look first in its own loader, and then, if not found, to
delegate to its parent class loader.
This, it was already doing for classes. I think this is the proper behavior for
getResources() too, since the intent is to allow classpath isolation (e.g., used
by PEARs), and that should work also for getting resources.
But, it represents a behavior change; does anyone know of any cases where this
will be an issue? I'm a bit reluctant to add a
-Duima.keep_wrong_classloader_behavior_for_uimaclassloader kind of backwards
compatible switch if it won't really be needed...
Cheers. -Marshall
Re: looking for possible issues in fixing
https://issues.apache.org/jira/browse/UIMA-5435
Posted by Marshall Schor <ms...@schor.com>.
good idea :-) - Marshall
On 5/27/2017 3:58 PM, Richard Eckart de Castilho wrote:
> How about adding this switch only if anybody complains?
>
> -- Richard
>
>> On 26.05.2017, at 21:50, Marshall Schor <ms...@schor.com> wrote:
>>
>> https://issues.apache.org/jira/browse/UIMA-5435 fixes the getResources() API of
>> the UIMAClassLoader to look first in its own loader, and then, if not found, to
>> delegate to its parent class loader.
>>
>> This, it was already doing for classes. I think this is the proper behavior for
>> getResources() too, since the intent is to allow classpath isolation (e.g., used
>> by PEARs), and that should work also for getting resources.
>>
>> But, it represents a behavior change; does anyone know of any cases where this
>> will be an issue? I'm a bit reluctant to add a
>> -Duima.keep_wrong_classloader_behavior_for_uimaclassloader kind of backwards
>> compatible switch if it won't really be needed...
>>
>> Cheers. -Marshall
>>
>
Re: looking for possible issues in fixing https://issues.apache.org/jira/browse/UIMA-5435
Posted by Richard Eckart de Castilho <re...@apache.org>.
How about adding this switch only if anybody complains?
-- Richard
> On 26.05.2017, at 21:50, Marshall Schor <ms...@schor.com> wrote:
>
> https://issues.apache.org/jira/browse/UIMA-5435 fixes the getResources() API of
> the UIMAClassLoader to look first in its own loader, and then, if not found, to
> delegate to its parent class loader.
>
> This, it was already doing for classes. I think this is the proper behavior for
> getResources() too, since the intent is to allow classpath isolation (e.g., used
> by PEARs), and that should work also for getting resources.
>
> But, it represents a behavior change; does anyone know of any cases where this
> will be an issue? I'm a bit reluctant to add a
> -Duima.keep_wrong_classloader_behavior_for_uimaclassloader kind of backwards
> compatible switch if it won't really be needed...
>
> Cheers. -Marshall
>