According to ServiceLayerCache, the cache is implemented as a static variable, so locator services and methods may be cached for all users. Your locators and service instances should therefore not keep any user-specific info, but rather obtain it in each method through a call to getLocalThreadRequest() as you suggest.
/dmc On Tue, Feb 8, 2011 at 3:11 PM, khiem nguyen <khi...@googlemail.com> wrote: > what if the decryption stuff is also user/session-specific ? > i read that rf caches locator-instances, will it be safe if i use > getLocalTheadRequest() at locator-methods to get the session-stuffs for > decrypting the data ? > > thanx > > > On Tue, Feb 8, 2011 at 6:13 PM, David Chandler <drfibona...@google.com>wrote: > >> Hi khiem, >> As of 2.1.1, you can replace static findEntity() methods using a Locator >> and ServiceLocator. Updated RF docs are available at >> http://code.google.com/webtoolkit/doc/trunk/DevGuideRequestFactory.html. >> A locator method implemented in a separate Locator class could decrypt the >> entity and retrieve the relations also. >> >> HTH, >> /dmc >> >> On Tue, Feb 8, 2011 at 4:24 AM, khiem nguyen <khi...@googlemail.com>wrote: >> >>> hi, >>> >>> i'm using Proxy-Entity with Locator for a gwt-app & got into problems >>> concerning this issue >>> http://code.google.com/p/google-web-toolkit/issues/detail?id=5724 >>> >>> >>> eg. i have several users, which retrieve data from DB, the data will be >>> retrieve from db & decrypted before delivering back to user, because of the >>> way static find() in locator work, when i do fire().with(...) with >>> relations, i cannot come to the relations of the entity to decrypt it. one >>> workaround would be only retrieve the ids of the relation & then get the >>> relations manually, but it seems not a good solution when u have alot of >>> nested-relations. >>> >>> what could be the solution here ? i guess a >>> customized ServiceLayerDecorator ??? can someone give some hints how to >>> start with it ? >>> >>> thanx >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Google Web Toolkit" group. >>> To post to this group, send email to google-web-toolkit@googlegroups.com >>> . >>> To unsubscribe from this group, send email to >>> google-web-toolkit+unsubscr...@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/google-web-toolkit?hl=en. >>> >> >> >> >> -- >> David Chandler >> Developer Programs Engineer, Google Web Toolkit >> w: http://code.google.com/ >> b: http://googlewebtoolkit.blogspot.com/ >> t: @googledevtools >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Google Web Toolkit" group. >> To post to this group, send email to google-web-toolkit@googlegroups.com. >> To unsubscribe from this group, send email to >> google-web-toolkit+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/google-web-toolkit?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To post to this group, send email to google-web-toolkit@googlegroups.com. > To unsubscribe from this group, send email to > google-web-toolkit+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > -- David Chandler Developer Programs Engineer, Google Web Toolkit w: http://code.google.com/ b: http://googlewebtoolkit.blogspot.com/ t: @googledevtools -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
