[
https://issues.apache.org/jira/browse/CXF-8324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh resolved CXF-8324.
--------------------------------------
Resolution: Fixed
Thanks for the patch!
> 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
> Assignee: Colm O hEigeartaigh
> Priority: Major
> Fix For: 3.4.0
>
>
> 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
> [email protected]//org.apache.cxf.attachment.AttachmentUtil.setStreamedAttachmentProperties(AttachmentUtil.java:178)
> at
> [email protected]//org.apache.cxf.attachment.AttachmentDeserializer.cache(AttachmentDeserializer.java:242)
> at
> [email protected]//org.apache.cxf.attachment.AttachmentDeserializer.cacheStreamedAttachments(AttachmentDeserializer.java:216)
> at
> [email protected]//org.apache.cxf.attachment.AttachmentDeserializer.hasNext(AttachmentDeserializer.java:329)
> at
> [email protected]//org.apache.cxf.attachment.LazyAttachmentCollection.hasNext(LazyAttachmentCollection.java:77)
> at
> [email protected]//org.apache.cxf.attachment.AttachmentDeserializer.markClosed(AttachmentDeserializer.java:313)
> at
> [email protected]//org.apache.cxf.attachment.DelegatingInputStream.close(DelegatingInputStream.java:52)
> at
> [email protected]//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
> [email protected]//org.apache.cxf.endpoint.AbstractConduitSelector.complete(AbstractConduitSelector.java:208)
> at
> [email protected]//org.apache.cxf.endpoint.ClientImpl.completeExchange(ClientImpl.java:553)
> at
> [email protected]//org.apache.cxf.endpoint.ClientImpl.processResult(ClientImpl.java:605)
> at
> [email protected]//org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:540)
> at
> [email protected]//org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:440)
> at
> [email protected]//org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:355)
> at
> [email protected]//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)
