In the interest of keeping the re-branding tasks together, I took the
liberty to made GEODE-3617 a subtask of
https://issues.apache.org/jira/browse/GEODE-1466.
On Tue, Sep 19, 2017 at 2:05 PM Dave Barnes wrote:
> Here's an updated link to the properties spreadsheet that should have wider
> viewa
Here's an updated link to the properties spreadsheet that should have wider
viewability:
https://docs.google.com/spreadsheets/d/1C2D7cpcYMy5bd0aXXReJn6wWsBuLZrCegl7_cevvKo0/edit?usp=sharing
On Tue, Sep 19, 2017 at 12:10 PM, Dave Barnes wrote:
> There's no single list of "all properties". Here's
There's no single list of "all properties". Here's one that Tech Pubs last
reviewed about 6 months ago...
https://docs.google.com/spreadsheets/d/1C2D7cpcYMy5bd0aXXReJn6wWsBuLZrCegl7_cevvKo0/edit#gid=0
On Thu, Sep 14, 2017 at 12:06 PM, Bruce Schuchardt
wrote:
> There are plenty of places beside
There are plenty of places besides DistributionConfig that use "gemfire"
prefixed system properties and there are now also places that use
"geode" prefixed system properties. I think the whole mess needs to be
managed and allow either prefix, or even as someone suggested making it
plug-able.
+1 to having DistributionConfig look for both the "gemfire." and "geode."
prefixes.
+1 to having DistributionConfig look for both a "gemfire.properties" and
"geode.properties" file.
Since the geode flavors are newer it should look for them first and only
look for the old gemfire flavor if a geode o
That's a bigger change and I'm not sure how you would handle backwards
compatibility for users using gemfire.properties.
On Thu, Sep 14, 2017 at 9:15 AM, Jacob Barrett wrote:
> Or better yet, we stop using properties files already.
>
> On Thu, Sep 14, 2017 at 8:55 AM Dave Barnes wrote:
>
> > Is
Or better yet, we stop using properties files already.
On Thu, Sep 14, 2017 at 8:55 AM Dave Barnes wrote:
> Is there a possibility that the code might find its way into additional
> contexts with other names? If so, perhaps we should consider a more generic
> identifier, such as PRODUCT_PREFIX.
Whoever takes this work on will need to spend time figuring out a way to
make it pluggable and support multiple prefixes possibly with pluggable
order of preference. For example, we would need to support looking for
geode.properties and gemfire.properties or it would break backwards
compatibility f
Is there a possibility that the code might find its way into additional
contexts with other names? If so, perhaps we should consider a more generic
identifier, such as PRODUCT_PREFIX.
On Thu, Sep 14, 2017 at 4:42 AM, Dinesh Akhand wrote:
> Hi,
>
> Why we are keeping gemfire in current geode 1.2
Hi,
Why we are keeping gemfire in current geode 1.2 , Can we replace this with GEODE
File : DistributionConfig.java
Current code:
String GEMFIRE_PREFIX = "gemfire.";
Suggestion to change:
String GEODE_PREFIX = "geode.";
Why do you think ?
Can we go ahead and change this ?
It will impact lot
10 matches
Mail list logo
