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 18:29:46 GMT


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