Re: [commons-fileupload2-jakarta-servlet6] - 2.0.0.M2 -DiskItemFile setPath

[Gary Gregory]

I'm not sure what you're missing, it works here:
https://github.com/apache/commons-fileupload/blob/e1ae2a1f64dfde98879bbd11f539beb3ebb76770/commons-fileupload2-core/src/test/java/org/apache/commons/fileupload2/core/DiskFileItemSerializeTest.java#L101-L104

Gary

On Sat, Jul 6, 2024 at 3:28 PM sendi Tho  wrote:
>
> Thank you for looking. I may be not clear .. here is what I am trying to say.
>
>
>
> 1.) The 2.0.0.M2 is using commons-io 2.16.1, here is the api
>
> https://commons.apache.org/proper//commons-io/apidocs/org/apache/commons/io/build/AbstractStreamBuilder.html
>
> setPath not public
>
> 2.) 
> https://github.com/apache/commons-fileupload/blob/master/commons-fileupload2-core/src/main/java/org/apache/commons/fileupload2/core/DiskFileItemFactory.java#L71
>
>  public static class Builder extends 
> AbstractStreamBuilder { ...}
>
> does not have setPath() so we api consumers don;t have access to this setter.
>
> 3.) The following call from documentation does not work, as setPath is not 
> available.
>
> DiskFileItemFactory factory = 
> DiskFileItemFactory.builder().setPath(path).setBufferSize(DEFAULT_THRESHOLD).get();
>
>
> 
>
> Sent: Saturday, July 06, 2024 at 2:31 PM
> From: "Gary Gregory" 
> To: "Commons Developers List" 
> Subject: Re: [commons-fileupload2-jakarta-servlet6] - 2.0.0.M2 -DiskItemFile 
> setPath
> Those two methods are public. What am I missing?
>
> Gary
>
> On Sat, Jul 6, 2024, 11:09 AM sendi Tho  wrote:
>
> > the exact issue I think is
> >
> > DiskFileItemFactory.Builder does not expose the property setPath and
> > setBufferSize.
> >
> >
> > in this file line# 82, #83
> >
> > commons-fileupload/commons-fileupload2-core/src/main/java/org/apache/commons/fileupload2/core/DiskFileItemFactory.java
> >
> >
> > TIA.
> >
> >
> >
> >
> >
> > Sent: Friday, July 05, 2024 at 11:31 PM
> > From: "sendi Tho" 
> > To: dev@commons.apache.org
> > Cc: "Commons Developers List" 
> > Subject: Re: [commons-fileupload2-jakarta-servlet6] - 2.0.0.M2
> > -DiskItemFile setPath
> > hi, thank you for reviewing this. I am just trying to set the path for
> > temporaty file location for upload
> >
> >
> > String path = new File(System.getProperty("java.io.tmpdir")).getPath();
> >
> > DiskFileItemFactory factory = DiskFileItemFactory.builder().get();
> > // sets temporary location to store files
> > factory.setPath(path); // does not have setter for path
> > factory.setRepository();// does not have setter for repo, it does have the
> > getter though
> >
> >
> > or I tried to see if Jakarta has setter available
> >
> > JakartaServletDiskFileUpload upload = new
> > JakartaServletDiskFileUpload(factory);
> > upload.setSizeMax(MEMORY_THRESHOLD);
> > upload.setSizeMax(MEMORY_THRESHOLD);
> > upload.setPath(path);// not there eiter
> >
> >
> >
> >
> > Sent: Friday, July 05, 2024 at 9:04 PM
> > From: "Gary Gregory" 
> > To: "Commons Developers List" 
> > Subject: Re: [commons-fileupload2-jakarta-servlet6] - 2.0.0.M2
> > -DiskItemFile setPath
> > Hello,
> >
> > Could you point out precisely in code what you are wanting to do with
> > DiskFileFactory?
> >
> > Gary
> >
> > On Fri, Jul 5, 2024 at 8:18 AM sendi Tho 
> > wrote:
> > >
> > > Greetings guys,
> > >
> > >
> > > I am trying to use the new "commons-fileupload2-jakarta-servlet6"
> > > 
> > > org.apache.commons
> > > commons-fileupload2-jakarta-servlet6
> > > 2.0.0-M2
> > > 
> > >
> > >
> > > looks like the M2 jar from maven and the code differs ( getting warning
> > like bycode and source code does not match).
> > >
> > > so currently this build does not allow DiskFileFactory api users to set
> > the repository path.. is this intentional ? how to set the path?
> > >
> > > the path seems to come from FileItemFactory, but as FileItemFactory is
> > abstract and DiskItemFactory delegates through its builder the path setter
> > is lost.
> > >
> > > also I could not find the 1.x prod build ( assuming we are on 2.x
> > version) of upload2 servlet6. the 2.x using the builder and change in api..
> > I just wanted to change the package name to jakarta and be done with this..
> > :)
> > >

Re: [commons-fileupload2-jakarta-servlet6] - 2.0.0.M2 -DiskItemFile setPath

[sendi Tho]

Thank you for looking. I may be not clear .. here is what I am trying to say.



1.) The 2.0.0.M2 is using commons-io 2.16.1, here is the api

https://commons.apache.org/proper//commons-io/apidocs/org/apache/commons/io/build/AbstractStreamBuilder.html

setPath not public

2.) 
https://github.com/apache/commons-fileupload/blob/master/commons-fileupload2-core/src/main/java/org/apache/commons/fileupload2/core/DiskFileItemFactory.java#L71
 

 public static class Builder extends AbstractStreamBuilder { ...}

does not have setPath() so we api consumers don;t have access to this setter.
 
3.) The following call from documentation does not work, as setPath is not 
available.

DiskFileItemFactory factory = 
DiskFileItemFactory.builder().setPath(path).setBufferSize(DEFAULT_THRESHOLD).get();
 



Sent: Saturday, July 06, 2024 at 2:31 PM
From: "Gary Gregory" 
To: "Commons Developers List" 
Subject: Re: [commons-fileupload2-jakarta-servlet6] - 2.0.0.M2 -DiskItemFile 
setPath
Those two methods are public. What am I missing?

Gary

On Sat, Jul 6, 2024, 11:09 AM sendi Tho  wrote:

