cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CXF-5803) Injection of SecurityContext
Date Sun, 06 Jul 2014 20:50:33 GMT

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

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

As far as I understand the more sophisticated strategy (i.e, delaying the proxy injection)
would involve the synchronization to avoid thread safety issue for singletons so IMHO it is
not worth it. Keeping it as null is worse than we have it now, with NPE and a proper error
description. Throwing the exception at the very start up might also be possible but I'd rather
start with  adding a warning which would be consistent with what we have now IMHO

> 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: Sergey Beryozkin
>
> 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