I've seen different behavior with Spring/Jersey when you mark a class with
@Component vs @Service. In the Stack Overflow example, the class is marked
with @Component. This is a shot in the dark, but you could try @Service
instead. I don't recall exactly the problems I had seen but injection
differences do sound familiar.
Also, I second the idea of creating a services layer separate from the
resource classes. I like it because then I can ensure that whether a
resource is calling a spring secured method directly, or indirectly
through other service methods, that the access control is not circumvented
in any way. And also your business logic is contained in the service
classes as well, and so your resource classes really just become a simple
layer to primarily marshall between HTTP/JSON and Java POJOs.
--joe
On 7/27/15, 12:14 PM, "Richard McAleer" <richard.mcaleer_at_caris.com> wrote:
>Hi,
>
>I've been having an issue with using rest resources that inject values
>using @Context while also being secured by spring-security using the
>@PreAuthorize annotation. I found a stack overflow question that is the
>exact problem I'm seeing:
>
>http://stackoverflow.com/questions/21586070/spring-security-preauthorize-b
>reaks-jersey-context-uriinfo-injection
>
>However, the work-around given as the accepted answer isn't overly
>practical for the application I work on. We have a lot of rest
>resources and having to add @Context method params for the UriInfo,
>ServletRequest and ServletResponse to every @GET and @POST method is a
>lot more annoying than just having a common base class that has them
>specified as member variables.
>
>Has anyone else has come across this issue and know if there's any other
>ways around it that would allow me to use the @Context annotation on
>class members instead of having to add them as method parameters? I've
>seen another suggested work-around of moving the @PreAuthorize
>annotation out of the rest resources to the services layer (or some
>other application layer), but that isn't really a practical solution for
>us either.
>
>Thanks,
>Richard