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

Aki Yoshida commented on CXF-4437:
----------------------------------

Hi Jason,
that explains the reason. The request message contains the invocation context, 
whereas the response message does not. So, the current code that copies the 
response message properties into the response context should not create a 
recursive reference. However, if the request message is directly used as the 
response message, there will be a recursive reference.

So, if you are not using the request message directly as the response message, 
this problem should not occur.

@Dan,
to be on the protected side, we should change the code to not put the 
invocation context into the response context.
In addition, should we even get rid of this log line or log only the keys? I 
don't know if it is okay to log the context properties from the security point 
of view even if the level is set to FINEST. 

regards, aki

                
> Stack Overflow exception in org.apache.cxf.endpoint.ClientImpl when logging 
> set to FINE
> ---------------------------------------------------------------------------------------
>
>                 Key: CXF-4437
>                 URL: https://issues.apache.org/jira/browse/CXF-4437
>             Project: CXF
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.6.1
>         Environment: JDK 1.6.0_32
>            Reporter: Jason Pell
>             Fix For: 2.6.2
>
>
> Hi,
> I can reproduce the issue in our code, but will probably struggle to
> create a test case.  
> I have narrowed down the culprit (in 2.6.1) to 
> org.apache.cxf.endpoint.ClientImpl line 636
> The method protected Object[] processResult(Message message,
>                                    Exchange exchange,
>                                    BindingOperationInfo oi,
>                                    Map<String, Object> resContext)
> throws Exception {
> And the code:
> if (LOG.isLoggable(Level.FINE)) {
>                     LOG.fine("set responseContext to be" + resContext);
>                 }
> The code to add all the properties from the message to resContext, creates a 
> recursive reference, because the message already has a reference to 
> resContext.  This causes the logging to fail as when it tries to serialise 
> the content of the map, it gets a stack overflow.
> The org.apache.cxf.invocation.context contains the ResponseContext and
> the ResponseContext contains the org.apache.cxf.invocation.context
> To prove my hypothesis I added the following code to replace the log call:
> HashMap contextMap = (HashMap)
> resContext.get("org.apache.cxf.invocation.context");
>                         HashMap responseContextMap = (HashMap)
> contextMap.get("ResponseContext");
>                         HashMap secondContextMap = (HashMap)
> responseContextMap.get("org.apache.cxf.invocation.context");
>                         if (secondContextMap != null) {
>                                 System.out.println("Oh boy here is the 
> error!");
>                         }
> And I got the Oh boy here is the error! message back.
> The original stack trace is:
> java.lang.StackOverflowError
>         at java.util.HashMap$EntrySet.iterator(HashMap.java:950)
>         at java.util.AbstractMap.toString(AbstractMap.java:478)
>         at java.lang.String.valueOf(String.java:2826)
>         at java.lang.StringBuilder.append(StringBuilder.java:115)
>         at java.util.AbstractMap.toString(AbstractMap.java:490)
>         at java.lang.String.valueOf(String.java:2826)
>         at java.lang.StringBuilder.append(StringBuilder.java:115)
>         at java.util.AbstractMap.toString(AbstractMap.java:490)
>         at java.lang.String.valueOf(String.java:2826)
>         at java.lang.StringBuilder.append(StringBuilder.java:115)
>         at java.util.AbstractMap.toString(AbstractMap.java:490)
>         at java.lang.String.valueOf(String.java:2826)
>         at java.lang.StringBuilder.append(StringBuilder.java:115)
>         at java.util.AbstractMap.toString(AbstractMap.java:490)
>         at java.lang.String.valueOf(String.java:2826)
>         at java.lang.StringBuilder.append(StringBuilder.java:115)
>         at java.util.AbstractMap.toString(AbstractMap.java:490)
>         at java.lang.String.valueOf(String.java:2826)
>         at java.lang.StringBuilder.append(StringBuilder.java:115)
>         at java.util.AbstractMap.toString(AbstractMap.java:490)
>         at java.lang.String.valueOf(String.java:2826)
>         at java.lang.StringBuilder.append(StringBuilder.java:115)
>         at java.util.AbstractMap.toString(AbstractMap.java:490)
>         at java.lang.String.valueOf(String.java:2826)
>         at java.lang.StringBuilder.append(StringBuilder.java:115)
>         at java.util.AbstractMap.toString(AbstractMap.java:490)
>         at java.lang.String.valueOf(String.java:2826)
>         at java.lang.StringBuilder.append(StringBuilder.java:115)
>         at java.util.AbstractMap.toString(AbstractMap.java:490)
> <snip>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to