uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eddie Epstein" <eaepst...@gmail.com>
Subject Re: <envVarRef>s in UIMA descriptors
Date Fri, 13 Apr 2007 13:19:39 GMT
And yet the UIMA SDK run_configurations depends on the environmental
variable UIMA_HOME:

"-Djava.util.logging.config.file=${env_var:UIMA_HOME}/config/Logger.properties"
-DVNS_HOST=localhost

Are we being hypocritical here, using environment variables in Java
when convenient but saying that others should not?

Eddie

On 4/12/07, Adam Lally <alally@alum.rpi.edu> wrote:
> 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
> rare.
>
> 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).
>
> -Adam
>
> 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
> >
> >
> >
> >
>

Mime
View raw message