[
https://issues.apache.org/jira/browse/GEODE-7394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16965084#comment-16965084
]
Darrel Schneider commented on GEODE-7394:
-----------------------------------------
I don't think this statement is true: "Without a PdxSerializer the command
essentially serves no purpose nor has any effect".
Pdx serialization can be used without a PdxSerializer. Domain classes can
implement the PdxSerializable interface.
Also, even if you are using a PdxSerializer, you may not need to have it on
your server. If you set --read-serialized=true on the server then it should
never need to use the PdxSerializer on the server even though it is used on the
client.
In the above use cases you may still want to set --read-serialized or
--ignore-unread-fields or the pdx disk store and the configure pdx command
allows you to do that.
The ReflectionBasedAutoSerializer is the easiest way to use pdx provided by
geode. My understanding is that one of the Spring projects has its own
PdxSerializer that works better with Spring than the
ReflectionBasedAutoSerializer. I know we have had requests before for the
default to be ReflectionBasedAutoSerializer with the .* REGEX. But I think one
of the current problems we have with that is that if you have a
ReflectionBasedAutoSerializer whose regex matches that class name then that
serialization takes precedence over other forms of serialization. So you could
have a JDK class that has its own special serialization code suddenly ignored
by geode serialization and instead it would be serialized by PDX. That could
cause performance issues, correctness issues, and compatibility issues.
Maybe we could enhance the PdxSerializer to have two stages in the
serialization precedence. The first state would ask it early if it wants to
serialize a class before all other serialization frameworks. If that request is
turned down it would then check the other ways of doing serialization like it
currently does. But a new stage at the end could be added after we have not
found any way to serialize an object. That would be to ask the PdxSerializer to
attempt serialization as a last ditch attempt. Maybe this "last ditch attempt"
could just be hardcoded into our serialization precedence with no need for the
user to even configure a PdxSerializer. We could just try all the current ways
we have and if none of them work ask our built in ReflectionBasedAutoSerializer
with a REGEX of .* to give it a try.
> Gfsh `configure pdx` command is non-intuitive and currently has a bad user
> experience
> -------------------------------------------------------------------------------------
>
> Key: GEODE-7394
> URL: https://issues.apache.org/jira/browse/GEODE-7394
> Project: Geode
> Issue Type: Bug
> Components: serialization
> Reporter: John Blum
> Priority: Major
>
> The _Gfsh_ {{configure pdx}} command does *not* register a {{PdxSerializer}}
> (e.g. {{ReflectionBasedAutoSerializer}}, or otherwise) unless the
> {{--auto-serializable-classes}} option is explicitly specified. Without a
> {{PdxSerializer}} the command essentially serves no purpose nor has any
> effect. Effectively, the command is useless.
> For example, doing something like `gfsh> configure pdx
> --read-serialized=false` or `gfsh> configure pdx --ignore-unread-fields` by
> itself is *pointless* since ultimately there would be no `PdxSerializer`
> registered in this case.
> _Gfsh_ should minimally register a `PdxSerializer` anytime the `configure
> pdx` command is used regardless of the options provided, especially if it
> returns successfully without incident. For instance, it could register the
> `ReflectionBaseAutoSerializer` with the REGEX {{.*}} (de/serializing all
> types, regardless of whether that is optimal or not).
> Alternatively, if we decide not to register the
> {{ReflectionBasedAutoSerialier}} with a generic REGEX (e.g. {{.*}}), then we
> should _fail-fast_ and the command should report that
> {{--[portable-]-auto-serializable-classes}} is required!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
