swf 2.0.1 binding problems with multipartrequests

[geoberle]

hi everybody.
i am using swf-2.0.1.CI-477. when i perform databinding from a multipart/form-data encoded form containing a <input type="file"/> element (aka fileupload) to a modelbean, i get the following expception.

java.lang.IllegalArgumentException: Map key 'attachment' has value [org.springframework.web.multipart.commons.CommonsMultipartFile@2002cfa5] that is not of expected type [class java.lang.String], instead it is of type [org.springframework.web.multipart.commons.CommonsMultipartFile]
        at org.springframework.binding.collection.MapAccessor.assertKeyValueInstanceOf(MapAccessor.java:421)
        at org.springframework.webflow.core.collection.LocalParameterMap.get(LocalParameterMap.java:133)
        at org.springframework.webflow.core.collection.LocalParameterMap.get(LocalParameterMap.java:113)
        at org.springframework.webflow.mvc.view.AbstractMvcView$RequestParameterExpression.getValue(AbstractMvcView.java:450)
        at org.springframework.binding.mapping.impl.DefaultMapping.map(DefaultMapping.java:113)
        at org.springframework.binding.mapping.impl.DefaultMapper.map(DefaultMapper.java:87)
        at org.springframework.webflow.mvc.view.AbstractMvcView.bind(AbstractMvcView.java:287)
        at org.springframework.webflow.mvc.view.AbstractMvcView.processUserEvent(AbstractMvcView.java:184)
        at org.springframework.webflow.engine.ViewState.resume(ViewState.java:187)
        at org.springframework.webflow.engine.Flow.resume(Flow.java:535)
        at org.springframework.webflow.engine.impl.FlowExecutionImpl.resume(FlowExecutionImpl.java:261)

somehow the CommonsMultipartFile object finds its way into the LocalParameterMap, where only String based values are expected.

after browsing the code, i think i might have found a clue where this happens. the class org.springframework.webflow.context.servlet.Servle tExternalContext creates in its init method a LocalParameterMap with a HttpServletRequestParameterMap based on a request which might be a DefaultMultipartHttpServletRequest object.

this.requestParameterMap = new LocalParameterMap(new HttpServletRequestParameterMap(request)); // request might a DefaultMultipartHttpServletRequest

the HttpServletRequestParameterMap class implements special handling for MultipartHttpServletRequest in its getAttribute(String key) method, extracting entries from the fileMap as well.

if (request instanceof MultipartHttpServletRequest) {
	MultipartHttpServletRequest multipartRequest = (MultipartHttpServletRequest) request;
	Object data = multipartRequest.getFileMap().get(key);
	if (data != null) {
		return data;
	}
}

once in the LocalParameterMap, databinding fails due to the strict type checking in the MapAccessor.assertKeyValueInstanceOf method.

might this behaviour be a bug or is this kind of databinding not supported?

best regards
gerd oberlechner

[Keith Donald]

This kind of data binding should be supported. LocalParameterMap actually has some accessors for accessing multipart files. Unfortunately, as you say, because the general parameterMap.get(String) operation returns a String, and that is what is called during data binding, binding of multipart file parameters is failing.

We'll address this for 2.0.2, also available in an upcoming nightly build. 2.0.1 is on its way up to Sourceforge so it won't make 2.0.1.

Keith

[geoberle]

hi keith
thanks for your reply. i'm looking forward to the next nightly builds.

gerd

[Keith Donald]

I just committed a fix for this to trunk; will be available in the next nightly.

Keith

[geoberle]

that's an incredible fast fix.
i will report back after i tested the nightly build in my application.

gerd

[geoberle]

with nightly build 2.0.2.CI-478 the error occurs a few method calls later in the AbstractMvcView.FormatterBackendMappingConversionE xecutor inner class.

in its execute(Object source, Object context) method the source object gets casted to a String, which causes a ClassCastException when "source" is a MultipartFile object

java.lang.ClassCastException: org.springframework.web.multipart.commons.CommonsMultipartFile
        at org.springframework.webflow.mvc.view.AbstractMvcView$FormatterBackedMappingConversionExecutor.execute(AbstractMvcView.java:480)
        at org.springframework.binding.mapping.impl.DefaultMapping.map(DefaultMapping.java:126)
        at org.springframework.binding.mapping.impl.DefaultMapper.map(DefaultMapper.java:87)
        at org.springframework.webflow.mvc.view.AbstractMvcView.bind(AbstractMvcView.java:287)
        at org.springframework.webflow.mvc.view.AbstractMvcView.processUserEvent(AbstractMvcView.java:184)
        at org.springframework.webflow.engine.ViewState.resume(ViewState.java:187)
        at org.springframework.webflow.engine.Flow.resume(Flow.java:535)

[Keith Donald]

Finally got back to this...

Yes, that was an example of me trying to be too quick with fixes.

I just committed a fix with an corresponding unit test showing successful multipart file binding. I do have a question. Would you prefer to work with the MultiPart object directly in your object, or would you prefer it to be converted to a byte[]? Right now there is no support for special MultiPart->byte[] conversation, but it could be added here as well.

Thanks

Keith

[geoberle]

mhm... i prefer to work with MultipartFile objects because i need the original filename submitted with the httprequest. but truly there may be some scenarios where you are only interessted in the plain byte[].

a MultipartFile->byte[] conversion would allow you to keep out the dependency on the MultipartFile interface, which is always a good thing.

[geoberle]

i have tested the latest nightly build (2.0.2.CI-482) for the MultiPart handling and it works as expected.

thank you very much.
gerd

[Keith Donald]

Gerd,

No problem. Would you mind creating a JIRA for the byte conversion enhancement? Just so it doesn't get lost.

Thanks!

keith