Hi Chandan, I like your proposal, too. +1
Can we ensure that a ThreadLocal is always valid also in case of a thread pooled environment? http://stackoverflow.com/questions/7403809/java-cached-thread-pool-and-thre ad-local It could also cause issues in case of hot deployment: https://weblogs.java.net/blog/jjviana/archive/2010/06/10/threadlocal-thread -pool-bad-idea-or-dealing-apparent-glassfish-memor Just for information. Greetings, Stephan On 13.12.13 16:06, "V.A, Chandan" <[email protected]> wrote: >Hi Vincenzo, >As Stephan mentioned you could inherit from class ODataJPAProcessor and >implement the behavior defined in ODataJPAProcessorDefault. > >You can use the API - JPAProcessor for processing an OData Request. >JPAProcessor is already available to you as a protected member variable >from ODataJPAProcessor. >However you cannot use (as of now) the ODataJPAResponseBuilder as it is >not part of API and will not be accessible when the project is executed >in an OSGi container. > >@All >Secondly just thinking out loud. >Can we push the logic of handling security to JPA Entity Listeners. Where >one could define Entity Listeners with different life cycle call back >methods to handle security. Here the only thing that is required is the >Current Principal from HTTP Request. This can be passed using a Thread >Local variable. If this sounds a better solution then we can think of >introducing context variables holding context information in a thread >local variable which can then be used by call back methods. > >WDYT? > > > >Thanks, >Kind Regards >Chandan VA > >-----Original Message----- >From: Klevenz, Stephan [mailto:[email protected]] >Sent: Friday, December 13, 2013 5:41 PM >To: [email protected] >Subject: Re: How to hook up permission check into JPA-scenario? > >Vincenzo, > >The current snapshot version gives access to request object via the >ODataContext class: > >https://issues.apache.org/jira/browse/OLINGO-26 > >To hook into JPA processor implementation my idea would be to derive from >ODataJPAProcessor (api) and re-implement the behavior of >ODataJPAProcessorDefault (core) and add here your security checks. Maybe >Chandan can hook in here. > >I have never tried this scenario and you have to try out. If it leads to >success then good :) if not then continue this discussion. > >Regards, >Stephan > > >On 13.12.13 10:54, "Vincenzo Turco" <[email protected]> wrote: > >>Hi all, >>I have exposed my JPA entities through the JPA processor and it works >>great. >>Now I have added authentication to my oData service, through the >>appropriate configuration in web.xml. >>I would like to restrict the entries returned by the odata service >>according to the logged in user. >>Is there any way to hook up custom logic (e.g. in the JPA processor) to >>do >>so? >>Also any alternative solution would be greatly valued. >>Thanks a lot for your time and attention >>Regards >>Vincenzo >> >> >>-- >> >> >>Vincenzo Turco >
