As per my understanding, If you get a cached user object from the IdenttityStroe cached wrapper, then the wrapper is responsible for setting the identity store object to the deserialized user object. So that the calling party will not see any difference.
As a summary, - Only IdentityStore cached wrapper stores user objects - After retrieving a user object from the cache, IdentityStore cached wrapper is responsible for setting the IdentityStore instance to the deserialized User object. - Any other component outside user-core should only cache uniqueUserId and should always come back to the user-core for User object Thanks, Thanuja On Sat, Mar 11, 2017 at 11:46 PM, Johann Nallathamby <joh...@wso2.com> wrote: > Why can't we simply re-initialize the User object with the correct > identity store when it is deserialized, using the readObject() method? > > On Sat, Mar 11, 2017 at 10:41 PM, Jayanga Kaushalya <jayan...@wso2.com> > wrote: > >> Hi Harsha, >> >> Yes I understand. Either you have to check whether the Identity Store is >> null in the User object or we should change each method in the User class >> which uses Identity Store to throw custom checked exception when the >> Identity Store is null and handle it accordingly when using User object. >> Personally I am +1 for the second approach. Please advice if there are any >> better approaches. >> >> Thanks! >> >> *Jayanga Kaushalya* >> Software Engineer >> Mobile: +94777860160 <+94%2077%20786%200160> >> WSO2 Inc. | http://wso2.com >> lean.enterprise.middleware >> >> On Sat, Mar 11, 2017 at 9:27 PM, Harsha Thirimanna <hars...@wso2.com> >> wrote: >> >>> Hi Jayanga, >>> >>> Yes, that is possible to do and I felt it as a workaround to instead of >>> calling getClaim API in user object. >>> But at once i didn't feel that i can't call getClaim API because i don't >>> know whether that User object is coming from Cache or not. It can be >>> cached by different component even. >>> Is that make sense to provide such API in user object if it not possible >>> to give the result all the time in sameway. We have to make it consistent. >>> Because , the developer has to know whether this User object came from >>> Cache or not. If it is from cache, then developer has to get the claims by >>> using RealmService again. >>> >>> *Harsha Thirimanna* >>> *Associate Tech Lead | WSO2* >>> >>> Email: hars...@wso2.com >>> Mob: +94715186770 <+94%2071%20518%206770> >>> Blog: http://harshathirimanna.blogspot.com/ >>> Twitter: http://twitter.com/harshathirimann >>> Linked-In: linked-in: http://www.linkedin.com/pub/ha >>> rsha-thirimanna/10/ab8/122 >>> <http://wso2.com/signature> >>> >>> On Sat, Mar 11, 2017 at 8:49 PM, Hasintha Indrajee <hasin...@wso2.com> >>> wrote: >>> >>>> Hi Jayanga, >>>> >>>> So what happens if we want to store user objects and then later if we >>>> want to retrieve user objects and try to access claims ? . Here we are >>>> storing user objects in authentication context, not in the identity store. >>>> And how are we storing user objects in the cache when the instance of >>>> identity store is neither serializable nor transient ? >>>> >>>> On Sat, Mar 11, 2017 at 8:34 PM, Jayanga Kaushalya <jayan...@wso2.com> >>>> wrote: >>>> >>>>> Hi Harsha, >>>>> >>>>> It was designed to be like that. User object will be cached in the >>>>> IdentityStore. So when you retrieving the user object from IdentityStore >>>>> again, it will be most probably from cache instead of connector. >>>>> >>>>> Thanks! >>>>> >>>>> *Jayanga Kaushalya* >>>>> Software Engineer >>>>> Mobile: +94777860160 <+94%2077%20786%200160> >>>>> WSO2 Inc. | http://wso2.com >>>>> lean.enterprise.middleware >>>>> >>>>> On Sat, Mar 11, 2017 at 7:41 PM, Harsha Thirimanna <hars...@wso2.com> >>>>> wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> In identity gateway, we have to cache the User object that is >>>>>> retrieved from user core within the authentication context and session >>>>>> context. After some times we have to get that user object and want to get >>>>>> the claims since it has the claim API within user object itself. But >>>>>> because of the IdentityStore is non Serializable and make it >>>>>> transient, it will not stored with the User object when it cached, >>>>>> so we can't call the getCalim method in User object now. >>>>>> >>>>>> What I did is, get the user unique id from the user object that is >>>>>> stored in the cache and call the RealmService and get the User object >>>>>> again >>>>>> from the user core when it required. Is that the right behaviour that we >>>>>> expect in the new user core design or did I missed something ? >>>>>> >>>>>> >>>>>> public class User implements Serializable { >>>>>> private static final long serialVersionUID = 21578845544565554L; >>>>>> private String uniqueUserId; >>>>>> private String domainName; >>>>>> private String state; >>>>>> private transient IdentityStore identityStore; >>>>>> >>>>>> thanks >>>>>> >>>>>> *Harsha Thirimanna* >>>>>> *Associate Tech Lead | WSO2* >>>>>> >>>>>> Email: hars...@wso2.com >>>>>> Mob: +94715186770 <+94%2071%20518%206770> >>>>>> Blog: http://harshathirimanna.blogspot.com/ >>>>>> Twitter: http://twitter.com/harshathirimann >>>>>> Linked-In: linked-in: http://www.linkedin.com/pub/ha >>>>>> rsha-thirimanna/10/ab8/122 >>>>>> <http://wso2.com/signature> >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> Architecture@wso2.org >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Hasintha Indrajee >>>> WSO2, Inc. >>>> Mobile:+94 771892453 <+94%2077%20189%202453> >>>> >>>> >>> >>> *Harsha Thirimanna* >>> *Associate Tech Lead | WSO2* >>> >>> Email: hars...@wso2.com >>> Mob: +94715186770 <+94%2071%20518%206770> >>> Blog: http://harshathirimanna.blogspot.com/ >>> Twitter: http://twitter.com/harshathirimann >>> Linked-In: linked-in: http://www.linkedin.com/pub/ha >>> rsha-thirimanna/10/ab8/122 >>> <http://wso2.com/signature> >>> >>> On Sat, Mar 11, 2017 at 8:49 PM, Hasintha Indrajee <hasin...@wso2.com> >>> wrote: >>> >>>> Hi Jayanga, >>>> >>>> So what happens if we want to store user objects and then later if we >>>> want to retrieve user objects and try to access claims ? . Here we are >>>> storing user objects in authentication context, not in the identity store. >>>> And how are we storing user objects in the cache when the instance of >>>> identity store is neither serializable nor transient ? >>>> >>>> On Sat, Mar 11, 2017 at 8:34 PM, Jayanga Kaushalya <jayan...@wso2.com> >>>> wrote: >>>> >>>>> Hi Harsha, >>>>> >>>>> It was designed to be like that. User object will be cached in the >>>>> IdentityStore. So when you retrieving the user object from IdentityStore >>>>> again, it will be most probably from cache instead of connector. >>>>> >>>>> Thanks! >>>>> >>>>> *Jayanga Kaushalya* >>>>> Software Engineer >>>>> Mobile: +94777860160 <+94%2077%20786%200160> >>>>> WSO2 Inc. | http://wso2.com >>>>> lean.enterprise.middleware >>>>> >>>>> On Sat, Mar 11, 2017 at 7:41 PM, Harsha Thirimanna <hars...@wso2.com> >>>>> wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> In identity gateway, we have to cache the User object that is >>>>>> retrieved from user core within the authentication context and session >>>>>> context. After some times we have to get that user object and want to get >>>>>> the claims since it has the claim API within user object itself. But >>>>>> because of the IdentityStore is non Serializable and make it >>>>>> transient, it will not stored with the User object when it cached, >>>>>> so we can't call the getCalim method in User object now. >>>>>> >>>>>> What I did is, get the user unique id from the user object that is >>>>>> stored in the cache and call the RealmService and get the User object >>>>>> again >>>>>> from the user core when it required. Is that the right behaviour that we >>>>>> expect in the new user core design or did I missed something ? >>>>>> >>>>>> >>>>>> public class User implements Serializable { >>>>>> private static final long serialVersionUID = 21578845544565554L; >>>>>> private String uniqueUserId; >>>>>> private String domainName; >>>>>> private String state; >>>>>> private transient IdentityStore identityStore; >>>>>> >>>>>> thanks >>>>>> >>>>>> *Harsha Thirimanna* >>>>>> *Associate Tech Lead | WSO2* >>>>>> >>>>>> Email: hars...@wso2.com >>>>>> Mob: +94715186770 <+94%2071%20518%206770> >>>>>> Blog: http://harshathirimanna.blogspot.com/ >>>>>> Twitter: http://twitter.com/harshathirimann >>>>>> Linked-In: linked-in: http://www.linkedin.com/pub/ha >>>>>> rsha-thirimanna/10/ab8/122 >>>>>> <http://wso2.com/signature> >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> Architecture@wso2.org >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Hasintha Indrajee >>>> WSO2, Inc. >>>> Mobile:+94 771892453 <+94%2077%20189%202453> >>>> >>>> >>> >> > > > -- > Thanks & Regards, > > *Johann Dilantha Nallathamby* > Technical Lead & Product Lead of WSO2 Identity Server > Governance Technologies Team > WSO2, Inc. > lean.enterprise.middleware > > Mobile - *+94777776950* > Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* > -- *Thanuja Lakmal* Senior Software Engineer WSO2 Inc. http://wso2.com/ *lean.enterprise.middleware* Mobile: +94715979891 +94758009992
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
