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 19:51:49 GMT
I guess I'm the opposite: I think it is better in the long run to be more
explicit about when you want external override settings loaded from the
classpath/datapath, rather than relying on some convention which might also need
som -D override flag for some cases.

That way, things are less "hidden", or "only known to those in-the-know", etc,
and instead are more explicit (and the rules are simpler too).

My 2 cents.  -Marshall


On 4/20/2017 2:35 PM, Burn Lewis wrote:
> 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
View raw message