When using a jersey client to retrieve multipart from a jersey server in a jersey-client/cxf mixed app reports that there is a missing start boundary.
After debugging I found that MediaType in jsr311-api-1.0.jar (used by cxf 2.2.2) is converting headers to lowercase. Since com.sun.jersey.multipart.Boundary.java is generating boundaries as
return new StringBuilder("Boundary_").
with an Upper case "Boundary", cxf would fail to find it in the body after the boundary case in the Content-Type is lowercased.
I am using jersey-client, yet javax.ws.rs is loaded from cxf given that the META-INF/services/javax.ws.rs.ext.RuntimeDelegate is found first in cxf and not in jersey-core.(I suspect that the web loader in tomcat finds "c" before "j")
Jersey's header and body are practically OK. It would be a cxf bug, except that it has to do with classpath conflicts between cxf and jersey-client. This could be easily fixed in Jersey by producing an all lowercase boundary.
The actual issue is that I have a legacy app that mixes both cfx and jersey-client. IMPORTANT: I am using the jersey client but cxf takes over. It would be OK for cfx to take over and it would do the right thing had it been lowercase.
The current workaround is to:
extract jersey's javax.ws.rs.ext.RuntimeDelegate
build the client WAR with the structure WEB-INF/classes/META-INF/services/javax.ws.rs.ext.RuntimeDelegate
start the app.
This is not entirely proper since the portions of the legacy application that use cxf would load jersey javax.ws.rs now.
The real fix is to force jersey-client to load its own classes, not going to the RuntimeDelegate et al to get the class names it requires. Going to get class names for RuntimeDelegate breaks jersey's encapsulation. It is an invitation for bugs.