I agree with John about pdx-read-serialized. The default expectation of a developer is that when they access their data it will be an instance of the class it was when it was added to the cache. Having it instead be a PdxInstance is tricky so I don't think it should be the default.
It is possible that the data will not even be deserialized on the server in which case it does not matter what pdx-read-serialized defaults to. If it is deserialized on the server then I think it is more understandable to get a ClassNotFoundException (java developers are used to that) instead of a class cast exception. A developer's initial instinct on class cast issues is that they made a coding error. So it might take them I while to figure out they can solve this problem by setting pdx-read-serialized to false. So I think the easiest new user experience is to configure the ReflectionBasedAutoSerializer by default and leave pdx-read-serialized defaulting to false. On Mon, Mar 27, 2017 at 1:41 PM, Wes Williams <wwilli...@pivotal.io> wrote: > Most new customers just want Geode/ GemFire to work - easily - because most > projects don't require dealing with PDX. In fact, some explicitly tell me > that they don't want to know about PDX because it's a distraction for the > simple use-cases. This is, of course, with the caveat that unless they need > it. But it is not to Geode's advantage if a new user gets a proprietary PDX > object and has to do research to figure out what to do with it. > > However, I definitely disagree with this... > > *> I think that customers would be ok to run PdxInstance.getObject() to > get their pojos when required.* > > On Mon, Mar 27, 2017 at 4:32 PM, John Blum <jb...@pivotal.io> wrote: > > > I generally don't see a problem with this from the *Spring* side, i.e. > SDG > > does not care as long as the "default" PdxSerializer (e.g. > > ReflectionBasedAutoSerializer or whatever) is "overridable" before cache > > initialization! > > > > However, I definitely disagree with this... > > > > *> I think that customers would be ok to run PdxInstance.getObject() to > > get their pojos when required.* > > > > IMO, I think (PDX) serialization really ought be treated as an "internal" > > concern and really should NOT be exposed to users. This is more of an > > implementation detail than anything else, and in an application, as a > > developer, I can tell you what I want to manipulate my POJOs. You do not > > see Hibernate or other mapping/persistent frameworks having you deal with > > the "internal" classes to make an entity "persistent" (i.e. attached vs. > > non-attached, etc). > > > > Longer term, I think the serialization mechanics should be > "configurable", > > being able to plugin whatever serialization framework (e.g. Avro, > Protobuf) > > makes sense for my application. > > > > $0.02 > > -j > > > > > > > > On Mon, Mar 27, 2017 at 1:15 PM, Udo Kohlmeyer <ukohlme...@pivotal.io> > > wrote: > > > > > +1 I think we should make the default serialization mechanism to be > PDX. > > > We should not concern ourselves with Java serialization at all anymore. > > > > > > +1 pdx-read-serialization=true ... I think we should prefer PdxInstance > > > objects over customer POJOs. I think that customers would be ok to run > > > PdxInstance.getObject() to get their pojos when required. But maybe to > > > start having customers use a more "optimal" serialization mechanism and > > > approach, a slight nudge into the PDXInstance direction is not that > bad. > > > > > > In addition to that, it might help if our own code expect PdxInstances > > > over Pojos. > > > > > > --Udo > > > > > > > > > On 3/27/17 12:58, Swapnil Bawaskar wrote: > > > > > >> I believe it would be much better user experience if we just > serialized > > >> user's domain object without requiring the user to configure anything. > > >> Currently, we require that the user specify that they want to use the > > >> ReflectionBasedAutoSerializer and the pattern that matches the domain > > >> objects. > > >> > > >> Looking at this code > > >> <https://github.com/apache/geode/blob/8bf39571471642beaaa36c > > >> 9626a61a90bd3803c2/geode-core/src/main/java/org/apache/ > > >> geode/pdx/internal/AutoSerializableManager.java#L213> > > >> it > > >> looks like the pattern can be made optional. Also, we can go ahead and > > >> configure ReflectionBasedAutoSerializer to be set by default on Cache > > >> startup (if one is not specified already). We should also set > > >> pdx-read-serialized to true in this case. > > >> For advanced use cases where the user wishes to exclude certain > fields, > > >> they can specify the pattern. > > >> If the users are using DataSerializable, that should still take > > precedence > > >> over PDX, so we won't break existing users. > > >> > > >> Are there any major concerns around this approach? > > >> > > >> Thanks! > > >> Swapnil. > > >> > > >> > > > > > > > > > -- > > -John > > john.blum10101 (skype) > > >
