To Swap's point about making ReflectionBasedAutoSerializer the default (which I think is a good idea), comparably, in SDG, I have made SDG's o.s.d.g.mapping.MappingPdxSerializer [1] the default when PDX is enabled (i.e. @EnablePdx). No need to explicitly declare/register it. SDG's MappingPdxSerializer leverage's *Spring Data's* powerful mapping infrastructure to convert Java objects to PDX and back. This is even more robust than Apache Geode's own ReflectionBasedAutoSerializer, but clearly *Spring* specific.
More details available here [2] (which as it turns out, needs to be updated based on the latest developments, namely DATAGEODE-72 [3]). -John [1] https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/mapping/MappingPdxSerializer.html [2] https://docs.spring.io/spring-data/geode/docs/current/reference/html/#bootstrap-annotation-config-pdx [3] https://jira.spring.io/browse/DATAGEODE-72 On Thu, Jan 25, 2018 at 12:44 PM, Jacob Barrett <jbarr...@pivotal.io> wrote: > > > > On Jan 25, 2018, at 12:06 PM, Anilkumar Gingade <aging...@pivotal.io> > wrote: > > > > Jake, > > > > Interesting...Its the argument passed to function that is in deserialized > > form, right? > > Yes, if pdx read serialized is false (default) the argument is > deserialized to domain object or fails if no domain object found. If read > serialized is true then all arguments that are PDX serialized and passed in > as PdxInstance. Sett my this flag breaks all previous deployed functions > that expected domain objects in the argument. > > -Jake > > > > > > -Anil. > > > > > > > > > > > > > >> On Thu, Jan 25, 2018 at 10:12 AM, Jacob Barrett <jbarr...@pivotal.io> > wrote: > >> > >> Anil, this wouldn't fix a function execution where a parameter sent to > the > >> function is a PDX serialized object. The function would be invoked on > the > >> server with the current global setting and file to deserialize the PDX > to > >> domain object. This is why the ask is for it to fall back to > PdxInstance if > >> the domain object is not deployed. > >> > >> -Jake > >> > >> On Thu, Jan 25, 2018 at 9:56 AM Anilkumar Gingade <aging...@pivotal.io> > >> wrote: > >> > >>> Internally, there is an option to override read-serialized flag (to > >> true); > >>> the query engine and other components uses this to keep the data in > >>> serialized form and work with PdxInstance... > >>> > >>> public static void setPdxReadSerialized(Cache cache, boolean > >>> readSerialized); > >>> > >>> We had discussed, making this as a public api...so that any thread that > >> can > >>> work on PdxInstance can take advantage of it... > >>> > >>> -Anil. > >>> > >>> > >>> On Thu, Jan 25, 2018 at 9:42 AM, Jacob Barrett <jbarr...@pivotal.io> > >>> wrote: > >>> > >>>> Bruce, the flag only applies to values serialized with PDX, > >>>> DataSerializable objects are not effected by this property. > >>>> > >>>> I think there is some real value here as a stop gap until we have a > >>> better > >>>> solution in Geode 2 where the user can have a per request context that > >>>> specifies what return type they would like. Consider the user that has > >> an > >>>> existing application that uses domain objects but wants to deploy > >> another > >>>> application that doesn't to the same Geode cluster. The only option is > >> to > >>>> either have all PDX deserialize to domain objects or all returned as > >>>> PdxInstance. One of the two applications will not work without > >>>> modification. Changing the behavior described by Addison splits the > >>>> difference. If the application is, like it is by default, configure to > >>>> deserialize PDX to the domain object but the domain object is not > >>> deployed > >>>> it will now give back the PDX instance rather than failing. > >>>> > >>>> An explicit use case is user that has both a Java and .NET > application. > >>> The > >>>> .NET application does not have any Java domain objects to deploy to > the > >>>> server but does want to query or run server side functions. The Java > >>>> application has deployed the domain objects to the server and > >> distributed > >>>> functions are written expecting those domain objects on the server. > The > >>>> user would have to create Java domain objects for the .NET application > >> or > >>>> modify their Java application to expect PdxInstance. > >>>> > >>>> > >>>> -Jake > >>>> > >>>> > >>>> On Thu, Jan 25, 2018 at 7:38 AM Bruce Schuchardt < > >> bschucha...@apache.org > >>>> > >>>> wrote: > >>>> > >>>>> +1 > >>>>> > >>>>> I've found the current read-serialized property to be pretty useless. > >>>>> > >>>>> Having said that, what if the value isn't actually in serialized form > >>> in > >>>>> the local cache? Is Geode supposed to serialize it & return it? > >> What > >>>>> if it isn't PDX-serialized? Do we return a byte array? > >>>>> > >>>>> > >>>>>> On 1/24/18 12:21 PM, Dan Smith wrote: > >>>>>> Is this really just a workaround for the fact that the > >>> read-serialized > >>>>> flag > >>>>>> applies to the whole cache? I can see that if you have mix of > >> regions > >>>>> with > >>>>>> and without domain classes on the server you might want this > >> feature. > >>>> Can > >>>>>> you provide some more background on your use case? > >>>>>> > >>>>>> IMO we should get rid of read-serialized in favor of APIs that let > >>> the > >>>>> user > >>>>>> decide whether they get a domain class or a PdxInstance. > >>>>>> > >>>>>> -Dan > >>>>>> > >>>>>> On Wed, Jan 24, 2018 at 9:58 AM, Galen O'Sullivan < > >>>> gosulli...@pivotal.io > >>>>>> > >>>>>> wrote: > >>>>>> > >>>>>>> Hi Addison, > >>>>>>> > >>>>>>> What kind of setup do you have that is causing you to have PDX > >>>>> serialized > >>>>>>> objects that cannot be deserialized? Do you have classes that are > >>>>> present > >>>>>>> on some servers but not others? > >>>>>>> > >>>>>>> This change would break the contract of region.get() , which is > >> that > >>>> it > >>>>>>> returns a value of a type that can be put into the region. > >>>>>>> > >>>>>>> Returning something that isn't what the user is expecting to be in > >>> the > >>>>>>> region would require users to check for PdxInstances every time > >> they > >>>>> get a > >>>>>>> value -- even though the type annotations say that you can't get a > >>>>>>> PdxInstance back (except for Region<Object,Object> ). > >>>>>>> > >>>>>>> I think it would be better to have a second API that allows users > >> to > >>>> get > >>>>>>> and put PdxInstance objects in regions. That way, if they want to > >>>> handle > >>>>>>> the exceptional case where they have a serialized object that > >> can't > >>> be > >>>>>>> deserialized, they can catch the ClassNotFound exception and get > >> the > >>>>>>> underlying PdxInstance. > >>>>>>> > >>>>>>> I do think that the possibility of a ClassNotFoundException should > >>> be > >>>>>>> documented in the Region API. > >>>>>>> > >>>>>>> Cheers, > >>>>>>> Galen > >>>>>>> > >>>>>>> On Tue, Jan 23, 2018 at 2:56 PM, Addison Huddy <ahu...@pivotal.io > >>> > >>>>> wrote: > >>>>>>> > >>>>>>>> Hi Geode Devs, > >>>>>>>> > >>>>>>>> I'm proposing the following change to how we handle > >> deserialization > >>>>> when > >>>>>>>> Domain Objects can't be found and pdx-serialize=false. > >>>>>>>> > >>>>>>>> https://issues.apache.org/jira/browse/GEODE-4367 > >>>>>>>> > >>>>>>>> Looking forward to the discussion. > >>>>>>>> > >>>>>>>> \ah > >>>>>>>> > >>>>> > >>>>> > >>>> > >>> > >> > -- -John john.blum10101 (skype)
