You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Jochen Wiedmann <jo...@gmail.com> on 2007/08/05 21:38:19 UTC
RfC: commons-fileupload 2, based on mime4j
Hi,
I'd like to ask for feedback on a proposed version of
commons-fileupload. It isn't yet finished, but most of the test cases
are already working.
Changes:
- Based on a slightly patched version of Mime4J. Should be possible to get the
required changes into upstream. The most important part was the rewrite of
Mime4J as a pull parser, which is already in.
Mime4J supports transfer encodings (FILEUPLOAD-131)
- I/O exceptions are no longer trapped, but passed through to the caller.
(FILEUPLOAD-71)
- Package name changed to org.apache.commons.fileupload2
- Streaming API is now clearly isolated. Traditional style API is still present,
but clearly distinguished. The Streaming API is implemented by the
FileUpload class, the traditional API is available through the FileItemStore
- Progress listener enhancements (FILEUPLOAD-142)
A migration guide from 1.x can be found at
http://people.apache.org/~jochen/commons-fileupload/site/migration.html
The complete site, including the updated docs, can be found at
http://people.apache.org/~jochen/commons-fileupload
For the distribution, see
http://people.apache.org/~jochen/commons-fileupload/dist/
I haven't checked the stuff in, as I am waiting for feedback first.
Jochen
--
"Besides, manipulating elections is under penalty of law, resulting in
a preventative effect against manipulating elections.
The german government justifying the use of electronic voting machines
and obviously believing that we don't need a police, because all
illegal actions are forbidden.
http://dip.bundestag.de/btd/16/051/1605194.pdf
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: RfC: commons-fileupload 2, based on mime4j
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2007-08-06 at 12:57 +0200, Jochen Wiedmann wrote:
> On 8/6/07, Oleg Kalnichevski <ol...@apache.org> wrote:
>
> > We are most likely to spin off the support for multipart coded POSTs
> > into a separate module (artifact) as of release 4.0, so dependency on
> > Mime4J will remain optional. I do not think Axis2 presently makes any
> > use of multipart coded POSTs anyways, so Axis2 will not be affected at
> > all.
>
> A question: How's posting (creating requests) related to mime4j
> (parsing requests)?
>
> Jochen
>
Isn't it the opposite side of the same process? No? If the scope of
Mime4j is exclusively about parsing requests, I apologize for bringing
up this idea.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: RfC: commons-fileupload 2, based on mime4j
Posted by Jochen Wiedmann <jo...@gmail.com>.
On 8/6/07, Oleg Kalnichevski <ol...@apache.org> wrote:
> We are most likely to spin off the support for multipart coded POSTs
> into a separate module (artifact) as of release 4.0, so dependency on
> Mime4J will remain optional. I do not think Axis2 presently makes any
> use of multipart coded POSTs anyways, so Axis2 will not be affected at
> all.
A question: How's posting (creating requests) related to mime4j
(parsing requests)?
Jochen
--
"Besides, manipulating elections is under penalty of law, resulting in
a preventative effect against manipulating elections.
The german government justifying the use of electronic voting machines
and obviously believing that we don't need a police, because all
illegal actions are forbidden.
http://dip.bundestag.de/btd/16/051/1605194.pdf
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: RfC: commons-fileupload 2, based on mime4j
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sun, 2007-08-05 at 21:25 -0400, Davanum Srinivas wrote:
> Hmm, if we are doing this (mime4j in httpclient), please let us know
> so that we will look more seriously at getting rid of mailapi jar in
> axis2 and depend on mime4j as well. since we dependent heavily on
> httpclient.
>
> thanks,
> dims
>
Hi Davanum,
We are most likely to spin off the support for multipart coded POSTs
into a separate module (artifact) as of release 4.0, so dependency on
Mime4J will remain optional. I do not think Axis2 presently makes any
use of multipart coded POSTs anyways, so Axis2 will not be affected at
all.
Cheers
Oleg
> On 8/5/07, Oleg Kalnichevski <ol...@apache.org> wrote:
> > Jochen Wiedmann wrote:
> > > Hi,
> > >
> > > I'd like to ask for feedback on a proposed version of
> > > commons-fileupload. It isn't yet finished, but most of the test cases
> > > are already working.
> > >
> > >
> >
> > Hi Jochen
> >
> > It is unlikely I will manage to find time to review the code, but I
> > would like to say that I consider the use of Mime4J to perform the
> > |multipart/form-data| decoding to be a good thing. I should also add I
> > would like to see the old multipart related code in HttpClient replaced
> > by Mime4J and I am willing to contribute the |multipart/form-data
> > |encoding functionality to Mime4J, if it is not available yet.
> >
> > Oleg
> >
> > > Changes:
> > >
> > > - Based on a slightly patched version of Mime4J. Should be possible to get the
> > > required changes into upstream. The most important part was the rewrite of
> > > Mime4J as a pull parser, which is already in.
> > > Mime4J supports transfer encodings (FILEUPLOAD-131)
> > > - I/O exceptions are no longer trapped, but passed through to the caller.
> > > (FILEUPLOAD-71)
> > > - Package name changed to org.apache.commons.fileupload2
> > > - Streaming API is now clearly isolated. Traditional style API is still present,
> > > but clearly distinguished. The Streaming API is implemented by the
> > > FileUpload class, the traditional API is available through the FileItemStore
> > > - Progress listener enhancements (FILEUPLOAD-142)
> > >
> > > A migration guide from 1.x can be found at
> > >
> > > http://people.apache.org/~jochen/commons-fileupload/site/migration.html
> > >
> > > The complete site, including the updated docs, can be found at
> > >
> > > http://people.apache.org/~jochen/commons-fileupload
> > >
> > > For the distribution, see
> > >
> > > http://people.apache.org/~jochen/commons-fileupload/dist/
> > >
> > > I haven't checked the stuff in, as I am waiting for feedback first.
> > >
> > >
> > > Jochen
> > >
> > >
> > >
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: RfC: commons-fileupload 2, based on mime4j
Posted by Davanum Srinivas <da...@gmail.com>.
Hmm, if we are doing this (mime4j in httpclient), please let us know
so that we will look more seriously at getting rid of mailapi jar in
axis2 and depend on mime4j as well. since we dependent heavily on
httpclient.
thanks,
dims
On 8/5/07, Oleg Kalnichevski <ol...@apache.org> wrote:
> Jochen Wiedmann wrote:
> > Hi,
> >
> > I'd like to ask for feedback on a proposed version of
> > commons-fileupload. It isn't yet finished, but most of the test cases
> > are already working.
> >
> >
>
> Hi Jochen
>
> It is unlikely I will manage to find time to review the code, but I
> would like to say that I consider the use of Mime4J to perform the
> |multipart/form-data| decoding to be a good thing. I should also add I
> would like to see the old multipart related code in HttpClient replaced
> by Mime4J and I am willing to contribute the |multipart/form-data
> |encoding functionality to Mime4J, if it is not available yet.
>
> Oleg
>
> > Changes:
> >
> > - Based on a slightly patched version of Mime4J. Should be possible to get the
> > required changes into upstream. The most important part was the rewrite of
> > Mime4J as a pull parser, which is already in.
> > Mime4J supports transfer encodings (FILEUPLOAD-131)
> > - I/O exceptions are no longer trapped, but passed through to the caller.
> > (FILEUPLOAD-71)
> > - Package name changed to org.apache.commons.fileupload2
> > - Streaming API is now clearly isolated. Traditional style API is still present,
> > but clearly distinguished. The Streaming API is implemented by the
> > FileUpload class, the traditional API is available through the FileItemStore
> > - Progress listener enhancements (FILEUPLOAD-142)
> >
> > A migration guide from 1.x can be found at
> >
> > http://people.apache.org/~jochen/commons-fileupload/site/migration.html
> >
> > The complete site, including the updated docs, can be found at
> >
> > http://people.apache.org/~jochen/commons-fileupload
> >
> > For the distribution, see
> >
> > http://people.apache.org/~jochen/commons-fileupload/dist/
> >
> > I haven't checked the stuff in, as I am waiting for feedback first.
> >
> >
> > Jochen
> >
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Davanum Srinivas :: http://davanum.wordpress.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: RfC: commons-fileupload 2, based on mime4j
Posted by Oleg Kalnichevski <ol...@apache.org>.
Jochen Wiedmann wrote:
> Hi,
>
> I'd like to ask for feedback on a proposed version of
> commons-fileupload. It isn't yet finished, but most of the test cases
> are already working.
>
>
Hi Jochen
It is unlikely I will manage to find time to review the code, but I
would like to say that I consider the use of Mime4J to perform the
|multipart/form-data| decoding to be a good thing. I should also add I
would like to see the old multipart related code in HttpClient replaced
by Mime4J and I am willing to contribute the |multipart/form-data
|encoding functionality to Mime4J, if it is not available yet.
Oleg
> Changes:
>
> - Based on a slightly patched version of Mime4J. Should be possible to get the
> required changes into upstream. The most important part was the rewrite of
> Mime4J as a pull parser, which is already in.
> Mime4J supports transfer encodings (FILEUPLOAD-131)
> - I/O exceptions are no longer trapped, but passed through to the caller.
> (FILEUPLOAD-71)
> - Package name changed to org.apache.commons.fileupload2
> - Streaming API is now clearly isolated. Traditional style API is still present,
> but clearly distinguished. The Streaming API is implemented by the
> FileUpload class, the traditional API is available through the FileItemStore
> - Progress listener enhancements (FILEUPLOAD-142)
>
> A migration guide from 1.x can be found at
>
> http://people.apache.org/~jochen/commons-fileupload/site/migration.html
>
> The complete site, including the updated docs, can be found at
>
> http://people.apache.org/~jochen/commons-fileupload
>
> For the distribution, see
>
> http://people.apache.org/~jochen/commons-fileupload/dist/
>
> I haven't checked the stuff in, as I am waiting for feedback first.
>
>
> Jochen
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org