Class-/data-path loading of external settings files is not in 2.9.0 ... it is new in 2.10.0.
Burn On Tue, Apr 4, 2017 at 9:54 AM, Marshall Schor <[email protected]> wrote: > just to be clear, this last discussion thread topic about changing the > interpretation of -DUimaEternalOverrides would result in a breaking change > from > 2.9.0 - that is - this is already in the 2.9.0 implementation, is this > correct? > > -Marshall > > > On 4/4/2017 8:35 AM, Burn Lewis wrote: > > Certainly. I don't want to rush this change through without discussion. > > One drawback to this proposed syntax is that it could break an existing > > application .... if a settings file was specified as *"foo.settings"* > then > > instead of being loaded from the current directory the class path would > be > > searched for *"foo.settings.settings"*. It would have to be changed to > > *"./foo.settings"* to get the original behavior. > > > > Burn > > > > On Tue, Apr 4, 2017 at 7:55 AM, Richard Eckart de Castilho < > [email protected]> > > wrote: > > > >> Would you be ok with releasing RC1 with the note that this external > >> overrides > >> behavior will be changed in the next release *without* introducing a > flag > >> that > >> restore the RC1 behavior (i.e. a potentially breaking change)? > >> > >> -- Richard > >> > >>> On 04.04.2017, at 00:32, Burn Lewis <[email protected]> wrote: > >>> > >>> The other issue is what I now believe is a poor design choice I made in > >>> Jira 5208 which lets an external overrides settings file be loaded from > >> the > >>> class path or data path. Currently if the file name is relative but > not > >>> found in the filesystem the class path and data path are searched. A > >>> cleaner design would be to follow the same convention used for > importing > >>> descriptors by name, i.e. use the java class notation to indicate that > >> the > >>> class path & data path must be searched (after replacing "." by "/" and > >>> adding ".settings".) The presence of a "/" in a file name would imply > a > >>> filesystem lookup. > >>> > >>> Thus a specification of *-DUimaEternalOverries=abc/ > >> test.settings,d.e.f.test > >>> *would load the first file from the filesystem and load the second as > >>> *d/e/f/test.settings* from the class path or data path. The current > >>> implementation makes it possible to silently change a program's > >> parameters > >>> by merely adding a file to the filesystem that replaces one that is > >> usually > >>> loaded from the class path ... perhaps not a desirable feature. > >>> > >>> Since this is not a severe problem I don't feel I can justify voting > rc1 > >>> down so I'll hold off until I have a potential fix, and will wait for > >> other > >>> comments. > >> > >
