commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wade Chandler <hwadechandler-apa...@yahoo.com>
Subject Re: [configuration][all] Support for OS environment variables
Date Tue, 24 Jul 2007 20:07:44 GMT
Well, deprecated doesn't mean gone. So, if it was
undeprecated in 1.5 then I wouldn't consider it
deprecated in earlier versions any more. I would just
consider it a goofy warning to deal with. At least
that is the way I would look at that. Then, I also
don't look at deprecated to mean don't "ever" use. As
in this case, it didn't make sense for it to go away
as it is something which is needed, and was probably
undeprecated for the same reason other desktop
integration as added such as OS taskbar icons and
menus in 1.6, and other times this has occurred in
different APIs yet the API lags on because there is no
good alternative. Just as in the NetBeans APIs there
are some APIs which have been deprecated yet no new
APIs are under way yet, so they won't be going away
any time soon, so until they are replaced the
deprecated ones have to be used.

Wade

--- Oliver Heger <oliver.heger@oliver-heger.de> wrote:

> Wade Chandler wrote:
> > Sure, but not from a configuration perspective.
> For
> > instance, if daemon used configuration for a
> > configuration file it could be easier to use.
> Provide
> > multiple configuration files with your
> distribution
> > which allows users to more easily install and
> > uninstall services and operate on them without
> > remembering command line switches etc. launcher
> could
> > even use configuration (which is smaller than ANT)
> yet
> > also allow ANT and not have as many runtime
> > requirements. Then of course other applications
> can
> > just use a single configuration entry point and
> use
> > configuration information and reference
> environment
> > variables without having to hard code them into
> their
> > sources...makes it configurable.
> > 
> > 
> > Wade
> > 
> > --- Mark Fortner <phidias51@gmail.com> wrote:
> > 
> >> Isn't this already handled by System.getenv?
> 
> System.getenv() has long been deprecated and is now
> available again 
> since 1.5. [configuration] still has 1.3 as minimum
> required JDK; I 
> don't know when we switch to 1.5 (there will
> probably be another version 
> that requires 1.4).
> 
> My problem with this issue is that it will probably
> take a high effort 
> to implement it correctly for earlier JDKs, while we
> get it for free in 
> 1.5. This seem counter-productive.
> 
> Oliver
> 
> >>
> >> On 7/23/07, Wade Chandler
> >> <hwadechandler-apache@yahoo.com> wrote:
> >>> Personally, I think this type thing comes in
> very
> >>> handy in different situations. It would even be
> >> handy
> >>> in daemon and launcher. Look how many times
> >> scripts
> >>> have to be written for every OS to get different
> >>> things like JAVA_HOME and ANT_HOME or similar
> into
> >> an
> >>> application. It has been deprecated for a long
> >> time,
> >>> but I doubt it will ever be removed. It seems to
> >> be
> >>> quite needed in situations.
> >>>
> >>> Wade
> >>>
> >>> --- Oliver Heger <oliver.heger@oliver-heger.de>
> >> wrote:
> >>>> Hi all,
> >>>>
> >>>> for [configuration] we have a feature request
> >> for
> >>>> supporting environment
> >>>> variables [1]. I searched the archives and
> found
> >>>> that this topic has
> >>>> been discussed before [2].
> >>>>
> >>>> I was wondering whether situation has changed
> >> since
> >>>> then. My personal
> >>>> opinion is expressed in the Jira ticket in [1].
> >> What
> >>>> do others think?
> >>>>
> >>>> Please note that the ticket contains an
> >> attachment
> >>>> with a simple
> >>>> implementation for accessing environment
> >> variables.
> >>>> Thanks
> >>>> Oliver
> >>>>
> >>>> [1]
> >>>>
> >
>
http://issues.apache.org/jira/browse/CONFIGURATION-284
> >>>> [2]
> >>>>
> >
>
http://thread.gmane.org/gmane.comp.jakarta.commons.devel/33239/focus=33325
> >>>>
> > 
> > 
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
> > 
> 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message