You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by GitBox <gi...@apache.org> on 2022/11/23 15:25:26 UTC

[GitHub] [cxf] aziubin commented on pull request #1033: CXF-8796: Replace REMOVED_MARKER with null

aziubin commented on PR #1033:
URL: https://github.com/apache/cxf/pull/1033#issuecomment-1325250610

   Hi @reta, thank you too for reproducing this issue and looking at code changes. The case when the last argument is omitted is not covered. The "argument type mismatch while invoking" error is blocking our migration from Axis to CXF. I put my effort mostly to understand if proposed change is isolated, safe and will not have negative impact on existing codebase. I did the following: verified that `REMOVED_MARKER` is not used in CXF code or out there; reviewed the code where `MessageContentsList.toArray` is used (that way I discovered an issue with bean validation, which is covered by this fix); reviewed the history of `MessageContentsList.java` file (that way I found CXF 2.0.3 SVN commit 587171, which introduced this issue - see [[CXF-1129] Fix issues with out of band headers causing marshalling issues Re-add asm jars to distribution](http://svn.apache.org/viewvc/cxf/trunk/api/src/main/java/org/apache/cxf/message/MessageContentsList.java?r1=587170&r2=587171&pathrev=1434564&)). As a 
 result, overriding `toArray` in my opinion looks like a missing change, which should have been done as part of commit 587171.
   
   Wider fix, which will also cover the case when the last argument is omitted, would need research and additional development and I am opened for it. Potentially, this is not going to be isolated and safe change, so I need to hear your opinion first before starting.
   
   The case with primitive type is different. Instead of an "argument type mismatch while invoking" error message, which does not allow us to understand the root cause of the error, there will be "null while invoking ..." message, which is correct and not confusing. Also, in opposite to the issue, which I am trying to fix, this case can be work around with a method wrapper, which has compatible wrapper class in the place of primitive type, for example `void allocateWrapper(Integer i) { allocate(i); } void allocate(int i) { }`. What do you think?
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscribe@cxf.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org