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:20:32 GMT
Another suggestion is to use a schema-like prefix ...* name: *or an
optional *file:*

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.

~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