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 14:04:32 GMT
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 <msa@schor.com> 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 <
> 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