> the exact issue I think is
>
> DiskFileItemFactory.Builder does not expose the property setPath and
> setBufferSize.
>
>
> in this file line# 82, #83
>
> commons-fileupload/commons-fileupload2-core/src/main/java/org/apache/commons/fileupload2/core/DiskFileItemFactory.java
>
>
> TIA.
>
>
>
>
>
> Sent: Friday, July 05, 2024 at 11:31 PM
> From: "sendi Tho" 
> To: dev@commons.apache.org
> Cc: "Commons Developers List" 
> Subject: Re: [commons-fileupload2-jakarta-servlet6] - 2.0.0.M2
> -DiskItemFile setPath
> hi, thank you for reviewing this. I am just trying to set the path for
> temporaty file location for upload
>
>
> String path = new File(System.getProperty("java.io.tmpdir")).getPath();
>
> DiskFileItemFactory factory = DiskFileItemFactory.builder().get();
> // sets temporary location to store files
> factory.setPath(path); // does not have setter for path
> factory.setRepository();// does not have setter for repo, it does have the
> getter though
>
>
> or I tried to see if Jakarta has setter available
>
> JakartaServletDiskFileUpload upload = new
> JakartaServletDiskFileUpload(factory);
> upload.setSizeMax(MEMORY_THRESHOLD);
> upload.setSizeMax(MEMORY_THRESHOLD);
> upload.setPath(path);// not there eiter
>
>
>
>
> Sent: Friday, July 05, 2024 at 9:04 PM
> From: "Gary Gregory" 
> To: "Commons Developers List" 
> Subject: Re: [commons-fileupload2-jakarta-servlet6] - 2.0.0.M2
> -DiskItemFile setPath
> Hello,
>
> Could you point out precisely in code what you are wanting to do with
> DiskFileFactory?
>
> Gary
>
> On Fri, Jul 5, 2024 at 8:18 AM sendi Tho 
> wrote:
> >
> > Greetings guys,
> >
> >
> > I am trying to use the new "commons-fileupload2-jakarta-servlet6"
> > 
> > org.apache.commons
> > commons-fileupload2-jakarta-servlet6
> > 2.0.0-M2
> > 
> >
> >
> > looks like the M2 jar from maven and the code differs ( getting warning
> like bycode and source code does not match).
> >
> > so currently this build does not allow DiskFileFactory api users to set
> the repository path.. is this intentional ? how to set the path?
> >
> > the path seems to come from FileItemFactory, but as FileItemFactory is
> abstract and DiskItemFactory delegates through its builder the path setter
> is lost.
> >
> > also I could not find the 1.x prod build ( assuming we are on 2.x
> version) of upload2 servlet6. the 2.x using the builder and change in api..
> I just wanted to change the package name to jakarta and be done with this..
> :)
> >
> > thanks in advance.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [commons-fileupload2-jakarta-servlet6] - 2.0.0.M2 -DiskItemFile setPath

[Gary Gregory]

Those two methods are public. What am I missing?

Gary

On Sat, Jul 6, 2024, 11:09 AM sendi Tho  wrote:

> the exact issue I think is
>
> DiskFileItemFactory.Builder does not expose the property setPath and
> setBufferSize.
>
>
> in this file line# 82, #83
>
> commons-fileupload/commons-fileupload2-core/src/main/java/org/apache/commons/fileupload2/core/DiskFileItemFactory.java
>
>
> TIA.
>
>
>
>
>
> Sent: Friday, July 05, 2024 at 11:31 PM
> From: "sendi Tho" 
> To: dev@commons.apache.org
> Cc: "Commons Developers List" 
> Subject: Re: [commons-fileupload2-jakarta-servlet6] - 2.0.0.M2
> -DiskItemFile setPath
> hi, thank you for reviewing this. I am just trying to set the path for
> temporaty file location for upload
>
>
> String path = new File(System.getProperty("java.io.tmpdir")).getPath();
>
> DiskFileItemFactory factory = DiskFileItemFactory.builder().get();
> // sets temporary location to store files
> factory.setPath(path); // does not have setter for path
> factory.setRepository();// does not have setter for repo, it does have the
> getter though
>
>
> or I tried to see if Jakarta has setter available
>
> JakartaServletDiskFileUpload upload = new
> JakartaServletDiskFileUpload(factory);
> upload.setSizeMax(MEMORY_THRESHOLD);
> upload.setSizeMax(MEMORY_THRESHOLD);
> upload.setPath(path);// not there eiter
>
>
>
>
> Sent: Friday, July 05, 2024 at 9:04 PM
> From: "Gary Gregory" 
> To: "Commons Developers List" 
> Subject: Re: [commons-fileupload2-jakarta-servlet6] - 2.0.0.M2
> -DiskItemFile setPath
> Hello,
>
> Could you point out precisely in code what you are wanting to do with
> DiskFileFactory?
>
> Gary
>
> On Fri, Jul 5, 2024 at 8:18 AM sendi Tho 
> wrote:
> >
> > Greetings guys,
> >
> >
> > I am trying to use the new "commons-fileupload2-jakarta-servlet6"
> > 
> > org.apache.commons
> > commons-fileupload2-jakarta-servlet6
> > 2.0.0-M2
> > 
> >
> >
> > looks like the M2 jar from maven and the code differs ( getting warning
> like bycode and source code does not match).
> >
> > so currently this build does not allow DiskFileFactory api users to set
> the repository path.. is this intentional ? how to set the path?
> >
> > the path seems to come from FileItemFactory, but as FileItemFactory is
> abstract and DiskItemFactory delegates through its builder the path setter
> is lost.
> >
> > also I could not find the 1.x prod build ( assuming we are on 2.x
> version) of upload2 servlet6. the 2.x using the builder and change in api..
> I just wanted to change the package name to jakarta and be done with this..
> :)
> >
> > thanks in advance.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [commons-fileupload2-jakarta-servlet6] - 2.0.0.M2 -DiskItemFile setPath

[sendi Tho]

the exact issue I think is

DiskFileItemFactory.Builder does not expose the property setPath and 
setBufferSize.
 

in this file line# 82, #83
commons-fileupload/commons-fileupload2-core/src/main/java/org/apache/commons/fileupload2/core/DiskFileItemFactory.java
 

TIA.



 

Sent: Friday, July 05, 2024 at 11:31 PM
From: "sendi Tho" 
To: dev@commons.apache.org
Cc: "Commons Developers List" 
Subject: Re: [commons-fileupload2-jakarta-servlet6] - 2.0.0.M2 -DiskItemFile 
setPath
hi, thank you for reviewing this. I am just trying to set the path for 
temporaty file location for upload
 
 
String path = new File(System.getProperty("java.io.tmpdir")).getPath();
 
DiskFileItemFactory factory = DiskFileItemFactory.builder().get();
// sets temporary location to store files
factory.setPath(path); // does not have setter for path
factory.setRepository();// does not have setter for repo, it does have the 
getter though

 
or I tried to see if Jakarta has setter available
 
JakartaServletDiskFileUpload upload = new JakartaServletDiskFileUpload(factory);
upload.setSizeMax(MEMORY_THRESHOLD);
upload.setSizeMax(MEMORY_THRESHOLD);
upload.setPath(path);// not there eiter

 
 

Sent: Friday, July 05, 2024 at 9:04 PM
From: "Gary Gregory" 
To: "Commons Developers List" 
Subject: Re: [commons-fileupload2-jakarta-servlet6] - 2.0.0.M2 -DiskItemFile 
setPath
Hello,

Could you point out precisely in code what you are wanting to do with
DiskFileFactory?

Gary

