uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Burn Lewis <burnle...@gmail.com>
Subject Re: [VOTE] uimaj sdk 2.10.0 rc1
Date Tue, 04 Apr 2017 12:35:06 GMT
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 <rec@apache.org>
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 <burnlewis@gmail.com> 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.
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message