I ran into the same problem with inconsistent behavior when uploading
files. Sometimes i get a RequestFacade, and sometimes I get the right
MultiPartRequestWrapper.
I dug into the struts source code a little and I think I found the
culprit.
in org.apache.struts2.dispatcher.FilterDispatcher there's a method
named "prepareDispatcherAndWrapRequest" where the RequestFacade
becomes the right kind of Request object. In the code, the wrapping
is within a conditional block where it will only be wrapped when the
Dispatcher instance is null. The problem when uploading a file is
that it's not always null.
Is that the expected behavior of this method? I've never dug this deep.
The good news is that the contextCleanup filter seems to take care of
making that Dispatcher instance null.
Finally, I hesitate suggesting a change in a class at such a
foundational point in the framework, but what would happen if the
request hits the wrapping part of the code outside when the
Dispatcher instance is not null? My file upload problems are fixed,
but what other problems would this cause?
======= Existing code for FilterDispatcher ================
protected HttpServletRequest prepareDispatcherAndWrapRequest(
HttpServletRequest request,
HttpServletResponse response)
throws ServletException {
Dispatcher du = Dispatcher.getInstance();
// Prepare and wrap the request if the cleanup filter hasn't
already, cleanup filter should be
// configured first before struts2 dispatcher filter, hence
when its cleanup filter's turn,
// static instance of Dispatcher should be null.
if (du == null) {
Dispatcher.setInstance(dispatcher);
// prepare the request no matter what - this ensures
that the proper character encoding
// is used before invoking the mapper (see WW-9127)
dispatcher.prepare(request, response);
try {
// Wrap request first, just in case it is multipart/
form-data
// parameters might not be accessible through before
encoding (ww-1278)
request = dispatcher.wrapRequest(request,
getServletContext());
} catch (IOException e) {
String message = "Could not wrap servlet request
with MultipartRequestWrapper!";
LOG.error(message, e);
throw new ServletException(message, e);
}
} // <------
//THE END OF THE LOGiC BLOCK HERE MEANS
//THAT THE Request ONLY GETS WRAPPED WHEN THE Dispatcher
//INSTANCE IS NULL. WHEN UPLOADING, IT'S SOMETIMES NOT null
else {
dispatcher = du;
}
return request;
}
======= Moving the wrapping outside of the logic block ================
======= wraps the request even if the Dispatcher is not null ==========
protected HttpServletRequest prepareDispatcherAndWrapRequest(
HttpServletRequest request,
HttpServletResponse response)
throws ServletException {
Dispatcher du = Dispatcher.getInstance();
// Prepare and wrap the request if the cleanup filter hasn't
already, cleanup filter should be
// configured first before struts2 dispatcher filter, hence
when its cleanup filter's turn,
// static instance of Dispatcher should be null.
if (du == null) {
Dispatcher.setInstance(dispatcher);
}
else {
dispatcher = du;
}
//MOVING THE WRAPPING CODE HERE
//SO THE Request ALWAYS GETS WRAPPED
// prepare the request no matter what - this ensures
that the proper character encoding
// is used before invoking the mapper (see WW-9127)
dispatcher.prepare(request, response);
try {
// Wrap request first, just in case it is multipart/
form-data
// parameters might not be accessible through before
encoding (ww-1278)
request = dispatcher.wrapRequest(request,
getServletContext());
} catch (IOException e) {
String message = "Could not wrap servlet request
with MultipartRequestWrapper!";
LOG.error(message, e);
throw new ServletException(message, e);
}
return request;
}
============================
Thanks,
Eric Rank
Dave Newton wrote:
Did either of you try specifying the context cleanup
filter?
<filter>
<filter-name>contextCleanup</filter-name>
<filter-class>
org.apache.struts2.dispatcher.ActionContextCleanUp
</filter-class>
</filter>
and put it first in the filter mapping.
I have yet to have any issues w/ file upload since
including that and I still think I vaguely recall a
thread about this a long time ago but can no longer
find any references to it, so I could be way off-base.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