On Fri, Jul 5, 2024 at 8:18 AM sendi Tho  wrote:
>
> Greetings guys,
>
>
> I am trying to use the new "commons-fileupload2-jakarta-servlet6"
> 
> org.apache.commons
> commons-fileupload2-jakarta-servlet6
> 2.0.0-M2
> 
>
>
> looks like the M2 jar from maven and the code differs ( getting warning like 
> bycode and source code does not match).
>
> so currently this build does not allow DiskFileFactory api users to set the 
> repository path.. is this intentional ? how to set the path?
>
> the path seems to come from FileItemFactory, but as FileItemFactory is 
> abstract and DiskItemFactory delegates through its builder the path setter is 
> lost.
>
> also I could not find the 1.x prod build ( assuming we are on 2.x version) of 
> upload2 servlet6. the 2.x using the builder and change in api.. I just wanted 
> to change the package name to jakarta and be done with this.. :)
>
> thanks in advance.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [commons-fileupload2-jakarta-servlet6] - 2.0.0.M2 -DiskItemFile setPath

[sendi Tho]

hi,  thank you for reviewing this. I am just trying to set the path for 
temporaty file location for upload
 
 
String path = new File(System.getProperty("java.io.tmpdir")).getPath();
 
DiskFileItemFactory factory = DiskFileItemFactory.builder().get();
// sets temporary location to store files
factory.setPath(path);  // does not have setter for path
factory.setRepository();// does not have setter for repo, it does have the 
getter though

 
or I tried to see if Jakarta has setter available
 
JakartaServletDiskFileUpload upload = new JakartaServletDiskFileUpload(factory);
upload.setSizeMax(MEMORY_THRESHOLD);
upload.setSizeMax(MEMORY_THRESHOLD);
upload.setPath(path);// not there eiter

 
 

Sent: Friday, July 05, 2024 at 9:04 PM
From: "Gary Gregory" 
To: "Commons Developers List" 
Subject: Re: [commons-fileupload2-jakarta-servlet6] - 2.0.0.M2 -DiskItemFile 
setPath
Hello,

Could you point out precisely in code what you are wanting to do with
DiskFileFactory?

Gary

On Fri, Jul 5, 2024 at 8:18 AM sendi Tho  wrote:
>
> Greetings guys,
>
>
> I am trying to use the new "commons-fileupload2-jakarta-servlet6"
> 
> org.apache.commons
> commons-fileupload2-jakarta-servlet6
> 2.0.0-M2
> 
>
>
> looks like the M2 jar from maven and the code differs ( getting warning like 
> bycode and source code does not match).
>
> so currently this build does not allow DiskFileFactory api users to set the 
> repository path.. is this intentional ? how to set the path?
>
> the path seems to come from FileItemFactory, but as FileItemFactory is 
> abstract and DiskItemFactory delegates through its builder the path setter is 
> lost.
>
> also I could not find the 1.x prod build ( assuming we are on 2.x version) of 
> upload2 servlet6. the 2.x using the builder and change in api.. I just wanted 
> to change the package name to jakarta and be done with this.. :)
>
> thanks in advance.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [commons-fileupload2-jakarta-servlet6] - 2.0.0.M2 -DiskItemFile setPath

[Gary Gregory]

Hello,

Could you point out precisely in code what you are wanting to do with
DiskFileFactory?

Gary

On Fri, Jul 5, 2024 at 8:18 AM sendi Tho  wrote:
>
> Greetings guys,
>
>
> I am trying to use the new  "commons-fileupload2-jakarta-servlet6"
> 
>org.apache.commons
>commons-fileupload2-jakarta-servlet6
>2.0.0-M2
> 
>
>
> looks like the M2 jar from maven and the code differs ( getting warning like 
> bycode and source code does not match).
>
> so currently this build does not allow DiskFileFactory api users to set the 
> repository path.. is this intentional ? how to set the path?
>
> the path seems to come from FileItemFactory, but as FileItemFactory is 
> abstract and DiskItemFactory delegates through its builder the path setter is 
> lost.
>
> also I could not find the 1.x prod build ( assuming we are on 2.x version) of 
> upload2 servlet6.  the 2.x using the builder and change in api.. I just 
> wanted to change the package name to jakarta and be done with this.. :)
>
> thanks in advance.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[commons-fileupload2-jakarta-servlet6] - 2.0.0.M2 -DiskItemFile setPath

[sendi Tho]

Greetings guys,
 
 
I am trying to use the new  "commons-fileupload2-jakarta-servlet6"

   org.apache.commons
   commons-fileupload2-jakarta-servlet6
   2.0.0-M2


 
looks like the M2 jar from maven and the code differs ( getting warning like 
bycode and source code does not match).
 
so currently this build does not allow DiskFileFactory api users to set the 
repository path.. is this intentional ? how to set the path?
 
the path seems to come from FileItemFactory, but as FileItemFactory is abstract 
and DiskItemFactory delegates through its builder the path setter is lost.
 
also I could not find the 1.x prod build ( assuming we are on 2.x version) of 
upload2 servlet6.  the 2.x using the builder and change in api.. I just wanted 
to change the package name to jakarta and be done with this.. :)
 
thanks in advance.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: commons-fileupload2-jakarta

[Romain Manni-Bucau]

Le lun. 17 juil. 2023 à 08:19, Martin Tzvetanov Grigorov <
mgrigo...@apache.org> a écrit :

>
>
> On 2023/07/15 14:04:54 Emmanuel Bourg wrote:
> > On 12/07/2023 13:27, Martin Tzvetanov Grigorov wrote:
> >
> > > Last time when I tried to replace Commons Fileupload with pure Servlet
> API I faced these issues:
> > >
> > > 1) The Servlet API does not provide hooks to follow the upload progress
> >
> > To display a progress bar on the client side?
>
> Yes!
>

AFAIK it is mainly about the input stream reading  *per item* and not
globally so you get it in any API wrapping InputStream and using Part
metadata.
Yes the wrapper is not built-in but it is common in several libs and quite
trivial to do inline too so not really missing.


>
> >
> > > 2) The Servlet API does not provide a way to cleanup after processing
> the uploaded files, i.e. the commons-fileupload Cleaner
> >
> > Isn't the temp file cleaning automatically handled by the Servlet
> > container? The API user shouldn't have to care about that.
>
> I don't remember the details why this is needed.
> Does the Servlet spec guarantee that or it is up to the container ?
>

It does and even exposes the Part#delete() method to force it force cases
you want to "optimize".


>
> >
> > Emmanuel Bourg
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: commons-fileupload2-jakarta

[Martin Tzvetanov Grigorov]

On 2023/07/15 14:04:54 Emmanuel Bourg wrote:
> On 12/07/2023 13:27, Martin Tzvetanov Grigorov wrote:
> 
> > Last time when I tried to replace Commons Fileupload with pure Servlet API 
> > I faced these issues:
> > 
> > 1) The Servlet API does not provide hooks to follow the upload progress
> 
> To display a progress bar on the client side?

Yes!

> 
> > 2) The Servlet API does not provide a way to cleanup after processing the 
> > uploaded files, i.e. the commons-fileupload Cleaner
> 
> Isn't the temp file cleaning automatically handled by the Servlet 
> container? The API user shouldn't have to care about that.

