RE: [Springframework-developer] Multipart File Handling

[Trevor C. <pr...@se...>]

Juergen - Glad that you'll look at it.  Based on the previous emails you =
seem to have a pretty good handle on this, and my ideas are fairly close =
to yours.  Are you back from vacation now, or still checking remotely?

As far as the filter goes, that is definately a possiblity to add later =
(possibly even for 1.0) but not something I'll be able to look at right =
away.  However, it could use the same code, so it shouldn't be too =
difficult.

Trevor


-----Original Message-----
From: j=C3=BCrgen h=C3=B6ller [werk3AT] =
[mailto:jue...@we...]
Sent: September 28, 2003 6:33 AM
To: Trevor Cook; Spring Developers
Subject: Re: [Springframework-developer] Multipart File Handling


Hi Trevor,
=20
A MultipartResolver interface with implementations for Commons =
FileUpload and COS is fine with me - it just hadn't high priority since =
I proposed it half a year ago. As I still have a pretty clear picture of =
the issues, I'll be happy to review your code once you've checked it in. =
As this should be pretty straightforward, let's try to include this =
already in 1.0 M2 - at least with a Commons FileUpload implementation.
=20
BTW, in contrast to COS, Commons FileUpload doesn't provide a Servlet =
2.3 filter anyway. This means that there would be some infrastructure =
code to write for that use case too, even when using standard filters. A =
simple but convenient Spring solution would definitely be a good thing.
=20
Juergen
=20
=20
=20

	-----Ursprngliche Nachricht-----=20
	Von: Trevor Cook [mailto:pr...@se...]=20
	Gesendet: Sa 27.09.2003 19:35=20
	An: Spring Developers=20
	Cc:=20
	Betreff: [[W3-SPAM]] - [Springframework-developer] Multipart File =
Handling - Email found in subject
=09
=09

	First some history:
	http://sourceforge.net/mailarchive/message.php?msg_id=3D3891279
	http://sourceforge.net/mailarchive/message.php?msg_id=3D5175276
	=
http://sourceforge.net/mailarchive/forum.php?thread_id=3D3125561&forum_id=
=3D3028
	7
	http://sourceforge.net/mailarchive/message.php?msg_id=3D6062288
=09
	To address a few things Juergen mentioned previously.
=09
	>> a less intrusive way would be to wrap the HttpServletRequest via a =
filter
	I personally don't like the filter approach, at least for the =
framework.  It
	requires additional setup for the user (in the web.xml file) and might =
be
	less understandable since our normal strategy so far has been with =
resolvers
	inside the servlet.
=09
	>>we would need to find concrete requirements for this
	We have numerous uses for file upload handling.  We have a public photo
	contest where users can upload fotos.  We have special access for =
suppliers
	to upload product files (csv) which we then add in to our ordering =
system.
	Finally, we have a web administration interface which allows our client =
to
	upload files to the website so they can be downloaded.  I think that
	including this support (multipart handling) is a no-brainer.
=09
	Basically, I have used COS exclusively in our projects, but I don't =
think
	that's easy for Spring to use (due to the licensing).  I would simply =
code
	this according to Spring norms using an interface and a default version
	using Commons FileUpload.  Later, if somebody wants to create a cos =
version
	we can (but to be honest, if we have a working, integrated solution I'm =
not
	sure that is necessary - at least not in the Spring framework).  =
Basically,
	provide hooks and a default implementation, and allow users to adopt as
	necessary.
=09
	In our project we had modified the AbstractController and put the code =
into
	it to handle the multipart processing, returning a wrapped
	HttpServletRequest through the handlers.  This is very similiar to =
Juergen's
	outline =
(http://sourceforge.net/mailarchive/message.php?msg_id=3D3891279).
=09
	Since we are migrating to the current Spring codebase, I need to move =
our
	multipart handling code.  The main question is whether we keep it
	internally, or place it into Spring.  I propose modifying
	org.springframework.web.servlet.DispatcherServlet to have a
	"MultipartResolver".  In the DispatcherServlet, the resolver would be =
called
	to wrap the request in doService immediately before getHandler(request) =
-
	currently line 351, and then called to do any cleanup immediately =
before
	exiting the doService method.
=09
	I have about 2/3 of the code already written, and I will be writing the =
rest
	between now and Monday.  Does this strategy sound appropriate for =
Spring
	(meaning should I commit it to the Spring codebase) when it's finished?
=09
	Trevor D. Cook
	Interprise Software
=09
=09
=09
	-------------------------------------------------------
	This sf.net email is sponsored by:ThinkGeek
	Welcome to geek heaven.
	http://thinkgeek.com/sf
	_______________________________________________
	Springframework-developer mailing list
	Spr...@li...
	https://lists.sourceforge.net/lists/listinfo/springframework-developer
=09