[
https://issues.apache.org/jira/browse/CXF-5803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14047708#comment-14047708
]
Andrei Shakirin commented on CXF-5803:
--------------------------------------
Hi Sergei,
After digging a bit into Jersey code, found the following:
Jersey implements a bit different concept of Context injections:
1. Independent on resource scopes (I tried both: Request and Singleton), all
injection activities in resource class happen only by receiving request.
Nothing are injected on service startup.
2. When request is coming, Jersey uses concept of ServiceLocator: it asks
ServiceLocator to find the resolver for specified injectee type and finally
resolver creates this injectee.
3. The injectee delegates methods call to ContainerRequestContext, containing
corresponded values for SecurityContext, headers, cookies, etc.
4. If @Context annotates unknown type, Jersey leaves it's value in null.
CXF proceeds that a bit differently and injects ThreadLocalProxies already on
server startup (InjectionUtils.injectContextProxyAndApplication()). By incoming
request CXF sets appropriate value to already injected ThreadLocalProxy
(InjectionUtils.injectContexts() -> ... -> createContextValue()).
I am going to apply solution you suggested as immediate fix. Anyway, for the
long terms, do you see any reason to rethink/revisit current context injection
approach in CXF? Does it have additional advantages?
> Injection of SecurityContext
> ----------------------------
>
> Key: CXF-5803
> URL: https://issues.apache.org/jira/browse/CXF-5803
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
> Affects Versions: 2.7.11
> Reporter: Andrei Shakirin
> Assignee: Andrei Shakirin
>
> Currently two different SecurityContext interfaces are available in CXF:
> a) standard java: javax.ws.rs.core.SecurityContext
> b) internal CXF: org.apache.cxf.security.SecurityContext
> Context injection using @Context annotation works only for standard one. If
> user purposely or deliberately tries to inject internal CXF SecurityContext,
> access to it caused not very informative NLP:
> {code}
> Caused by: java.lang.NullPointerException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.apache.cxf.jaxrs.impl.tl.ThreadLocalInvocationHandler.invoke(ThreadLocalInvocationHandler.java:36)
> at com.sun.proxy.$Proxy5.getUserPrincipal(Unknown Source)
> at
> demo.rs.security.SimpleCustomerService.getCustomer(SimpleCustomerService.java:26)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:181)
> at
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:97)
> ... 26 more
> {code}
> I would propose either to support injections of both contexts or provide more
> clear error message.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