I don't remember the details why this is needed. 
Does the Servlet spec guarantee that or it is up to the container ?

> 
> Emmanuel Bourg
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: commons-fileupload2-jakarta

[Emmanuel Bourg]

On 11/07/2023 12:57, Eugene Grybinnyk wrote:

We tried to get rid of commons-fileupload in favour of Servlet API for our 
project where we disable multipart and use streaming (not to store files on the 
disk). And it looks like Servlet API doesn’t provide a convenient way of 
streaming the attachments (like commons-fileupload does) so in the end we 
concluded that we need to implement something similar to what we get from 
commons-fileupload OR to wait for version commons-fileupload:2.0.


streaming is a good use case for commons-fileupload, thank you for 
mentioning it.


I think we should highlight the differences between the Servlet API and 
commons-fileupload on the website, and encourage using the standard API 
if neither streaming nor upload progression is required.


Emmanuel Bourg

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: commons-fileupload2-jakarta

[Emmanuel Bourg]

On 12/07/2023 13:27, Martin Tzvetanov Grigorov wrote:


Last time when I tried to replace Commons Fileupload with pure Servlet API I 
faced these issues:

1) The Servlet API does not provide hooks to follow the upload progress


To display a progress bar on the client side?


2) The Servlet API does not provide a way to cleanup after processing the 
uploaded files, i.e. the commons-fileupload Cleaner


Isn't the temp file cleaning automatically handled by the Servlet 
container? The API user shouldn't have to care about that.


Emmanuel Bourg

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: commons-fileupload2-jakarta

[Martin Tzvetanov Grigorov]

Hi,

On 2023/07/09 14:45:21 Emmanuel Bourg wrote:
> Dumb question: what's the benefit of using commons-fileupload in 2023 
> instead of the equivalent file upload feature of the  Servlet API?

Last time when I tried to replace Commons Fileupload with pure Servlet API I 
faced these issues:

1) The Servlet API does not provide hooks to follow the upload progress

2) The Servlet API does not provide a way to cleanup after processing the 
uploaded files, i.e. the commons-fileupload Cleaner

