[
https://issues.apache.org/jira/browse/OOZIE-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14059071#comment-14059071
]
Robert Kanter commented on OOZIE-1915:
--------------------------------------
That's a good point. We should try to keep this compatible. I think we can
handle this if we put properties in oozie-site/default, but if the equivalent
env var is also defined, we overwrite it (i.e. env var has highest priority,
then oozie-site, then oozie-default). This should allow us to remove the env
vars but still let people use them if they already have them defined. For
implementing this, I think we can just do something simple like have Services
or ConfigurationService check the env vars on startup and if defined, overwrite
their equivalent config properties; all of the code using these properties can
then look at the Oozie config from Services.getConf() without worrying about
it. Makes sense?
> Move system properties to conf properties
> -----------------------------------------
>
> Key: OOZIE-1915
> URL: https://issues.apache.org/jira/browse/OOZIE-1915
> Project: Oozie
> Issue Type: Bug
> Reporter: Purshotam Shah
>
> There are few properties like {{oozie.instance.id}}, {{oozie.http.hostname}},
> {{oozie.http.port}} which need to be configured as system property (-D).
> This are mostly used for HA.
> Let's have only one way of configuration, through oozie-default/oozie-site.
> It will avoid confusion and ease deployment.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
