Craig McClanahan wrote:
>
> Hmm ... maybe something analogous to the MediaType class (perhaps
> HeaderValue) that gives you an accessor to get to the value itself
> ("form-data" in this case), plus a Map<String,String> giving you access
> to all the parameters (just one in the case shown here, but there could
> be several for general header values)? We'd still want convenient
> string-only ways to *construct* the header value, but it would be nice
> to have something like this on BodyPart:
>
> MultivaluedMap<String,HeaderType> getHeaders() { ... }
>
> instead of the current return value of "MultivaluedMap<String,String>".
> Then you could call:
>
> HeaderType header =
> bodyPart.getHeaders().getFirst("Content-Disposition");
> System.out.println("Disposition value is " + header.getValue()); //
> "form-data"
> System.out.println("Name is " + header.getParameters().get("name"));
> // "files"
>
> What do you think?
>
That sounds exactly like the kind of thing I was looking for.
BTW, I just discovered this related discussion:
http://forums.sun.com/thread.jspa?threadID=5333195
This, in turn, led me to javax.mail.internet.ContentDisposition and more
importantly javax.mail.internet.HeaderTokenizer. We should be able to use
these fairly easily to implement the aforementioned APIs.
Craig McClanahan wrote:
>
> Dealing with the configuration seems solvable fairly easily, although
> the interesting bit is to find a solution that works for both a servlet
> deployment (where there could be multiple independent apps deployed in
> the same server, so system properties don't work well) and a non-servlet
> deployment (where we don't have any access to servlet APIs.
>
Why do you need to support non-servlet deployments?
Craig McClanahan wrote:
>
> Probably the best bet is an optional properties file loaded via the thread
> context class loader (if any; otherwise the class loader that loaded the
> jersey-multipart classes) that can be used to set configuration stuff
> like this.
>
As soon as we start talking about class loaders things get ugly real quick.
Ideally I'd like to cheat by simplifing the requirements if possible ;)
Craig McClanahan wrote:
>
> Regarding the need for the cleanup call, I'm open to suggestion for how
> to improve this. I've started looking at Jersey filters (which would
> impose a Jersey-specific implementation dependency), but haven't settled
> on anything yet.
>
FileUpload has a background thread that monitors when its File instances get
garbage-collected (Guice does something similar) and when this happens it
goes and deletes the files off the hard-drive automatically. It also uses a
Servlet Filter to hook servlet shutdown to force immediate deletion of all
outstanding files. At least, that's what I understood from their Javadoc.
Craig McClanahan wrote:
>
> Separately, I took your suggestion to look at Commons FileUpload. It
> turns out that there *is* a single important class
> (org.apache.commons.fileupload.MultipartStream) -- plus a couple of
> small helpers -- that performs the only real task I'm currently
> delegating to JavaMail. That's the actual parsing of the multipart/*
> input stream. I need to do some experiments, and take heed of the
> potential concerns in the javadocs about nested multipart/* body parts,
> but it may well be that we could incorporate a variant of just this
> class and not even need the entire Commons FileUpload package (or it's
> dependence on Commons IO).
>
The only reason I suggested looking at FileUpload is I thought it was an
active project that it handles temporary files and configuration under the
hood for us. Now I'm not so sure anymore. If you believe that adding their
configuration on top of Javamail isn't much hassle I think I'd prefer that
than relying on their code. I say this because I noticed that Javamail has
been open-sourced and is now part of Glassfish and I trust those guys a heck
of a lot more than I do your average Apache project.
My main concern now is stability and simplicity. I guess I no longer care
about the underlying JAR size ;)
Gili
--
View this message in context: http://n2.nabble.com/Hello-World%21-and-Welcome-to-jersey-multipart-tp1343189p1453306.html
Sent from the Jersey mailing list archive at Nabble.com.