[ 
https://issues.apache.org/jira/browse/CXF-5803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14031234#comment-14031234
 ] 

Sergey Beryozkin commented on CXF-5803:
---------------------------------------

I'm changing my mind again :-). WARNING is actually correct: after all we have 
an application code with the expectations that contexts will be populated by 
the runtime and if a given context has no current value it is a WARNING.
Re NPE: as I said IMHO we should keep it as is - the fact ContextProvider is 
not registered is a bug on its own. Note JAX-RS 2.0 API itself has moved toward 
using NPE as a preferred option for various setup/init related issues, instead 
of exceptions like IllegalStateException.
Finally, a user can always register ExceptionMapper catching NPE

So, adding a WARNING should be a reasonable solution here

Sorry for the noise :-)

> 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)

Reply via email to