[jira] [Comment Edited] (FILEUPLOAD-309) Release version 2.0.0
[
https://issues.apache.org/jira/browse/FILEUPLOAD-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17652022#comment-17652022
]
Andy Seaborne edited comment on FILEUPLOAD-309 at 1/20/23 9:52 AM:
---
I tried the servlet 3.1 multipart support. (PS it's now in the Jena codebase.)
Our (Jena) usage is
* a servlet filter
* deployed in any servlet container - normally bundled with Jetty; some users
deploy a WAR file version in Tomcat et al.
* `multipart/form-data` is just one possible content-type at the URL endpoint.
* streaming (errors are handled by being inside a database transaction)
Each servlet container needs custom configuration.
{{@MultipartConfig}} only applies to servlets, not servlet filters.
[https://github.com/jakartaee/servlet/issues/87]
Jetty: the code can set request attribute {{__MULTIPART_CONFIG_ELEMENT}} during
request processing.
Tomcat needs a setting of a context XML attribute
{{allowCasualMultipartParsing}}. e.g. set it in {{META-INF/context.xml}}. That
does at least avoid users needing to specially change the configuration of
their server.
was (Author: andy.seaborne):
I tried the servlet 3.1 multipart support. (PS it's now in Jena codebase)
Our (Jena) usage is
* a servlet filter
* deployed in any servlet container - normally bundled with Jetty; some users
deploy a WAR file version in Tomcat et al.
* `multipart/form-data` is just one possible content-type at the URL endpoint.
* streaming (errors are handled by being inside a database transaction)
Each servlet container needs custom configuration.
{{@MultipartConfig}} only applies to servlets, not servlet filters.
[https://github.com/jakartaee/servlet/issues/87]
Jetty: the code can set request attribute {{__MULTIPART_CONFIG_ELEMENT}} during
request processing.
Tomcat needs a setting of a context XML attribute
{{allowCasualMultipartParsing}}. e.g. set it in {{META-INF/context.xml}}. That
does at least avoid users needing to specially change the configuration of
their server.
> Release version 2.0.0
> -
>
> Key: FILEUPLOAD-309
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-309
> Project: Commons FileUpload
> Issue Type: Wish
>Reporter: Thiago Henrique Hupner
>Priority: Major
>
> At Piranha, we've migrated to use the new Jakarta namespace.
> One of our dependencies is the Commons File Upload, but the latest version
> available is 1.4.
> Looking around at the source code, I've found that the code is already
> prepared for the new Jakarta namespace.
> So, I want to know if there's a plan to release a new version soon. Or at
> least a 2.0.0 milestone.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (FILEUPLOAD-309) Release version 2.0.0
[
https://issues.apache.org/jira/browse/FILEUPLOAD-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17652022#comment-17652022
]
Andy Seaborne edited comment on FILEUPLOAD-309 at 1/20/23 9:52 AM:
---
I tried the servlet 3.1 multipart support. (PS it's now in Jena codebase)
Our (Jena) usage is
* a servlet filter
* deployed in any servlet container - normally bundled with Jetty; some users
deploy a WAR file version in Tomcat et al.
* `multipart/form-data` is just one possible content-type at the URL endpoint.
* streaming (errors are handled by being inside a database transaction)
Each servlet container needs custom configuration.
{{@MultipartConfig}} only applies to servlets, not servlet filters.
[https://github.com/jakartaee/servlet/issues/87]
Jetty: the code can set request attribute {{__MULTIPART_CONFIG_ELEMENT}} during
request processing.
Tomcat needs a setting of a context XML attribute
{{allowCasualMultipartParsing}}. e.g. set it in {{META-INF/context.xml}}. That
does at least avoid users needing to specially change the configuration of
their server.
was (Author: andy.seaborne):
I tried the servlet 3.1 multipart support.
Our (Jena) usage is
* a servlet filter
* deployed in any servlet container - normally bundled with Jetty; some users
deploy a WAR file version in Tomcat et al.
* `multipart/form-data` is just one possible content-type at the URL endpoint.
* streaming (errors are handled by being inside a database transaction)
Each servlet container needs custom configuration.
`
{{@MultipartConfig}} only applies to servlets, not servlet filters.
[https://github.com/jakartaee/servlet/issues/87]
Jetty: the code can set request attribute {{__MULTIPART_CONFIG_ELEMENT}} during
request processing.
Tomcat needs a setting of a context XML attribute
{{allowCasualMultipartParsing}}. e.g. set it in {{META-INF/context.xml}}. That
does at least avoid users needing to specially change the configuration of
their server.
> Release version 2.0.0
> -
>
> Key: FILEUPLOAD-309
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-309
> Project: Commons FileUpload
> Issue Type: Wish
>Reporter: Thiago Henrique Hupner
>Priority: Major
>
> At Piranha, we've migrated to use the new Jakarta namespace.
> One of our dependencies is the Commons File Upload, but the latest version
> available is 1.4.
> Looking around at the source code, I've found that the code is already
> prepared for the new Jakarta namespace.
> So, I want to know if there's a plan to release a new version soon. Or at
> least a 2.0.0 milestone.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (FILEUPLOAD-309) Release version 2.0.0
[ https://issues.apache.org/jira/browse/FILEUPLOAD-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677499#comment-17677499 ] Steve Lopez edited comment on FILEUPLOAD-309 at 1/16/23 7:40 PM: - Thank you Jochen for the reply. I went ahead and just refactored our code to use Servlet 3.1 spec and remove the need for this. As a an observation it seems like there aren’t standards for how OS projected are handling this Jakarta thing. Another library we use added a jakarta tag to their existing version whereas another just bumped the major version up to 2.0 (which is what I mistakenly thought the Apache commons library did as well) was (Author: steve.rc): Thank you Jochen for the replay. I went ahead and just refactored our code to use Servlet 3.1 spec and remove the need for this. As a an observation it seems like there aren’t standards for how OS projected are handling this Jakarta thing. Another library we use added a jakarta tag to their existing version whereas another just bumped the major version up to 2.0 (which is what I mistakenly thought the Apache commons library did as well) > Release version 2.0.0 > - > > Key: FILEUPLOAD-309 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-309 > Project: Commons FileUpload > Issue Type: Wish >Reporter: Thiago Henrique Hupner >Priority: Major > > At Piranha, we've migrated to use the new Jakarta namespace. > One of our dependencies is the Commons File Upload, but the latest version > available is 1.4. > Looking around at the source code, I've found that the code is already > prepared for the new Jakarta namespace. > So, I want to know if there's a plan to release a new version soon. Or at > least a 2.0.0 milestone. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (FILEUPLOAD-309) Release version 2.0.0
[ https://issues.apache.org/jira/browse/FILEUPLOAD-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677337#comment-17677337 ] Flying Wolf edited comment on FILEUPLOAD-309 at 1/16/23 11:53 AM: -- [~joc...@apache.org] The current big problem with FileUpload, where is issue is about, is this: At 10 September 2019 the "Java Servlet" api was renamed to "Jakarta Servlet", starting from version 4.0.3. At 9 October 2020, with the release of Jakarta Servlet 5.0, the API moved from package `javax.servlet` to `jakarta.servlet`. This package change has big consequences when a project (such as Wicket) wants to update its old Servlet dependency to the new Jakarta Servlet 5.0 API package (jakarta.servlet), but the project (Wicket) also depends on a project (FileUpload) that is still using the old package (javax.servlet). This causes the project (Wicket) to be unable to update to a new Servlet version. If Wicket would stick to the old Java Servlet version that FileUpload automatically and unknowingly is enforcing to projects since 9 October 2020, then this also causes other dependency problems for Wicket. For example, Spring Framework 6 also moved from Java Servlet to Jakarta Servlet. Because FileUpload is enforcing other projects to stay with the old Java Servlet spec, other projects (such as Wicket) won't be able to update to Spring Framework 6. This will become an ever bigger issue when Spring Framework 5 gets end-of-life in 2024. Then projects are forced to use outdated insecure Spring version, or they have to fully drop the usage of FileUpload. So FileUpload is enforcing projects to use an old Servlet spec, which causes major problems for these projects to be able to update important dependencies (Jakarta Servlet and Spring Framework). Whereas the solution in FileUpload to solve this big problem, is really simple: FileUpload only needs to update it dependency (javax.servlet:servlet-api:2.4 provided dependency) to a Jakarta Servlet depedency (for example jakarta.servlet:jakarta.servlet-api:6.0.0). Which means changing some simple import statements from "javax.servlet" to "jakarta.servlet". This simple fix would help projects that depend on FileUpload, a lot. was (Author: flyingwolf): [~joc...@apache.org] The current big problem with FileUpload, where is issue is about, is this: At 10 September 2019 the "Java Servlet" api was renamed to "Jakarta Servlet", starting from version 4.0.3. At 9 October 2020, with the release of Jakarta Servlet 5.0, the API moved from package `javax.servlet` to `jakarta.servlet`. This package change has big consequences when a project (such as Wicket) wants to update its old Servlet dependency to the new Jakarta Servlet 5.0 API package (jakarta.servlet), but the project (Wicket) also depends on a project (FileUpload) that is still using the old package (javax.servlet). This causes the project (Wicket) to be unable to update to a new Servlet version. If Wicket would stick to the old Java Servlet version that FileUpload automatically and unknowingly is enforcing to projects since 10 September 2019, then this also causes other dependency problems for Wicket. For example, Spring Framework 6 also moved from Java Servlet to Jakarta Servlet. Because FileUpload is enforcing other projects to stay with the old Java Servlet spec, other projects (such as Wicket) won't be able to update to Spring Framework 6. This will become an ever bigger issue when Spring Framework 5 gets end-of-life in 2024. Then projects are forced to use outdated insecure Spring version, or they have to fully drop the usage of FileUpload. So FileUpload is enforcing projects to use an old Servlet spec, which causes major problems for these projects to be able to update important dependencies (Jakarta Servlet and Spring Framework). Whereas the solution in FileUpload to solve this big problem, is really simple: FileUpload only needs to update it dependency (javax.servlet:servlet-api:2.4 provided dependency) to a Jakarta Servlet depedency (for example jakarta.servlet:jakarta.servlet-api:6.0.0). Which means changing some simple import statements from "javax.servlet" to "jakarta.servlet". This simple fix would help projects that depend on FileUpload, a lot. > Release version 2.0.0 > - > > Key: FILEUPLOAD-309 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-309 > Project: Commons FileUpload > Issue Type: Wish >Reporter: Thiago Henrique Hupner >Priority: Major > > At Piranha, we've migrated to use the new Jakarta namespace. > One of our dependencies is the Commons File Upload, but the latest version > available is 1.4. > Looking around at the source code, I've found that the code is already > prepared for the new Jakarta namespace. > So, I want to know if there's a plan to release
[jira] [Comment Edited] (FILEUPLOAD-309) Release version 2.0.0
[ https://issues.apache.org/jira/browse/FILEUPLOAD-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677337#comment-17677337 ] Flying Wolf edited comment on FILEUPLOAD-309 at 1/16/23 11:52 AM: -- [~joc...@apache.org] The current big problem with FileUpload, where is issue is about, is this: At 10 September 2019 the "Java Servlet" api was renamed to "Jakarta Servlet", starting from version 4.0.3. At 9 October 2020, with the release of Jakarta Servlet 5.0, the API moved from package `javax.servlet` to `jakarta.servlet`. This package change has big consequences when a project (such as Wicket) wants to update its old Servlet dependency to the new Jakarta Servlet 5.0 API package (jakarta.servlet), but the project (Wicket) also depends on a project (FileUpload) that is still using the old package (javax.servlet). This causes the project (Wicket) to be unable to update to a new Servlet version. If Wicket would stick to the old Java Servlet version that FileUpload automatically and unknowingly is enforcing to projects since 10 September 2019, then this also causes other dependency problems for Wicket. For example, Spring Framework 6 also moved from Java Servlet to Jakarta Servlet. Because FileUpload is enforcing other projects to stay with the old Java Servlet spec, other projects (such as Wicket) won't be able to update to Spring Framework 6. This will become an ever bigger issue when Spring Framework 5 gets end-of-life in 2024. Then projects are forced to use outdated insecure Spring version, or they have to fully drop the usage of FileUpload. So FileUpload is enforcing projects to use an old Servlet spec, which causes major problems for these projects to be able to update important dependencies (Jakarta Servlet and Spring Framework). Whereas the solution in FileUpload to solve this big problem, is really simple: FileUpload only needs to update it dependency (javax.servlet:servlet-api:2.4 provided dependency) to a Jakarta Servlet depedency (for example jakarta.servlet:jakarta.servlet-api:6.0.0). Which means changing some simple import statements from "javax.servlet" to "jakarta.servlet". This simple fix would help projects that depend on FileUpload, a lot. was (Author: flyingwolf): [~joc...@apache.org] The current big problem with FileUpload is this: At 10 September 2019 the "Java Servlet" api was renamed to "Jakarta Servlet", starting from version 4.0.3. At 9 October 2020, with the release of Jakarta Servlet 5.0, the API moved from package `javax.servlet` to `jakarta.servlet`. This package change has big consequences when a project (such as Wicket) wants to update its old Servlet dependency to the new Jakarta Servlet 5.0 API package (jakarta.servlet), but the project (Wicket) also depends on a project (FileUpload) that is still using the old package (javax.servlet). This causes the project (Wicket) to be unable to update to a new Servlet version. If Wicket would stick to the old Java Servlet version that FileUpload automatically and unknowingly is enforcing to projects since 10 September 2019, then this also causes other dependency problems for Wicket. For example, Spring Framework 6 also moved from Java Servlet to Jakarta Servlet. Because FileUpload is enforcing other projects to stay with the old Java Servlet spec, other projects (such as Wicket) won't be able to update to Spring Framework 6. This will become an ever bigger issue when Spring Framework 5 gets end-of-life in 2024. Then projects are forced to use outdated insecure Spring version, or they have to fully drop the usage of FileUpload. So FileUpload is enforcing projects to use an old Servlet spec, which causes major problems for these projects to be able to update important dependencies (Jakarta Servlet and Spring Framework). Whereas the solution in FileUpload to solve this big problem, is really simple: FileUpload only needs to update it dependency (javax.servlet:servlet-api:2.4 provided dependency) to a Jakarta Servlet depedency (for example jakarta.servlet:jakarta.servlet-api:6.0.0). Which means changing some simple import statements from "javax.servlet" to "jakarta.servlet". This simple fix would help projects that depend on FileUpload, a lot. > Release version 2.0.0 > - > > Key: FILEUPLOAD-309 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-309 > Project: Commons FileUpload > Issue Type: Wish >Reporter: Thiago Henrique Hupner >Priority: Major > > At Piranha, we've migrated to use the new Jakarta namespace. > One of our dependencies is the Commons File Upload, but the latest version > available is 1.4. > Looking around at the source code, I've found that the code is already > prepared for the new Jakarta namespace. > So, I want to know if there's a plan to release a new version soon. Or
[jira] [Comment Edited] (FILEUPLOAD-309) Release version 2.0.0
[
https://issues.apache.org/jira/browse/FILEUPLOAD-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17652022#comment-17652022
]
Andy Seaborne edited comment on FILEUPLOAD-309 at 1/1/23 10:09 PM:
---
I tried the servlet 3.1 multipart support.
Our (Jena) usage is
* a servlet filter
* deployed in any servlet container - normally bundled with Jetty; some users
deploy a WAR file version in Tomcat et al.
* `multipart/form-data` is just one possible content-type at the URL endpoint.
* streaming (errors are handled by being inside a database transaction)
Each servlet container needs custom configuration.
`
{{@MultipartConfig}} only applies to servlets, not servlet filters.
[https://github.com/jakartaee/servlet/issues/87]
Jetty: the code can set request attribute {{__MULTIPART_CONFIG_ELEMENT}} during
request processing.
Tomcat needs a setting of a context XML attribute
{{allowCasualMultipartParsing}}. e.g. set it in {{META-INF/context.xml}}. That
does at least avoid users needing to specially change the configuration of
their server.
was (Author: andy.seaborne):
I tried the servlet 3.1 multipart support.
Our (Jena) usage is
* a servlet filter
* deployed in any servlet container - normally bundled with Jetty; some users
deploy a WAR file version in Tomcat et al.
* `multipart/form-data` is just one possible content-type at the URL endpoint.
* streaming (errors are handled by being inside a database transaction)
Each servlet container needs custom configuration.
`@MultipartConfig` only applies to servlets, not servlet filters.
https://github.com/jakartaee/servlet/issues/87
Jetty: the code can set request attribute `__MULTIPART_CONFIG_ELEMENT` during
request processing.
Tomcat needs a setting of a context XML attribute
`allowCasualMultipartParsing`. Set in e.g. `META-INF/context.xml`.
> Release version 2.0.0
> -
>
> Key: FILEUPLOAD-309
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-309
> Project: Commons FileUpload
> Issue Type: Wish
>Reporter: Thiago Henrique Hupner
>Priority: Major
>
> At Piranha, we've migrated to use the new Jakarta namespace.
> One of our dependencies is the Commons File Upload, but the latest version
> available is 1.4.
> Looking around at the source code, I've found that the code is already
> prepared for the new Jakarta namespace.
> So, I want to know if there's a plan to release a new version soon. Or at
> least a 2.0.0 milestone.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (FILEUPLOAD-309) Release version 2.0.0
[ https://issues.apache.org/jira/browse/FILEUPLOAD-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616378#comment-17616378 ] Andy Seaborne edited comment on FILEUPLOAD-309 at 11/18/22 7:28 PM: (( This whole jakarta thing is "no gain, and a bit of a pain". )) The [Jakarta 9 release plan|https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee9/JakartaEE9ReleasePlan] says that the idea is for a "no changes except namespaces" release, with an exception if referring to spec not transferring. Would not Fileupload v2.0 with name changes be better, and give the 3.x space for considered changes? A release of 1.4/Jakarta as 2.0 would help smooth this transition as it is significant for many projects. Or is the advice copying the code and changing it locally – which is practical for fileupload. was (Author: andy.seaborne): (( This whole jakarta thing is "no gain, and a bit of a pain". )) The [Jakarta 9 release plan](https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee9/JakartaEE9ReleasePlan) specifically says that the idea is no changes except namespaces with an exception if referring to spec not transferring. Would not Fileupload v3.0 with changes be better, and give the 3.x space for considered changes? A release of 1.4/Jakarta as 2.0 would help smooth this transition as it is significant for many projects. Or advise copying the code and changing it locally which is practical for fileupload. > Release version 2.0.0 > - > > Key: FILEUPLOAD-309 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-309 > Project: Commons FileUpload > Issue Type: Wish >Reporter: Thiago Henrique Hupner >Priority: Major > > At Piranha, we've migrated to use the new Jakarta namespace. > One of our dependencies is the Commons File Upload, but the latest version > available is 1.4. > Looking around at the source code, I've found that the code is already > prepared for the new Jakarta namespace. > So, I want to know if there's a plan to release a new version soon. Or at > least a 2.0.0 milestone. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (FILEUPLOAD-309) Release version 2.0.0
[ https://issues.apache.org/jira/browse/FILEUPLOAD-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524545#comment-17524545 ] Martin Tzvetanov Grigorov edited comment on FILEUPLOAD-309 at 4/19/22 7:08 PM: --- One year after my initial request: Please release a milestone! We (other Apache projects) want to make releases but it is not possible due to the -SNAPSHOT dependency. was (Author: mgrigorov): One year after my initial request: Please release a milestone release! We (other Apache projects) want to make releases but it is not possible due to the -SNAPSHOT dependency. > Release version 2.0.0 > - > > Key: FILEUPLOAD-309 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-309 > Project: Commons FileUpload > Issue Type: Wish >Reporter: Thiago Henrique Hupner >Priority: Major > > At Piranha, we've migrated to use the new Jakarta namespace. > One of our dependencies is the Commons File Upload, but the latest version > available is 1.4. > Looking around at the source code, I've found that the code is already > prepared for the new Jakarta namespace. > So, I want to know if there's a plan to release a new version soon. Or at > least a 2.0.0 milestone. -- This message was sent by Atlassian Jira (v8.20.7#820007)
