The question is, what functionality are we expecting to see?
If one has already defined PDX within the cache.xml file, then maybe any
subsequent pdx calls should be seen as updates... Like adding classes to
the auto-serialization config.
Or maybe it should throw an exception where you should not be able to
change the configuration of PDX once deployed.
Not sure what they right answer should be.
What it seems to be right now, that it replaces the existing
configuration. So if you change the configuration and not specify the
correct parameters, you would potentially alter the expected behavior.
--Udo
<http://www.pivotal.io>
On 20/11/15 14:48, Real Wes Williams wrote:
resubmitting...
Why does the gfsh> Configure Pdx command automatically revert the
setting of “persistence” to false?
Is this by design or a bug?
I have pdf defined as persistent in cluster.xml.
<pdxread-serialized="true"persistent="true">
<pdx-serializer>
Later, when executing scripts that include configure pdf, it turns off
my persistence. I realize that configure pdx does not support
—persistence=true but why turn it off?
gfsh>configure pdx --read-serialized=true
--portable-auto-serializable-classes="com.company.domain.*"
The command would only take effect on new data members joining the
distributed system. It won't affect the existing data members
*persistent = false*
read-serialized = true
ignore-unread-fields = false
PDX Serializer com.gemstone.gemfire.pdx.ReflectionBasedAutoSerializer
Portable classes [com.company.domain.*]
