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

ASF GitHub Bot commented on CXF-7309:
-------------------------------------

Github user nhtzr commented on a diff in the pull request:

    https://github.com/apache/cxf/pull/253#discussion_r109967425
  
    --- Diff: 
rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/InjectionUtils.java 
---
    @@ -1167,10 +1161,12 @@ public static void injectContextMethods(Object 
requestObject,
                     if (!cri.isSingleton()) {
                         InjectionUtils.injectThroughMethod(requestObject, 
method, o, message);
                     } else {
    -                    ThreadLocalProxy<Object> proxy 
    -                        = 
(ThreadLocalProxy<Object>)cri.getContextSetterProxy(method);
    +                    Object proxy = extractFromSetter(requestObject, 
method);
    +                    if (!(proxy instanceof ThreadLocalProxy)) {
    --- End diff --
    
    I think it will be fine, because we are not messing with the unexpected 
value (so no code breakage outside) and Line 1169 is now unsafe unless we make 
that check (so no code breakage in this method).
    
    In case of CXF-7309, the value returned here is another `ThreadLocalProxy` 
different from the one in `cri.getContextSetterProxy(method)`
    This happens because of a singleton filter in a OSGI bundle. Whenever I hot 
re deploy that bundle, a new filter provider instance is created, and all OSGI 
proxy references (saved as `requestObject` here) are redirected to this new 
instance, but CXF has no way to know it has to update its internal 
`AbstractResourceInfo#getSetterProxyMap` to reflect that. All of this causes 
CXF to inject references into stale ThreadLocalProxies that no one is gonna use.
    
    Hence the patch, which basically translates to "check getter first; check 
cri otherwise if the getter is not convenient"
    
    
    As a side note: Now that you mention bean naming sense.
    I reread the `@Context` documentation, and it does say that it should 
annotate bean property method (other options are a field or a parameter). 
:thinking: 
    Do you think it would be beneficial to drop the 
`AbstractResourceInfo#getSetterProxyMap` and instead rely on getters?
    I think it would be good, but maybe the change is big enough for 
reconsideration.
    
    
    I hope I addressed all you asked!


> JAX-RS @Context fields throw NPE in OSGI hot deployed filters
> -------------------------------------------------------------
>
>                 Key: CXF-7309
>                 URL: https://issues.apache.org/jira/browse/CXF-7309
>             Project: CXF
>          Issue Type: Bug
>          Components: JAX-RS
>    Affects Versions: 3.0.12, 3.1.10
>            Reporter: Ezequiel Rosas Garcia
>
> Hello. 
> This happens with a PreMatching filter that is loaded from OSGI.
> I found that when the filter OSGI bundle is hot deployed, all other already 
> running bundles using it would start throwing NPE when trying to access the 
> injected fields inside the filter (like CXF-7248)
> This seems to happen due to other bundles retaining their ThreadLocal 
> references in their own AbstractResourceInfo#getSetterProxyMap() while the 
> OSGI Proxy starts redirecting to a new filter object which has new different 
> ThreadLocal references as soon as it is used for the first time after hot re 
> deployment.
> Test: 
> [Link](https://github.com/nhtzr/osgiee-web/blob/42faf2cbe0c54497ea706e97cd91a9ee8c29e020/src/test/java/mx/nhtzr/osgiee/web/internal/MyFilterTest.java)
> PR: [Link](https://github.com/apache/cxf/pull/253)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to