You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Richard Eckart de Castilho <re...@apache.org> on 2015/03/24 23:13:43 UTC
Cannot set resource manager on RootUimaContext
Hi all,
I wonder... what is the point of having a method allowing to initialize
a UimaContext with a resource manager if in fact the code is commented out?
See RootUimaContext_impl
public void initializeRoot(Logger aLogger, ResourceManager aResourceManager,
ConfigurationManager aConfigurationManager) {
mLogger = aLogger;
// mResourceManager = aResourceManager;
// mConfigurationManager = aConfigurationManager;
mSession = new Session_impl();
}
Cheers,
-- Richard
Re: Cannot set resource manager on RootUimaContext
Posted by Marshall Schor <ms...@schor.com>.
On 3/26/2015 6:54 PM, Richard Eckart de Castilho wrote:
> On 26.03.2015, at 23:06, Marshall Schor <ms...@schor.com> wrote:
>> On 3/25/2015 10:34 AM, Richard Eckart de Castilho wrote:
>>> Thanks for the explanation. With this change, however, it is not possible anymore
>>> to create a customized RootUimaContext with a custom resource manager.
>>>
>>> Admittedly, my case (which I didn't explain yet) is a freak case and should probably
>>> also be fixed elsewhere... my workaround now is to create an anonymous instance
>>> in which I override getResourceManager()...
>>>
>>> Yet, I would still propose to introduce a constructor which allows to create
>>> instances of this class based on pre-existing resource / configuration managers.
>> Ok, can you propose a change that will work for you and still keep these fields
>> "final"?
> I'm sure you had a very good reason for passing these values as thread-locals to a
> 0-args constructor. Would you object to introducing an additional 2-args constructor?
The reason for the 0 arg constructor is rooted in history and the
configurability of UIMA, I think.
The way that class is instantiated is via the (static) newUimaContext call in
UimaContextAdmin class.
This is part of the top-level configurability supplied by the UIMAFramework
class. This mechanism
reads (at startup) a mapping from uima things to java impl classes from the file
(in uimaj-core/src/main/resources/org/apache/uima/impl/) factoryConfig.xml.
There you'll see the mapping uimaContext to the class ...RootUimaContext_impl.
The implementation of this factory mechanism uniformly instantiates those
classes using a 0-argument constructor.
(That's where the the requirement for a 0 argument constructor comes from). So
if you have "final" values
that need to be passed in, you have to use a trick...
That doesn't prevent other constructors, though - so having an additional
2-argument constructor would be OK,
although it implies that the caller is "bypassing" possible
reconfiguration/customization that might be being
done via altering the factoryConfig.xml file of that installation.
(You'll notice that there are no direct references (at least in uimaj-core
project) to the RootUimaContext_impl class.)
-Marshall
>
> Cheers,
>
> -- Richard
>
Re: Cannot set resource manager on RootUimaContext
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 26.03.2015, at 23:06, Marshall Schor <ms...@schor.com> wrote:
>
> On 3/25/2015 10:34 AM, Richard Eckart de Castilho wrote:
>> Thanks for the explanation. With this change, however, it is not possible anymore
>> to create a customized RootUimaContext with a custom resource manager.
>>
>> Admittedly, my case (which I didn't explain yet) is a freak case and should probably
>> also be fixed elsewhere... my workaround now is to create an anonymous instance
>> in which I override getResourceManager()...
>>
>> Yet, I would still propose to introduce a constructor which allows to create
>> instances of this class based on pre-existing resource / configuration managers.
>
> Ok, can you propose a change that will work for you and still keep these fields
> "final"?
I'm sure you had a very good reason for passing these values as thread-locals to a
0-args constructor. Would you object to introducing an additional 2-args constructor?
Cheers,
-- Richard
Re: Cannot set resource manager on RootUimaContext
Posted by Marshall Schor <ms...@schor.com>.
On 3/25/2015 10:34 AM, Richard Eckart de Castilho wrote:
> Thanks for the explanation. With this change, however, it is not possible anymore
> to create a customized RootUimaContext with a custom resource manager.
>
> Admittedly, my case (which I didn't explain yet) is a freak case and should probably
> also be fixed elsewhere... my workaround now is to create an anonymous instance
> in which I override getResourceManager()...
>
> Yet, I would still propose to introduce a constructor which allows to create
> instances of this class based on pre-existing resource / configuration managers.
Ok, can you propose a change that will work for you and still keep these fields
"final"?
-Marshall
>
>
> Cheers,
>
> -- Richard
>
> On 25.03.2015, at 15:29, Marshall Schor <ms...@schor.com> wrote:
>
>> The mResourceManager and mConfigurationManager initialization were changed a few
>> releases ago as part of the work to make this area more thread safe, in support
>> of multi-threaded read-only access to a shared CAS.
>>
>> These variables were made "final", and the comment for RootUimaContext_impl says
>> (I hope it's correct :-) ) that making these final causes a memory barrier to be
>> inserted for them which in turn makes other access to them "safe" from other
>> threads without further synchronization.
>>
>> The method "initializeRoot" is in a package ending with the word "impl", which
>> says this is an internal implementation method, not part of the exposed API.
>> It's public because it is defined in the UimaContextAdmin "interface" and all
>> interface-style methods need to be public.
>>
>> I think this is left-over stuff from that earlier change in the way these two
>> things were initialized. I think the method and the interface should probably
>> be updated to remove these two arguments. (But that's low priority...)
>>
>> -Marshall
>>
>> On 3/24/2015 6:13 PM, Richard Eckart de Castilho wrote:
>>> Hi all,
>>>
>>> I wonder... what is the point of having a method allowing to initialize
>>> a UimaContext with a resource manager if in fact the code is commented out?
>>>
>>> See RootUimaContext_impl
>>>
>>> public void initializeRoot(Logger aLogger, ResourceManager aResourceManager,
>>> ConfigurationManager aConfigurationManager) {
>>> mLogger = aLogger;
>>> // mResourceManager = aResourceManager;
>>> // mConfigurationManager = aConfigurationManager;
>>> mSession = new Session_impl();
>>> }
>>>
>>> Cheers,
>>>
>>> -- Richard
>
Re: Cannot set resource manager on RootUimaContext
Posted by Richard Eckart de Castilho <re...@apache.org>.
Thanks for the explanation. With this change, however, it is not possible anymore
to create a customized RootUimaContext with a custom resource manager.
Admittedly, my case (which I didn't explain yet) is a freak case and should probably
also be fixed elsewhere... my workaround now is to create an anonymous instance
in which I override getResourceManager()...
Yet, I would still propose to introduce a constructor which allows to create
instances of this class based on pre-existing resource / configuration managers.
Cheers,
-- Richard
On 25.03.2015, at 15:29, Marshall Schor <ms...@schor.com> wrote:
> The mResourceManager and mConfigurationManager initialization were changed a few
> releases ago as part of the work to make this area more thread safe, in support
> of multi-threaded read-only access to a shared CAS.
>
> These variables were made "final", and the comment for RootUimaContext_impl says
> (I hope it's correct :-) ) that making these final causes a memory barrier to be
> inserted for them which in turn makes other access to them "safe" from other
> threads without further synchronization.
>
> The method "initializeRoot" is in a package ending with the word "impl", which
> says this is an internal implementation method, not part of the exposed API.
> It's public because it is defined in the UimaContextAdmin "interface" and all
> interface-style methods need to be public.
>
> I think this is left-over stuff from that earlier change in the way these two
> things were initialized. I think the method and the interface should probably
> be updated to remove these two arguments. (But that's low priority...)
>
> -Marshall
>
> On 3/24/2015 6:13 PM, Richard Eckart de Castilho wrote:
>> Hi all,
>>
>> I wonder... what is the point of having a method allowing to initialize
>> a UimaContext with a resource manager if in fact the code is commented out?
>>
>> See RootUimaContext_impl
>>
>> public void initializeRoot(Logger aLogger, ResourceManager aResourceManager,
>> ConfigurationManager aConfigurationManager) {
>> mLogger = aLogger;
>> // mResourceManager = aResourceManager;
>> // mConfigurationManager = aConfigurationManager;
>> mSession = new Session_impl();
>> }
>>
>> Cheers,
>>
>> -- Richard
Re: Cannot set resource manager on RootUimaContext
Posted by Marshall Schor <ms...@schor.com>.
The mResourceManager and mConfigurationManager initialization were changed a few
releases ago as part of the work to make this area more thread safe, in support
of multi-threaded read-only access to a shared CAS.
These variables were made "final", and the comment for RootUimaContext_impl says
(I hope it's correct :-) ) that making these final causes a memory barrier to be
inserted for them which in turn makes other access to them "safe" from other
threads without further synchronization.
The method "initializeRoot" is in a package ending with the word "impl", which
says this is an internal implementation method, not part of the exposed API.
It's public because it is defined in the UimaContextAdmin "interface" and all
interface-style methods need to be public.
I think this is left-over stuff from that earlier change in the way these two
things were initialized. I think the method and the interface should probably
be updated to remove these two arguments. (But that's low priority...)
-Marshall
On 3/24/2015 6:13 PM, Richard Eckart de Castilho wrote:
> Hi all,
>
> I wonder... what is the point of having a method allowing to initialize
> a UimaContext with a resource manager if in fact the code is commented out?
>
> See RootUimaContext_impl
>
> public void initializeRoot(Logger aLogger, ResourceManager aResourceManager,
> ConfigurationManager aConfigurationManager) {
> mLogger = aLogger;
> // mResourceManager = aResourceManager;
> // mConfigurationManager = aConfigurationManager;
> mSession = new Session_impl();
> }
>
> Cheers,
>
> -- Richard
>