Thanks, Joe. Just a quick, if not short, response. I think the next
thing I do should be to show some code. See within:
<SNIP>
On Thu, 24 Feb 2005 09:06:48 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote:
> At 11:09 PM -0800 2/23/05, Dakota Jack wrote:
> >Joe,
> >
> >I have rethought recent discussions on multipart requests and have a
> >different proposal. What I would suggest would be to take the whole
> >multipart business out of the framework altogether and to treat it as
> >I think it should be treated, as just another Action.
> >
> >There is nothing about a multipart request that indicates that it
> >should be take care of in any special manner
>
> That's not entirely true, in that one must be sure to wrap a
> multipart request in *something* which can deal with the special
> cases of that encoding type before any attempts are made to read the
> request input stream.
</SNIP>
I am not sure what you are thinking but the wrappers really are just
decorations and are not necessary. The only tricky part is in
RequestUtils' populate method vis-a-vis ActionForm.
The request is wrapped in the UploadMultipartWrapper, UNWRAPPED twice,
MISIDENTIFIED once under Globals.MULTIPART_KEY (unless I am mistaken
about this), and only USED once in RequestUtils. All in all, if the
wrapper were just completely dumped and the wrapping code put into
RequestUtils everything would immediately be better with no real
changes. Something probably should be done with the mistaken
identification, unless, as I said, I somehow have something wrong
about that. But, since the same key is used for
MultipartRequestHandler, I don't see how I can be wrong about that. I
assume you would not use the same key under Globals for two different
and inconsistent class types.
Not only is the wrapper not needed in Struts, but the actual code
seemingly is a quite a little bit off, unless I am missing something
that is not obvious at all. The MultipartRequestWrapper in Struts
1.2.6 is used at the following places only and is used only to create
two fields: (1) a Map of parameter names/values and (2) the request.
RequestProcessor(677,1043,1044,1074,1075)
677
protected HttpServletRequest processMultipart(HttpServletRequest request) {
//....
if ((contentType != null) &&
contentType.startsWith("multipart/form-data")) {
return (new MultipartRequestWrapper(request));
//....
1043,1044,1074, 1075 These merely UNWRAP the request object.
IncludeAction (110,111) These merely UNWRAP the request object.
ConfigHelper (255,260) also in ConfigHelperInterface, of course.
public MultipartRequestWrapper getMultipartRequestWrapper() {
//....
return (MultipartRequestWrapper)
this.request.getAttribute(Globals.MULTIPART_KEY);
}
I may be off the wall here, but this does not make any sense and can
just be jettisoned as a noodle that is unwelcome in the spaghetti,
because the Globals.MULTIPART_KEY is used to store a
MultipartRequestHandler object. Isn't it? This all seems to be code
that is not used and it seemingly is a good thing it is not. This
code should be torn out, perhaps?
See getMultipartHandler in RequestUtils, ll. 514 ff, which uses
Globals.MULTIPART_KEY for the MultipartRequestHandler and not the
MultipartRequestWrapper. So the only real use for the wrapper, other
than (1) apparent mistaken code that could create an error that would
be really hard to find and (2) having to UNDO the wrapping is in:
RequestUtils(621,622)
private static Map getAllParametersForMultipartRequest(
HttpServletRequest request,
MultipartRequestHandler multipartHandler) {
Map parameters = new HashMap();
Hashtable elements = multipartHandler.getAllElements();
Enumeration e = elements.keys();
while (e.hasMoreElements()) {
String key = (String) e.nextElement();
parameters.put(key, elements.get(key));
}
if (request instanceof MultipartRequestWrapper) {
request = ((MultipartRequestWrapper) request).getRequest();
e = request.getParameterNames();
while (e.hasMoreElements()) {
String key = (String) e.nextElement();
parameters.put(key, request.getParameterValues(key));
}
} else {
log.debug("Gathering multipart parameters for unwrapped request");
}
return parameters;
}
That is it.
<SNIP>
> >I cannot think of one reason why the default solution has to be
> >hardwired into the framework. Maybe Martin has some reason that I
> >don't know about.
>
> If nothing else, for compatibility. There are lots of Struts
> applications built around things being as they are; we can't just rip
> it out without those applications breaking, and we are committed to
> maintaining backwards compatibility or making clear, deliberate
> deprecations with adequate time to adjust.
</SNIP>
Yes, of course. We are in complete agreement on this. The wiring is
fairly simple and this should not be a difficulty. As I said, the big
thing is what happens in RequestUtils' populate method for ActionForm.
If what I am saying here is of any interest, then I will suggest what
could be doen with the code in RequestUtils and ActionForm to allow
alternative implementations uploads in Stuts.
<SNIP>
> Forgive me if I don't have it at hand from some previous message;
> where is Struts preventing you from changing to use some other file
> upload strategy if you want to? Say you wanted to use Jason Hunter's
> Multipart Filter... you could install that in your webapp and extend
> the RequestProcessor to make processMultipart(...) a no-op. Then in
> your action you cast the request to his MultipartRequestWrapper and
> use its methods to deal with the file. If there's something I'm
> missing because I've never actually tried to do this, please speak up
> -- if we've biffed an extension point, I'd like to know.
</SNIP>
I use the same commons based multipart classes that Martin does with
Struts upload, but just do it a lot differently. I have used Hunter's
as well. And, I have tried various combinations that I have created
on my own. I like commons a lot.
Indeed, as I think I said, I have used Martin's upload app too. I am
trying to help, not to complain.
I have no difficulty for my own reasons to jump in and make
adjustments to the Struts code to fit my custom purposes in my
applications. This is fairly easy for multiparts.
And, if I don't want to use ActionForm, then there is no problem and
no need for any adjustments at all. This is what I presently do.
My sole reason for this discussion is to try and help to make Struts
better. I think I have something to contribute in the area, but the
present hard wiring of the default implementation is making this hard
to do. I am merely trying to suggest some refactoring that might be
worth doing.
'Hope this is helpful.
Jack
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