This was 2016 (https://issues.apache.org/jira/browse/WICKET-5192) so things may 
have changed in the meantime! 

Regards,
Martin

> 
> The use case I had in mind was to support file upload in very old 
> Servlet containers still in production (Tomcat 6 or Jetty 7 for example, 
> both EOL), but servers supporting the Jakarta API are recent and have 
> the file upload feature integrated. I'd expect commons-fileupload to go 
> to dormant in the near future rather than adapted for the jakarta namespace.
> 
> What did I miss?
> 
> Emmanuel Bourg
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Re: commons-fileupload2-jakarta

[Gary Gregory]

FYI, I plan on pushing a 2.0.0-M1 this week.

Gary

On Tue, Jul 11, 2023 at 8:48 AM Romain Manni-Bucau
 wrote:
>
> Sounds good to me, so something like v2 will target legacy apps migrating
> to jakarta but there will be no v3 so prefer migrating to servlet API - or
> your env API.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
>
>
> Le mar. 11 juil. 2023 à 14:43, Dennis Kieselhorst  a
> écrit :
>
> > > Not sure I get the why, let me summarize:
> > >
> > > * using [fileupload] in a servlet >= 3 container is conflicting and can
> > > easily mess up things
> > > * servlet provides [fileupload] api
> > > * jetty (since you mentionned it) does not use [fileupload] (
> > >
> > https://github.com/eclipse/jetty.project/blob/jetty-10.0.x/jetty-server/src/main/java/org/eclipse/jetty/server/MultiPartFormInputStream.java#L82
> > )
> > > but only tomcat does
> > >
> >
> > Pretty sure there are more, see linked JIRA tickets. I'm using it here:
> > https://github.com/awslabs/aws-serverless-java-container
> >
> > Let's move ahead with a release and point out in the docs that from a
> > consumer perspective using Servlet API is preferred.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Re: commons-fileupload2-jakarta

[Romain Manni-Bucau]

Sounds good to me, so something like v2 will target legacy apps migrating
to jakarta but there will be no v3 so prefer migrating to servlet API - or
your env API.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mar. 11 juil. 2023 à 14:43, Dennis Kieselhorst  a
écrit :

> > Not sure I get the why, let me summarize:
> >
> > * using [fileupload] in a servlet >= 3 container is conflicting and can
> > easily mess up things
> > * servlet provides [fileupload] api
> > * jetty (since you mentionned it) does not use [fileupload] (
> >
> https://github.com/eclipse/jetty.project/blob/jetty-10.0.x/jetty-server/src/main/java/org/eclipse/jetty/server/MultiPartFormInputStream.java#L82
> )
> > but only tomcat does
> >
>
> Pretty sure there are more, see linked JIRA tickets. I'm using it here:
> https://github.com/awslabs/aws-serverless-java-container
>
> Let's move ahead with a release and point out in the docs that from a
> consumer perspective using Servlet API is preferred.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Re: commons-fileupload2-jakarta

[Dennis Kieselhorst]

> Not sure I get the why, let me summarize:
> 
> * using [fileupload] in a servlet >= 3 container is conflicting and can
> easily mess up things
> * servlet provides [fileupload] api
> * jetty (since you mentionned it) does not use [fileupload] (
> https://github.com/eclipse/jetty.project/blob/jetty-10.0.x/jetty-server/src/main/java/org/eclipse/jetty/server/MultiPartFormInputStream.java#L82)
> but only tomcat does
> 

Pretty sure there are more, see linked JIRA tickets. I'm using it here: 
https://github.com/awslabs/aws-serverless-java-container 

Let's move ahead with a release and point out in the docs that from a consumer 
perspective using Servlet API is preferred.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Re: commons-fileupload2-jakarta

[Romain Manni-Bucau]

Le mar. 11 juil. 2023 à 14:13, Maxim Solodovnik  a
écrit :

> from mobile (sorry for typos ;)
>
>
> On Tue, Jul 11, 2023, 18:58 Romain Manni-Bucau 
> wrote:
>
> > @Maxim: exactly, this is why hosting it only in tomcat and using the
> > servlet abstraction is saner since commons is not usable in tomcat
> without
> > relocation or hacks nobdoy wants on any sides and it is the main relevant
> > consumer these days.
> >
>
> Will the same API be available in Jetty for ex.?
>

Theorically it can but in practise no because jetty adds "stages" in its
processing so it does not want to be that lazy otherwise it enables garbage
- their impl choice I guess.


>
> IMO code need to stay in Commons
>

Not sure I get the why, let me summarize:

* using [fileupload] in a servlet >= 3 container is conflicting and can
easily mess up things
* servlet provides [fileupload] api
* jetty (since you mentionned it) does not use [fileupload] (
https://github.com/eclipse/jetty.project/blob/jetty-10.0.x/jetty-server/src/main/java/org/eclipse/jetty/server/MultiPartFormInputStream.java#L82)
but only tomcat does

So overall it would be way more beneficial for end users to push the
(unique?) missing feature in the servlet API and be it rather than keep a
lib which is no more a common thing and is superseeded by a standard API -
from my window.


>
>
>
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le mar. 11 juil. 2023 à 13:47, Maxim Solodovnik  a
> > écrit :
> >
> > > Tomcat uses the code copy\pasted from commons-fileupload (due to there
> > > was not release)
> > > IMO it is better to use library instead of copy/pasting here and there
> > > .
> > >
> > > On Tue, 11 Jul 2023 at 18:03, Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > > wrote:
> > > >
> > > > This is a good point but guess it is not hard - and would be great -
> to
> > > fix
> > > > it in tomcat, just needs to not use ArrayList but a lazy list which
> > will
> > > > behave like fileupload streaming API. Under the hood the API already
> > uses
> > > > the FileItemIterator , it just needs to be able to populate the list
> > > lazily.
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau  |  Blog
> > > >  | Old Blog
> > > >  | Github <
> > > https://github.com/rmannibucau> |
> > > > LinkedIn  | Book
> > > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > > >
> > > >
> > > > Le mar. 11 juil. 2023 à 12:57, Eugene Grybinnyk
> > > >  a écrit :
> > > >
> > > > > We tried to get rid of commons-fileupload in favour of Servlet API
> > for
> > > our
> > > > > project where we disable multipart and use streaming (not to store
> > > files on
> > > > > the disk). And it looks like Servlet API doesn’t provide a
> convenient
> > > way
> > > > > of streaming the attachments (like commons-fileupload does) so in
> the
> > > end
> > > > > we concluded that we need to implement something similar to what we
> > get
> > > > > from commons-fileupload OR to wait for version
> > commons-fileupload:2.0.
> > > > >
> > > > > On 2023/07/09 14:45:21 Emmanuel Bourg wrote:
> > > > > > Dumb question: what's the benefit of using commons-fileupload in
> > 2023
> > > > > > instead of the equivalent file upload feature of the  Servlet
> API?
> > > > > >
> > > > > > The use case I had in mind was to support file upload in very old
> > > > > > Servlet containers still in production (Tomcat 6 or Jetty 7 for
> > > example,
> > > > > > both EOL), but servers supporting the Jakarta API are recent and
> > have
> > > > > > the file upload feature integrated. I'd expect commons-fileupload
> > to
> > > go
> > > > > > to dormant in the near future rather than adapted for the jakarta
> > > > > namespace.
> > > > > >
> > > > > > What did I miss?
> > > > > >
> > > > > > Emmanuel Bourg
> > > > > >
> > > > > >
> > -
> > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > > > >
> > > > > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > > Maxim
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
> >
>

Re: Re: commons-fileupload2-jakarta

[Maxim Solodovnik]

from mobile (sorry for typos ;)


On Tue, Jul 11, 2023, 18:58 Romain Manni-Bucau 
wrote:

> @Maxim: exactly, this is why hosting it only in tomcat and using the
> servlet abstraction is saner since commons is not usable in tomcat without
> relocation or hacks nobdoy wants on any sides and it is the main relevant
> consumer these days.
>

Will the same API be available in Jetty for ex.?

IMO code need to stay in Commons



> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mar. 11 juil. 2023 à 13:47, Maxim Solodovnik  a
> écrit :
>
> > Tomcat uses the code copy\pasted from commons-fileupload (due to there
> > was not release)
> > IMO it is better to use library instead of copy/pasting here and there
> > .
> >
> > On Tue, 11 Jul 2023 at 18:03, Romain Manni-Bucau 
> > wrote:
> > >
> > > This is a good point but guess it is not hard - and would be great - to
> > fix
> > > it in tomcat, just needs to not use ArrayList but a lazy list which
> will
> > > behave like fileupload streaming API. Under the hood the API already
> uses
> > > the FileItemIterator , it just needs to be able to populate the list
> > lazily.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github <
> > https://github.com/rmannibucau> |
> > > LinkedIn  | Book
> > > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> > >
> > >
> > > Le mar. 11 juil. 2023 à 12:57, Eugene Grybinnyk
> > >  a écrit :
> > >
> > > > We tried to get rid of commons-fileupload in favour of Servlet API
> for
> > our
> > > > project where we disable multipart and use streaming (not to store
> > files on
> > > > the disk). And it looks like Servlet API doesn’t provide a convenient
> > way
> > > > of streaming the attachments (like commons-fileupload does) so in the
> > end
> > > > we concluded that we need to implement something similar to what we
> get
> > > > from commons-fileupload OR to wait for version
> commons-fileupload:2.0.
> > > >
> > > > On 2023/07/09 14:45:21 Emmanuel Bourg wrote:
> > > > > Dumb question: what's the benefit of using commons-fileupload in
> 2023
> > > > > instead of the equivalent file upload feature of the  Servlet API?
> > > > >
> > > > > The use case I had in mind was to support file upload in very old
> > > > > Servlet containers still in production (Tomcat 6 or Jetty 7 for
> > example,
> > > > > both EOL), but servers supporting the Jakarta API are recent and
> have
> > > > > the file upload feature integrated. I'd expect commons-fileupload
> to
> > go
> > > > > to dormant in the near future rather than adapted for the jakarta
> > > > namespace.
> > > > >
> > > > > What did I miss?
> > > > >
> > > > > Emmanuel Bourg
> > > > >
> > > > >
> -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > > >
> > > > >
> >
> >
> >
> > --
> > Best regards,
> > Maxim
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>

Re: commons-fileupload2-jakarta

[Romain Manni-Bucau]

Le mar. 11 juil. 2023 à 14:09, Eugene Grybinnyk
 a écrit :

> AFAIK it is NOT possible to have a lazy list populated on demand, because
> we cannot know the number of attachments in the HTTP body till we parse the
> body. The iterator (FileItemIterator) is the only working approach - you
> ask for the next attachment and you parse input stream further till you
> face one.
>

I agree we should report to the servlet EG to add a method returning an
Iterator or Stream to solve that but it is also as possible to have a lazy
list, the impl would be full streaming using list.iterator but as soon as
you call another list method (get(i), size(), ...) you materialize it and
break the streaming, this is fine and works well - it is used in several
languages and frameworks.


>
> > On 11 Jul 2023, at 13:02, Romain Manni-Bucau 
> wrote:
> >
> > This is a good point but guess it is not hard - and would be great - to
> fix
> > it in tomcat, just needs to not use ArrayList but a lazy list which will
> > behave like fileupload streaming API. Under the hood the API already uses
> > the FileItemIterator , it just needs to be able to populate the list
> lazily.
> >
> > Romain Manni-Bucau
> > @rmannibucau <
> https://www.google.com/url?q=https://twitter.com/rmannibucau=gmail-imap=168967820300=AOvVaw3qqT1RRsU7FfGEjH71MpYD>
> |  Blog
> > <
> https://www.google.com/url?q=https://rmannibucau.metawerx.net/=gmail-imap=168967820300=AOvVaw2mrk6QnasITfnU8GRENCTc>
> | Old Blog
> > <
> https://www.google.com/url?q=http://rmannibucau.wordpress.com=gmail-imap=168967820300=AOvVaw2Ngwvevye-Ks7lkKfus6-S>
> | Github <
> https://www.google.com/url?q=https://github.com/rmannibucau=gmail-imap=168967820300=AOvVaw0v9iQacoZYhsaDAtt9YYzt>
> |
> > LinkedIn <
> https://www.google.com/url?q=https://www.linkedin.com/in/rmannibucau=gmail-imap=168967820300=AOvVaw2xTNsW2b2LNDCRolnR98VV>
> | Book
> > <
> https://www.google.com/url?q=https://www.packtpub.com/application-development/java-ee-8-high-performance=gmail-imap=168967820300=AOvVaw3zcwUb9o-Bj6YM_TFj0eeo
> >
> >
> >
> > Le mar. 11 juil. 2023 à 12:57, Eugene Grybinnyk
> >  a écrit :
> >
> >> We tried to get rid of commons-fileupload in favour of Servlet API for
> our
> >> project where we disable multipart and use streaming (not to store
> files on
> >> the disk). And it looks like Servlet API doesn’t provide a convenient
> way
> >> of streaming the attachments (like commons-fileupload does) so in the
> end
> >> we concluded that we need to implement something similar to what we get
> >> from commons-fileupload OR to wait for version commons-fileupload:2.0.
> >>
> >> On 2023/07/09 14:45:21 Emmanuel Bourg wrote:
> >>> Dumb question: what's the benefit of using commons-fileupload in 2023
> >>> instead of the equivalent file upload feature of the  Servlet API?
> >>>
> >>> The use case I had in mind was to support file upload in very old
> >>> Servlet containers still in production (Tomcat 6 or Jetty 7 for
> example,
> >>> both EOL), but servers supporting the Jakarta API are recent and have
> >>> the file upload feature integrated. I'd expect commons-fileupload to go
> >>> to dormant in the near future rather than adapted for the jakarta
> >> namespace.
> >>>
> >>> What did I miss?
> >>>
> >>> Emmanuel Bourg
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >>> For additional commands, e-mail: dev-h...@commons.apache.org
> >>>
> >>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: commons-fileupload2-jakarta

[Eugene Grybinnyk]

AFAIK it is NOT possible to have a lazy list populated on demand, because we 
cannot know the number of attachments in the HTTP body till we parse the body. 
The iterator (FileItemIterator) is the only working approach - you ask for the 
next attachment and you parse input stream further till you face one.

> On 11 Jul 2023, at 13:02, Romain Manni-Bucau  wrote:
> 
> This is a good point but guess it is not hard - and would be great - to fix
> it in tomcat, just needs to not use ArrayList but a lazy list which will
> behave like fileupload streaming API. Under the hood the API already uses
> the FileItemIterator , it just needs to be able to populate the list lazily.
> 
> Romain Manni-Bucau
> @rmannibucau 
> 
>  |  Blog
> 
>  | Old Blog
> 
>  | Github 
> 
>  |
> LinkedIn 
> 
>  | Book
> 
> 
> 
> Le mar. 11 juil. 2023 à 12:57, Eugene Grybinnyk
>  a écrit :
> 
>> We tried to get rid of commons-fileupload in favour of Servlet API for our
>> project where we disable multipart and use streaming (not to store files on
>> the disk). And it looks like Servlet API doesn’t provide a convenient way
>> of streaming the attachments (like commons-fileupload does) so in the end
>> we concluded that we need to implement something similar to what we get
>> from commons-fileupload OR to wait for version commons-fileupload:2.0.
>> 
>> On 2023/07/09 14:45:21 Emmanuel Bourg wrote:
>>> Dumb question: what's the benefit of using commons-fileupload in 2023
>>> instead of the equivalent file upload feature of the  Servlet API?
>>> 
>>> The use case I had in mind was to support file upload in very old
>>> Servlet containers still in production (Tomcat 6 or Jetty 7 for example,
>>> both EOL), but servers supporting the Jakarta API are recent and have
>>> the file upload feature integrated. I'd expect commons-fileupload to go
>>> to dormant in the near future rather than adapted for the jakarta
>> namespace.
>>> 
>>> What did I miss?
>>> 
>>> Emmanuel Bourg
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>> 
>>> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Re: commons-fileupload2-jakarta

[Romain Manni-Bucau]

@Maxim: exactly, this is why hosting it only in tomcat and using the
servlet abstraction is saner since commons is not usable in tomcat without
relocation or hacks nobdoy wants on any sides and it is the main relevant
consumer these days.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mar. 11 juil. 2023 à 13:47, Maxim Solodovnik  a
écrit :

> Tomcat uses the code copy\pasted from commons-fileupload (due to there
> was not release)
> IMO it is better to use library instead of copy/pasting here and there
> .
>
> On Tue, 11 Jul 2023 at 18:03, Romain Manni-Bucau 
> wrote:
> >
> > This is a good point but guess it is not hard - and would be great - to
> fix
> > it in tomcat, just needs to not use ArrayList but a lazy list which will
> > behave like fileupload streaming API. Under the hood the API already uses
> > the FileItemIterator , it just needs to be able to populate the list
> lazily.
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le mar. 11 juil. 2023 à 12:57, Eugene Grybinnyk
> >  a écrit :
> >
> > > We tried to get rid of commons-fileupload in favour of Servlet API for
> our
> > > project where we disable multipart and use streaming (not to store
> files on
> > > the disk). And it looks like Servlet API doesn’t provide a convenient
> way
> > > of streaming the attachments (like commons-fileupload does) so in the
> end
> > > we concluded that we need to implement something similar to what we get
> > > from commons-fileupload OR to wait for version commons-fileupload:2.0.
> > >
> > > On 2023/07/09 14:45:21 Emmanuel Bourg wrote:
> > > > Dumb question: what's the benefit of using commons-fileupload in 2023
> > > > instead of the equivalent file upload feature of the  Servlet API?
> > > >
> > > > The use case I had in mind was to support file upload in very old
> > > > Servlet containers still in production (Tomcat 6 or Jetty 7 for
> example,
> > > > both EOL), but servers supporting the Jakarta API are recent and have
> > > > the file upload feature integrated. I'd expect commons-fileupload to
> go
> > > > to dormant in the near future rather than adapted for the jakarta
> > > namespace.
> > > >
> > > > What did I miss?
> > > >
> > > > Emmanuel Bourg
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > >
> > > >
>
>
>
> --
> Best regards,
> Maxim
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Re: commons-fileupload2-jakarta

[Maxim Solodovnik]

Tomcat uses the code copy\pasted from commons-fileupload (due to there
was not release)
IMO it is better to use library instead of copy/pasting here and there .

On Tue, 11 Jul 2023 at 18:03, Romain Manni-Bucau  wrote:
>
> This is a good point but guess it is not hard - and would be great - to fix
> it in tomcat, just needs to not use ArrayList but a lazy list which will
> behave like fileupload streaming API. Under the hood the API already uses
> the FileItemIterator , it just needs to be able to populate the list lazily.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
>
>
> Le mar. 11 juil. 2023 à 12:57, Eugene Grybinnyk
>  a écrit :
>
> > We tried to get rid of commons-fileupload in favour of Servlet API for our
> > project where we disable multipart and use streaming (not to store files on
> > the disk). And it looks like Servlet API doesn’t provide a convenient way
> > of streaming the attachments (like commons-fileupload does) so in the end
> > we concluded that we need to implement something similar to what we get
> > from commons-fileupload OR to wait for version commons-fileupload:2.0.
> >
> > On 2023/07/09 14:45:21 Emmanuel Bourg wrote:
> > > Dumb question: what's the benefit of using commons-fileupload in 2023
> > > instead of the equivalent file upload feature of the  Servlet API?
> > >
> > > The use case I had in mind was to support file upload in very old
> > > Servlet containers still in production (Tomcat 6 or Jetty 7 for example,
> > > both EOL), but servers supporting the Jakarta API are recent and have
> > > the file upload feature integrated. I'd expect commons-fileupload to go
> > > to dormant in the near future rather than adapted for the jakarta
> > namespace.
> > >
> > > What did I miss?
> > >
> > > Emmanuel Bourg
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >



-- 
Best regards,
Maxim

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Re: commons-fileupload2-jakarta

[Romain Manni-Bucau]

This is a good point but guess it is not hard - and would be great - to fix
it in tomcat, just needs to not use ArrayList but a lazy list which will
behave like fileupload streaming API. Under the hood the API already uses
the FileItemIterator , it just needs to be able to populate the list lazily.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mar. 11 juil. 2023 à 12:57, Eugene Grybinnyk
 a écrit :

> We tried to get rid of commons-fileupload in favour of Servlet API for our
> project where we disable multipart and use streaming (not to store files on
> the disk). And it looks like Servlet API doesn’t provide a convenient way
> of streaming the attachments (like commons-fileupload does) so in the end
> we concluded that we need to implement something similar to what we get
> from commons-fileupload OR to wait for version commons-fileupload:2.0.
>
> On 2023/07/09 14:45:21 Emmanuel Bourg wrote:
> > Dumb question: what's the benefit of using commons-fileupload in 2023
> > instead of the equivalent file upload feature of the  Servlet API?
> >
> > The use case I had in mind was to support file upload in very old
> > Servlet containers still in production (Tomcat 6 or Jetty 7 for example,
> > both EOL), but servers supporting the Jakarta API are recent and have
> > the file upload feature integrated. I'd expect commons-fileupload to go
> > to dormant in the near future rather than adapted for the jakarta
> namespace.
> >
> > What did I miss?
> >
> > Emmanuel Bourg
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >

RE: Re: commons-fileupload2-jakarta

[Eugene Grybinnyk]

We tried to get rid of commons-fileupload in favour of Servlet API for our 
project where we disable multipart and use streaming (not to store files on the 
disk). And it looks like Servlet API doesn’t provide a convenient way of 
streaming the attachments (like commons-fileupload does) so in the end we 
concluded that we need to implement something similar to what we get from 
commons-fileupload OR to wait for version commons-fileupload:2.0.

On 2023/07/09 14:45:21 Emmanuel Bourg wrote:
> Dumb question: what's the benefit of using commons-fileupload in 2023 
> instead of the equivalent file upload feature of the  Servlet API?
> 
> The use case I had in mind was to support file upload in very old 
> Servlet containers still in production (Tomcat 6 or Jetty 7 for example, 
> both EOL), but servers supporting the Jakarta API are recent and have 
> the file upload feature integrated. I'd expect commons-fileupload to go 
> to dormant in the near future rather than adapted for the jakarta namespace.
> 
> What did I miss?
> 
> Emmanuel Bourg
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 

Re: commons-fileupload2-jakarta

[Romain Manni-Bucau]

Le lun. 10 juil. 2023 à 11:49, Gary Gregory  a
écrit :

> As we all (should) know, there is no way to tell how a much a jar file is
> used, beyond what Maven Central tells us, especially once within a
> company's network that use it's own repository like Artifactory...
>

(not sure I get your point) Do you mean there are so much application
servers which are not known? We are not in general case there and the end
user case was already covered so think it is one of the rare cases we know.


>
> Gary
>
> On Mon, Jul 10, 2023, 02:26 Romain Manni-Bucau 
> wrote:
>
> > @Dennis: good question but how many servers do reuse commons? I know most
> > of them reimplemented it (to own it or cause they dont use servlet or
> want
> > a reactive based API) or reused tomcat forked (payara for ex or other
> > tomcat based servers). So at the end I think the question is not "why"
> > which is a wish but more "does" and from my window fileupload is not a
> > common thing.
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le lun. 10 juil. 2023 à 07:33, Dennis Kieselhorst  a
> > écrit :
> >
> > > Hmm why should every server create it's own impl instead of sharing
> > > capabilities like multipart handling and parsing as a common library?
> > >
> > > I agree with the consumer part but the lib is still useful in the
> future
> > > to handle server side of things
> > >
> > > Dennis
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
> >
>

Re: commons-fileupload2-jakarta

[Gary Gregory]

As we all (should) know, there is no way to tell how a much a jar file is
used, beyond what Maven Central tells us, especially once within a
company's network that use it's own repository like Artifactory...

Gary

On Mon, Jul 10, 2023, 02:26 Romain Manni-Bucau 
wrote:

> @Dennis: good question but how many servers do reuse commons? I know most
> of them reimplemented it (to own it or cause they dont use servlet or want
> a reactive based API) or reused tomcat forked (payara for ex or other
> tomcat based servers). So at the end I think the question is not "why"
> which is a wish but more "does" and from my window fileupload is not a
> common thing.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le lun. 10 juil. 2023 à 07:33, Dennis Kieselhorst  a
> écrit :
>
> > Hmm why should every server create it's own impl instead of sharing
> > capabilities like multipart handling and parsing as a common library?
> >
> > I agree with the consumer part but the lib is still useful in the future
> > to handle server side of things
> >
> > Dennis
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>

Re: commons-fileupload2-jakarta

[Romain Manni-Bucau]

@Dennis: good question but how many servers do reuse commons? I know most
of them reimplemented it (to own it or cause they dont use servlet or want
a reactive based API) or reused tomcat forked (payara for ex or other
tomcat based servers). So at the end I think the question is not "why"
which is a wish but more "does" and from my window fileupload is not a
common thing.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 10 juil. 2023 à 07:33, Dennis Kieselhorst  a
écrit :

> Hmm why should every server create it's own impl instead of sharing
> capabilities like multipart handling and parsing as a common library?
>
> I agree with the consumer part but the lib is still useful in the future
> to handle server side of things
>
> Dennis
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: commons-fileupload2-jakarta

[Dennis Kieselhorst]

Hmm why should every server create it's own impl instead of sharing 
capabilities like multipart handling and parsing as a common library?

I agree with the consumer part but the lib is still useful in the future to 
handle server side of things

Dennis

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: commons-fileupload2-jakarta

[Emmanuel Bourg]

On 09/07/2023 18:01, Gary Gregory wrote:

I think it might be helpful to think about this in terms of existing and
legacy code bases that need to migrate to the Jakarta namespace in a simple
manner, as opposed to green-field development.


Here the sensible migration path is to switch to the Servlet API, not 
creating a new API that puts a maintenance burden on us for the years to 
come.




I plan on cutting a release candidate for 2 .0.0-M1 this weekend or next
Some people have been asking for it as well.


But why are they asking for that? We don't do things just because we are 
asked to. We do things because it makes sense technically, and it 
doesn't look so in this case.


Emmanuel Bourg

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: commons-fileupload2-jakarta

[Romain Manni-Bucau]

@Dennis: the point is more about not encouraging users to consume it,
tomcat has no big issue integrating the project as it is in its own code
base but as an servlet API user, importing it means either to not use
servlet 3 api or to not use fileupload but both together can become a
nightmare when mixed thru libraries so since it is not needed on end users
side now maybe it is time to not do a v2 and let tomcat handle the impl as
part of the tomat project. Guess it was the main point and I think it makes
sense.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le dim. 9 juil. 2023 à 19:53, Dennis Kieselhorst  a écrit :

> It's not redundant as Servlet API is just the API and commons-fileupload
> offers a server-side implementation that even Tomcat could use (forked code
> lives here
> https://github.com/apache/tomcat/tree/main/java/org/apache/tomcat/util/http/fileupload
> ).
>
> See also: https://issues.apache.org/jira/browse/FILEUPLOAD-309
>
> Best,
> Dennis
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: commons-fileupload2-jakarta

[Dennis Kieselhorst]

It's not redundant as Servlet API is just the API and commons-fileupload offers 
a server-side implementation that even Tomcat could use (forked code lives here 
https://github.com/apache/tomcat/tree/main/java/org/apache/tomcat/util/http/fileupload).

See also: https://issues.apache.org/jira/browse/FILEUPLOAD-309 

Best,
Dennis

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: commons-fileupload2-jakarta

[Romain Manni-Bucau]

Whereas I can envision the migration point but means putting an API on top
of Servlet, not doing a v2 which is the v1 in a new namespace with conflict
in the target env so if really a migration thing it should likely be marked
as "to drop asap".
For wicket, for example, I don't see them keeping it very long since it
would be against embracing jakarta (was ok for javax due to old containers,
but for jakarta this does not make sense).

So means a M1 is ok but consumers should probably expect there will never
be a final which would be iso if we do our homeworks (it is summer to time
for holiday notebooks ;)).

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le dim. 9 juil. 2023 à 18:02, Gary Gregory  a
écrit :

> I think it might be helpful to think about this in terms of existing and
> legacy code bases that need to migrate to the Jakarta namespace in a simple
> manner, as opposed to green-field development.
>
> For example, Apache Wicket has a branch using FileUpload 2 snapshot.
>
> I plan on cutting a release candidate for 2 .0.0-M1 this weekend or next
> week. Some people have been asking for it as well.
>
> Gary
>
> On Sun, Jul 9, 2023, 10:45 Emmanuel Bourg  wrote:
>
> > Dumb question: what's the benefit of using commons-fileupload in 2023
> > instead of the equivalent file upload feature of the  Servlet API?
> >
> > The use case I had in mind was to support file upload in very old
> > Servlet containers still in production (Tomcat 6 or Jetty 7 for example,
> > both EOL), but servers supporting the Jakarta API are recent and have
> > the file upload feature integrated. I'd expect commons-fileupload to go
> > to dormant in the near future rather than adapted for the jakarta
> > namespace.
> >
> > What did I miss?
> >
> > Emmanuel Bourg
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>

Re: commons-fileupload2-jakarta

[Gary Gregory]

I think it might be helpful to think about this in terms of existing and
legacy code bases that need to migrate to the Jakarta namespace in a simple
manner, as opposed to green-field development.

For example, Apache Wicket has a branch using FileUpload 2 snapshot.

I plan on cutting a release candidate for 2 .0.0-M1 this weekend or next
week. Some people have been asking for it as well.

Gary

On Sun, Jul 9, 2023, 10:45 Emmanuel Bourg  wrote:

> Dumb question: what's the benefit of using commons-fileupload in 2023
> instead of the equivalent file upload feature of the  Servlet API?
>
> The use case I had in mind was to support file upload in very old
> Servlet containers still in production (Tomcat 6 or Jetty 7 for example,
> both EOL), but servers supporting the Jakarta API are recent and have
> the file upload feature integrated. I'd expect commons-fileupload to go
> to dormant in the near future rather than adapted for the jakarta
> namespace.
>
> What did I miss?
>
> Emmanuel Bourg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: commons-fileupload2-jakarta

[Romain Manni-Bucau]

Le dim. 9 juil. 2023 à 16:45, Emmanuel Bourg  a écrit :

> Dumb question: what's the benefit of using commons-fileupload in 2023
> instead of the equivalent file upload feature of the  Servlet API?
>

+1, sounds redundant and can potentially break servlet API (or file upload
one depending how it is wrapped/integrated).


>
> The use case I had in mind was to support file upload in very old
> Servlet containers still in production (Tomcat 6 or Jetty 7 for example,
> both EOL), but servers supporting the Jakarta API are recent and have
> the file upload feature integrated. I'd expect commons-fileupload to go
> to dormant in the near future rather than adapted for the jakarta
> namespace.
>
> What did I miss?
>
> Emmanuel Bourg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: commons-fileupload2-jakarta

[Emmanuel Bourg]

Dumb question: what's the benefit of using commons-fileupload in 2023 
instead of the equivalent file upload feature of the  Servlet API?


The use case I had in mind was to support file upload in very old 
Servlet containers still in production (Tomcat 6 or Jetty 7 for example, 
both EOL), but servers supporting the Jakarta API are recent and have 
the file upload feature integrated. I'd expect commons-fileupload to go 
to dormant in the near future rather than adapted for the jakarta namespace.


What did I miss?

Emmanuel Bourg

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: commons-fileupload2-jakarta

[Gary Gregory]

I plan on creating a 2.0.0-M1 release candidate this weekend or next week,
so soonish.

Gary

On Fri, Jul 7, 2023, 14:40 Marinko  wrote:

> Hi
>
> Any plan about the release date of the commons-fileupload2-jakarta <
> https://github.com/apache/commons-fileupload/tree/master/commons-fileupload2-jakarta>
> package?
>
> Thanks
> Marinko

commons-fileupload2-jakarta

[Marinko]

Hi

Any plan about the release date of the commons-fileupload2-jakarta 
<https://github.com/apache/commons-fileupload/tree/master/commons-fileupload2-jakarta>
 package?

Thanks
Marinko