On 3/26/2015 6:54 PM, Richard Eckart de Castilho wrote: > On 26.03.2015, at 23:06, Marshall Schor <[email protected]> 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 >
