uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: Loading external override settings from the class path or data path
Date Thu, 20 Apr 2017 17:53:04 GMT

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
View raw message