Again, my concern is with documentation and direction, not necessarily
going through and making these changes at right now.
On Wed, Apr 25, 2018 at 3:45 PM, Jinmei Liao wrote:
> Any config object that needs to be Identifiable and Serializable should be
> identified as a
Any config object that needs to be Identifiable and Serializable should be
identified as a CacheElement, but we don't have to go through all of the
objects and identify them at once. When we are refactoring each individual
commands and recognize the need, we will identify the object to be a
Sorry, I forgot to step away from the In The Weeds where I am.
o.a.g.cache.configuration.CacheElement is the experimental interface meant
to identify an extension's configuration classes for consumption with the
new cluster configuration interface. Extension developers can then use the
It looks like there are two classes called CacheElement in the codebase;
am I correct in thinking that you're referring to
org.apache.geode.cache.configuration.CacheElement?
This class doesn't have a Javadoc, so it's a little hard as an outsider
to understand exactly what it is or how it's
Hi there Patrick.
I have not checked the wiki page, but if you have not updated that page
with the proposal then could you possibly do that.
I need to visualize the problem and reading a bunch of words does not
visualize it for me. Visualizing it might actually help describe the
future and
Hello all!
We introduced the CacheElement interface as part of our experimental API
to update the cluster configuration. I'd like to solidify and document our
intent for the interface and the extent to which it is expected to apply.
In its current form, the CacheElement interface extends