uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Lally" <ala...@alum.rpi.edu>
Subject Re: <envVarRef>s in UIMA descriptors
Date Thu, 12 Apr 2007 17:30:05 GMT
I think it might not be so bad to have the <envVarRef> resolve first
to a Java system property, if one exists, and if none exists then try
to get an actual environment variable (if the underlying JRE supports
it).  Then at least existing applications that work will continue to
work.  The worst that might happen to an existing application is a
case where the <envVarRef> resolved to empty string might suddently
start picking up a value from the enviornment, but this seems very

Still, like Thilo I'm not entirely convinced that this feature is even
a good idea at all.  It's true we've had users ask for this, but I'm
concerned that it complicates reusability of UIMA components.  To
deploy someone's component you now have yet another thing to worry
about besides configuration parameter settings and external resource
bindings - now you have to make sure the environment variables are set
up right.  (I suppose any particular annotator might access
environment variables in its code anyway, so we can't entirely avoid
that, but I'm reluctant to have UIMA actually encourage it).


On 4/12/07, Thilo Goetz <twgoetz@gmx.de> wrote:
> Marshall Schor wrote:
> > Adam Lally wrote:
> >> On 3/26/07, Thilo Goetz <twgoetz@gmx.de> wrote:
> >>> I agree that people may be using it.  I haven't seen it used in a while,
> >>> but that doesn't mean anything.  If we don't plan on removing the
> >>> feature, why should we deprecate it?
> >>>
> >>> The name is because we wanted no difference between Java and C++
> >>> descriptors.  System properties are the way to do env vars in Java.
> >>> System env vars are deprecated in Java.  So I'd vote to leave things as
> >>> they are.  If the CDE doesn't support this (documented and I assume,
> >>> working) feature, maybe we should add that support?
> >>>
> >>
> >> BTW, System.getEnv is no longer deprecated in Java 5.  But I'm not
> >> sure that really helps us, since at present we're still committing to
> >> support Java 1.4.
> >>
> >> -Adam
> >>
> >>
> >
> > In Java 1.4, although it's marked as deprecated, it is available.  And
> > it's no longer
> > deprecated in Java 5 or Java 6.  So we could change this to
> > access environment variables directly, right?  Then it would match the
> > C++ impl.
> >
> > -Marshall
> >
> Changing this might break backward compatibility in fairly subtle ways.
>   I'd be very careful to change the behavior of an existing feature in
> that way.  If we want to change it (it and I'm not at all convinced we
> do), I'd vote for removing the <envVar> feature and replacing it with a
> new one that has the desired properties.  That will alert both annotator
> writers and application developers to the change.
> --Thilo

View raw message