cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrei Shakirin (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CXF-5803) Injection of SecurityContext
Date Mon, 16 Jun 2014 13:46:03 GMT

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

Andrei Shakirin commented on CXF-5803:
--------------------------------------

Hi Sergei,
OK, makes sense. My concern was that stack trace currently makes impression that the field
was injected, but somehow in the wrong way (or incomplete, etc). That can confuse the user.
I would prefer either to throw more clear exception or leave field not injected at all (caused
NLP in custom code). Of course, warning can be helpful as well.
Let me investigate the topic a bit more in Jersey - I would say more next week after vacation
:)
Regards,
Andrei.

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

Mime
View raw message