Hmmm, you would think it would be easier to change a file name :-) I don’t think we should be pushing destabilizing changes into a release branch. If the changes aren’t ready now we always pick them up for the next release.
Anthony
> On Oct 13, 2016, at 1:13 PM, Kirk Lund <kl...@apache.org> wrote:
>
> I'm currently working with Jared and we have spent a few days working
> on GEODE-1466. We've been trying to get geode to the point where it can
> automatically search for, find and use either geode.properties or
> gemfire.properties (preferring geode.properties if both are found).
>
> We were intending to break this up into three subtasks with the hope of
> including #1 in Geode 1.0.0 incubating:
>
> 1) locating geode.properties and gemfire.properties if user has not
> specified a specific properties file
>
> 2) support specifying geode configuration properties with system properties
> geode.<property-name> as well as gemfire.<property-name>
>
> ex: -Dgemfire.off-heap-memory-size=40g or -Dgeode.off-heap-memory-size=40g
>
> 3) modify all other system properties in geode to support alias of gemfire
> as well as geode where the name of the system property currently contains
> gemfire
>
> ex: -Dgemfire.Query.VERBOSE=true or -Dgeode.Query.VERBOSE=true
>
> The community is planning to create the Geode 1.0.0 incubating RC tomorrow.
> The work we have completed so far involves modifying geode to search for
> both geode.properties and gemfire.properties to use whichever one is found.
> This turns out to be too complex to complete by tomorrow (send me a email
> directly if you want more detailed info which mostly involves
> DistributionConfig and ConfigSource).
>
> In order to complete this in time, we need to use a different strategy.
> Instead of looking for geode.properties first and then gemfire.properties,
> we are proposing the following change to DistributionConfig:
>
> Change the GEMFIRE_PREFIX = "gemfire." constant to be configurable by a
> system property and change the default to be "geode." This places a greater
> burden on the user who is migrating from GemFire to Geode but doesn't want
> to rename gemfire.properties or gemfire system properties. By default,
> Geode would search for geode.properties unless the user specifies a new
> system property with a different prefix ("gemfire."):
>
> String GEMFIRE_PREFIX = PropertiesPrefix.getGemfireOrGeodePrefix();
>
> Example of overriding this to be "gemfire.":
>
> -DgeodePropertiesPrefix="gemfire."
> or
> -DgeodePropertiesPrefix="gemfire"
>
> (we'll add the "." for you if you leave it out)
>
> Pivotal or other vendors could also alter this prefix as they see fit.
>
> There are 453 lines of production code that refer to this GEMFIRE_PREFIX
> constant. For example, every system property that contains "gemfire." is
> currently referring to the constant, so they would also be altered to be
> "geode." by default. The JMX notifications also refer to GEMFIRE_PREFIX
> such as: GEMFIRE_PREFIX + "distributedsystem.cache.client.joined".
>
> Does anyone know if anything referring to GEMFIRE_PREFIX is persisted in
> some way that would break if we make this change? For example, if we
> persist any strings built with this constant to a diskstore, then recovery
> from that diskstore would be broken if the prefix value is "geode." during
> recovery of an old diskstore.
>
> Also, a user could conceivably override the GEMFIRE_PREFIX in some members
> of a cluster but not others which could break things in unexpected ways.
>
> One more note: While reviewing uses of GEMFIRE_PREFIX we noticed that
> AgentUtil supports "GEMFIRE" (hardcoded) and GEMFIRE_PREFIX+".home" env
> vars while all of the online docs specify setting GEMFIRE_HOME as an env
> var. I suspect this is already broken (I will file a ticket), but I think
> we will also be at risk of breaking additional things that may or may not
> be immediately detected by precheckin tests. It's also used by DtdResolver
> for the name of a dtd: new File(GEMFIRE_PREFIX + "dtd). We'll continue
> looking for unusual or risky uses of the constant.
>
> Bottom line is making this change is higher risk than not making the
> change, and there could be some fallout bugs that require fixes and
> additional release candidates for 1.0.0.
>
> Does the community feel this change is desirable for 1.0.0? Or is it better
> to leave it as "gemfire." and move GEODE-1466 to post-1.0.0?
>
> Thanks,
> Kirk
signature.asc
Description: Message signed with OpenPGP using GPGMail
