[
https://issues.apache.org/jira/browse/CXF-5803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14031983#comment-14031983
]
Sergey Beryozkin commented on CXF-5803:
---------------------------------------
Hi Andrei
It would be difficult to do - at the moment the runtime injects the proxies it
does not know if ContextProvider for the unknown context is available due to
the ordering issues. Making changes to ensure the providers are registered
first before the introspection begins would be very sensitive and it will still
not work completely because providers can also have contexts injected. Perhaps
the solution would be to do a post-initialization run and check all the
injected proxies when we already have everything registered - this is in itself
can be difficult to do and will slow down the registration in most cases where
no custom contexts are even used. But even if we make it work then we would
still see NPE in the application code - yes we can 'prevent' by throwing some
specific exception if we do detect that a custom context can not work but as I
said I'm not convinced it would better than NPE.
Jersey allows registering custom contexts - I'm not aware of how they do it
though. If you'd like then please check what Jersey does if a custom context
can not be satisfied. I'd settle though with a warning log message and NPE
Cheers, Sergey
> 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)
