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 <[EMAIL PROTECTED]> wrote:
Marshall Schor wrote: > Adam Lally wrote: >> On 3/26/07, Thilo Goetz <[EMAIL PROTECTED]> 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
