[ https://issues.apache.org/jira/browse/GEODE-7394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485434#comment-17485434 ]
John Blum edited comment on GEODE-7394 at 2/1/22, 7:52 PM: ----------------------------------------------------------- [~dschneider]- Implementing {{PdxSerializable}} should be viewed as an _*anti-pattern*_ and deprecated, IMO. I never recommend this approach to any users, ever. For one, it unduly couples application code to Geode, and application domain model types can play in mores spaces then simply Geode, especially in a distributed application context, 1 that is highly likely in a Microservices architecture. Coupling, in general, is bad. Users should always supply a {{PdxSerializer}} implementation if they require custom serialization. Secondly, setting {{read-serialized}} to {{true}} without a registered {{PdxSerializer}} implementation is dangerous at best, given it is only a matter of time before something triggers a deserialization on the server-side (e.g. an OQL query (invoking a Object method) or Function execution, depending on the logic, most likely a query). Regarding... > _My understanding is that one of the Spring projects has its own > PdxSerializer that works better with Spring than the > ReflectionBasedAutoSerializer._ SDG's {{MappingPdxSerializer}} ([Javadoc|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/mapping/MappingPdxSerializer.html], [Doc|https://docs.spring.io/spring-data/geode/docs/current/reference/html/#mapping.pdx-serializer]) is better on all accounts, with or without _Spring_, given is foundation in _Spring Data's_ Mapping infrastructure (which handles type conversation, serialization, identity and other needs). Additionally, Geode's {{ReflectionBasedAutoSerializer}} currently suffers from several limitations (for [example|https://issues.apache.org/jira/browse/GEODE-7382]) and has issues (for [example|https://issues.apache.org/jira/browse/GEODE-7381]). SDG's {{MappingPdxSerializer}} has replaced REGEX with Java {{Predicates}}. REGEX is very error prone given users general lack of REGEX experience. A sipmly typo in the pattern can compile but completely mismatch types. Even for savvy REGEX users, it is problematic. Of course, SDG's {{MappingPdxSerializer}} does not prevent users from using REGEX if they prefer; they can do so inside a Java {{Predicate}}, and they can use multiple (chained) {{Predicates}}, which effectively simplifies expressions or matching criteria. All {{PdxSerialization}} aside, it is not apparent "how Geode will behave" when the _Gfsh_ {{configure pdx}} command is used. It is less than obvious what effect the command has in most cases. Having said this, I have not had to issue the command in sometime, maybe not since I filed this ticket, so I am not sure if anything has been updated in this regard. was (Author: jblum): [~dschneider]- Implementing {{PdxSerializable}} should be viewed as an _*anti-pattern*_ and deprecated, IMO. I never recommend this approach to any users, ever. For one, it unduly couples application code to Geode, and application domain model types can play in mores spaces then simply Geode, especially in a distributed application context, 1 that is highly likely in a Microservices architecture. Coupling, in general, is bad. Users should always provided a {{PdxSerializer}} implementation if they require custom serialization. Secondly, setting {{read-serialized}} to {{true}} without a registered {{PdxSerializer}} implementation is dangerous at best, given it is only a matter of time before something triggers a deserialization on the server-side (e.g. an OQL query (invoking a Object method) or Function execution, depending on the logic, most likely a query). Regarding... > _My understanding is that one of the Spring projects has its own > PdxSerializer that works better with Spring than the > ReflectionBasedAutoSerializer._ SDG's {{MappingPdxSerializer}} ([Javadoc|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/mapping/MappingPdxSerializer.html], [Doc|https://docs.spring.io/spring-data/geode/docs/current/reference/html/#mapping.pdx-serializer]) is better on all accounts, with or without _Spring_, given is foundation in _Spring Data's_ Mapping infrastructure (which handles type conversation, serialization, identity and other needs). Additionally, Geode's {{ReflectionBasedAutoSerializer}} currently suffers from several limitations (for [example|https://issues.apache.org/jira/browse/GEODE-7382]) and has issues (for [example|https://issues.apache.org/jira/browse/GEODE-7381]). SDG's {{MappingPdxSerializer}} has replaced REGEX with Java {{Predicates}}. REGEX is very error prone given users general lack of REGEX experience. A sipmly typo in the pattern can compile but completely mismatch types. Even for savvy REGEX users, it is problematic. Of course, SDG's {{MappingPdxSerializer}} does not prevent users from using REGEX if they prefer; they can do so inside a Java {{Predicate}}, and they can use multiple (chained) {{Predicates}}, which effectively simplifies expressions or matching criteria. All {{PdxSerialization}} aside, it is not apparent "how Geode will behave" when the _Gfsh_ {{configure pdx}} command is used. It is less than obvious what effect the command has in most cases. Having said this, I have not had to issue the command in sometime, maybe not since I filed this ticket, so I am not sure if anything has been updated in this regard. > 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.20.1#820001)