Hi all, thanks for your kind help. Since the ODataJPAResponseBuilder is not part of the api, I understand that the strategy of extending ODataJPAProcessor is not feasible. This is because re-implementing ODataJPAResponseBuilder looks like a big effort, but please feel free to correct me if I'm wrong.
Imho, as an api-user, the scenario where access control is enforced through Entity Listeners is of the greatest interest. It would be great if a general idea of the timeframe for releasing this feature could be made available, as I severely need it for my current project. Thanks, regards Vincenzo 2013/12/16 V.A, Chandan <[email protected]> > Hello All > Then I will outline a proposal in the Olingo wiki explaining how we could > pass the OData JPA context (in a fail safe mode) to the JPA entity > listeners. > > Thanks, > Kind Regards > Chandan VA > > > -----Original Message----- > From: Klevenz, Stephan [mailto:[email protected]] > Sent: Friday, December 13, 2013 8:56 PM > To: [email protected] > Subject: Re: How to hook up permission check into JPA-scenario? > > 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 > > > > -- Vincenzo Turco
