[CXF-8324] ClassCastException at AttachmentUtil.setStreamedAttachmentProperties

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 3.3.2
• Fix Version/s: 3.4.0

Environment

CXF used within Wildfly 17

Java 11

• Estimated Complexity: Unknown
• Assignee: Colm O hEigeartaigh
• Reporter: Robin Schimpf
• Created: 10/Aug/20 06:21
• Updated: 22/Dec/21 20:43
• Resolved: 12/Aug/20 09:31

Description

I am currently creating a Webservice Client and have set the AttachmentDeserializer.ATTACHMENT_MEMORY_THRESHOLD property as an integer. When sending a request the following exception occured.

Caused by: java.lang.ClassCastException: class java.lang.Integer cannot be cast to class java.lang.String (java.lang.Integer and java.lang.String are in module java.base of loader 'bootstrap')
        at org.apache.cxf@3.3.2//org.apache.cxf.attachment.AttachmentUtil.setStreamedAttachmentProperties(AttachmentUtil.java:178)
        at org.apache.cxf@3.3.2//org.apache.cxf.attachment.AttachmentDeserializer.cache(AttachmentDeserializer.java:242)
        at org.apache.cxf@3.3.2//org.apache.cxf.attachment.AttachmentDeserializer.cacheStreamedAttachments(AttachmentDeserializer.java:216)
        at org.apache.cxf@3.3.2//org.apache.cxf.attachment.AttachmentDeserializer.hasNext(AttachmentDeserializer.java:329)
        at org.apache.cxf@3.3.2//org.apache.cxf.attachment.LazyAttachmentCollection.hasNext(LazyAttachmentCollection.java:77)
        at org.apache.cxf@3.3.2//org.apache.cxf.attachment.AttachmentDeserializer.markClosed(AttachmentDeserializer.java:313)
        at org.apache.cxf@3.3.2//org.apache.cxf.attachment.DelegatingInputStream.close(DelegatingInputStream.java:52)
        at org.apache.cxf@3.3.2//org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:60)
        at org.apache.cxf.impl//org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:671)
        at org.apache.cxf@3.3.2//org.apache.cxf.endpoint.AbstractConduitSelector.complete(AbstractConduitSelector.java:208)
        at org.apache.cxf@3.3.2//org.apache.cxf.endpoint.ClientImpl.completeExchange(ClientImpl.java:553)
        at org.apache.cxf@3.3.2//org.apache.cxf.endpoint.ClientImpl.processResult(ClientImpl.java:605)
        at org.apache.cxf@3.3.2//org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:540)
        at org.apache.cxf@3.3.2//org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:440)
        at org.apache.cxf@3.3.2//org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:355)
        at org.apache.cxf@3.3.2//org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:313)
        at org.apache.cxf.impl//org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
        at org.apache.cxf.impl//org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:140)
        ... 77 more

Only after receiving this exception I realized (through reading the implementation) the only two allowed values for the property are Long and String.

For me the current implementation is too optimistic and pesimistic at the same time. The check if the given value is a Long is too optimistic because the user could also provide an integer or even a short if the value he wants to set is small. And the assumtion that any non Long value is a String is overly optimistic and in the end leads to the shown Exception.

I would propose to change the implementation to something like this (if there is no hard requirement that the user has to provide an Long or String)

if (threshold instanceof Number) {
    bos.setThreshold(((Number)threshold).longValue());
} else if (threshold instanceof String) {
    bos.setThreshold(Long.parseLong((String)threshold));
} else {
    // throw some descriptive exception
}

The same change can also be used for the other 2 properties set in this method.
Providing some information in the JavaDoc of the mentioned property about allowed values would also be helpful.

Issue Links

• links to: GitHub Pull Request #688