uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Burn Lewis <burnle...@gmail.com>
Subject Re: Loading external override settings from the class path or data path
Date Thu, 20 Apr 2017 18:35:39 GMT
I mean that I'd prefer no prefixes ... just the presence or absence of /'s.

On Thu, Apr 20, 2017 at 2:29 PM, Marshall Schor <msa@schor.com> wrote:

>
>
> On 4/20/2017 2:20 PM, Burn Lewis wrote:
> > Another suggestion is to use a schema-like prefix ...* name: *or an
> > optional *file:*
> Either way would be fine with me.
> >
> > Ideally I would prefer "the names of file resources contain file path
> > separators, while path resources only dots."
> > But for backward compatibility we need to treat entries such as
> > foo.settings as files ... but this back-level support could be enabled by
> > an environment variable.
> I don't understand why this would be needed, if you required that name: or
> name=
> prefix be there for the classpath/datapath choice?  Then if it wasn't
> there, it
> would be the file system choice, and it wouldn't matter if there were "/"
> there
> or not?
>
> -Marshall
> >
> > ~Burn
> >
> >
> > On Thu, Apr 20, 2017 at 1:53 PM, Marshall Schor <msa@schor.com> wrote:
> >
> >> On 4/19/2017 4:20 PM, Burn Lewis wrote:
> >>> In UIMA 2.10.0 support was added for loading external override settings
> >>> from the classpath or datapath, but the approach chosen introduced an
> >>> ambiguity
> >> ambiguity maybe not quite the right idea.  If the order of looking is
> well
> >> defined, then what we have is a spec which has a non-ambiguous
> >> interpretation,
> >> but that interpretation depends on the run-time existence (or not) of
> >> things.
> >>
> >> So, I think the goal is to make this more explicit, instead of implicit.
> >>
> >>> by looking first in the filesystem and then in the class path or
> >>> datapath.  A better approach would be to use a syntax that clearly
> >>> indicates whether to search the filesystem, or to search the classpath
> &
> >>> datapath.
> >> Sounds like a good idea, and in line with many other tradeoffs done in
> >> UIMA in
> >> favor of helping users to avoid mistakes.  The mistake here would be
> >> expecting
> >> to get the external overrides from the classpath, for example, but
> >> "accidentally" having a file system file that unintentionally starts
> >> overriding
> >> this (I'm assuming that file system things override classpath things.
> If
> >> that's
> >> backwards, just reverse the example :-) ).
> >>
> >>> We could represent path resources using the Java-style dotted name
> syntax
> >>> as is used for UIMA imports by name.  The dots would be replaced by
> file
> >>> path separators and the suffix ".settings" appended before searching
> the
> >>> paths.  Ideally the presence of a slash would indicate a file resource,
> >> but
> >>> in case existing applications are using a simple relative filename we
> >> could
> >>> also check for the presence of a ".settings" suffix.
> >>>
> >>> Another approach would be to copy the import convention and also allow
> a
> >>> name or location attribute.  So the comma-separated elements could be a
> >>> filename, or location=filename, or name=dotted-name.
> >>>
> >>> The documentation could be:
> >>>
> >>> The value of the property must be a list of resource names, each
> >> separated
> >>> by a single comma.  The name can be a filename, or a Java-style dotted
> >> name
> >>> loaded from the class path or data path.  Dots are replaced by file
> path
> >>> separators and the suffix ".settings" is appended.  Note that if that
> >>> suffix is already present the resource is assumed to be a file.
> >>> e.g. -DUimaExternalOverrides=/data/file1.settings,org.foo.bar.
> >> file2.settings
> >>> or
> >>>
> >>> The value of the property must be a list of resources, each separated
> by
> >> a
> >>> single comma.  The resource can be specified as a filename, or as
> >>> name=dotted-name, or as location=filename.  The dotted-name resources
> are
> >>> loaded from the class path or data path after replacing dots by file
> path
> >>> separators and appending the suffix ".settings".
> >>> e.g.
> >>> -DUimaExternalOverrides=/data/file1.settings,name=org.foo.
> >> bar,location=file2.settings
> >>> Comments and better/different suggestions welcome!
> >> One other criteria to consider: can the most likely usage already
> >> existing, be
> >> made backward compatible?
> >>
> >> I kind of like the name= style (indicating to get it from the
> >> classpath/datapath), since that is the same as already existing syntax
> for
> >> imports.
> >>
> >> For backwards compatibility, I would allow the location=xxxx or just
> xxxx
> >> as it
> >> is today.
> >>
> >> -Marshall
> >>
>
>

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