Robin Schimpf created CXF-8324:
----------------------------------
Summary: ClassCastException at
AttachmentUtil.setStreamedAttachmentProperties
Key: CXF-8324
URL: https://issues.apache.org/jira/browse/CXF-8324
Project: CXF
Issue Type: Bug
Affects Versions: 3.3.2
Environment: CXF used within Wildfly 17
Java 11
Reporter: Robin Schimpf
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.
{code:java}
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
{code}
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)
{code:java}
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
}
{code}
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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
