[jira] [Updated] (GEODE-5217) Some configuration properties passed on the command-line must be passed with the gemfire.* prefix rather than the geode.* prefix.

["Patrick Rhomberg (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GEODE-5217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Patrick Rhomberg updated GEODE-5217:
------------------------------------
    Summary: Some configuration properties passed on the command-line must be passed with the gemfire.* prefix rather than the geode.* prefix.  (was: Reconcile support of deprecated gemfire.* properties with current geode.* property specification)

> Some configuration properties passed on the command-line must be passed with the gemfire.* prefix rather than the geode.* prefix.
> ---------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: GEODE-5217
>                 URL: https://issues.apache.org/jira/browse/GEODE-5217
>             Project: Geode
>          Issue Type: Bug
>          Components: configuration, docs
>            Reporter: Patrick Rhomberg
>            Priority: Major
>
> By way of intent, properties historically stored as {{gemfire.my-property}} should now be stored as {{geode.my-property}}.  To support pre-open-source implementations, we support (as deprecated) the {{gemfire}} property prefix as though it were a {{geode}} prefix.
> By way of intent, the {{SystemPropertyHelper}} class wraps environment property calls to abstract this dual-prefix support.
> Problematically, the {{DistributionConfig}} class specifies its own {{GEMFIRE_PREFIX}}, with extending classes calling {{System.getProperty}} and its proxies (e.g., {{Integer.getInteger}}) directly, rather that using the {{SystemPropertyHelper}}.
> When properties are injected into the system environment from a properties file, it appears to use the {{gemfire.}} prefix for compatibility with existing implementations.
> As a result however, some properties (e.g., cluster-ssl) cannot be provided on the command-line using the intuitive "geode.cluster-ssl" and must use "gemfire.cluster-ssl".
> The {{DistributionConfig}} and affiliate classes should be refactor to support the modern, open-source project naming.
> ----
> To reproduce, observe that the following correctly enforces peer-to-peer SSL
> {noformat}
> start locator --name=GemfireLocator --http-service-port=0 --bind-address=localhost --enable-cluster-configuration=true\
>  --J=-Dgemfire.jmx-manager-hostname-for-clients=localhost --J=-Dgemfire.feature-protobuf-protocol=false --J=-Dgemfire.ssl-enabled-components=locator\
>  --J=-Dgemfire.ssl-keystore=myKeystore.jsk --J=-Dgemfire.ssl-keystore-password=secret\
>  --J=-Dgemfire.ssl-truststore=myTruststore.jks --J=-Dgemfire.ssl-truststore-password=alsoSecret
> {noformat}
> while this does not
> {noformat}
> start locator --name=GeodeLocator --http-service-port=0 --bind-address=localhost --enable-cluster-configuration=true\
>  --J=-Dgeode.jmx-manager-hostname-for-clients=localhost --J=-Dgeode.feature-protobuf-protocol=false --J=-Dgeode.ssl-enabled-components=locator\
>  --J=-Dgeode.ssl-keystore=myKeystore.jsk --J=-Dgeode.ssl-keystore-password=secret\
>  --J=-Dgeode.ssl-truststore=myTruststore.jks --J=-Dgeode.ssl-truststore-password=alsoSecret
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)