You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "KONTRA, Gergely" <pi...@gmail.com> on 2013/03/05 16:37:56 UTC
Re: [fileupload] Uploading large files - DONE
Dear all!
I've finished my patch for 2Gb+ uploads.
Since I don't use portlets, it needs some additional fix for portlets (it's
not broken, just returns -1 as the total size of the file, when it's over
2Gb.
Gergo
see
https://github.com/pihentagy/commons-fileupload/commit/16a677dd3c61acde530a5f54a59402faed1a953a
ps: feel free to contact me if you need additional info for the merge.
+-[ Gergely Kontra <pi...@gmail.com> ]------------------+
| |
| Mobile:(+36 20)356 9656 |
| |
+- "Olyan lángész vagyok, hogy poroltóval kellene járnom!" -+
On Mon, Mar 4, 2013 at 10:25 AM, KONTRA, Gergely <pi...@gmail.com>wrote:
> 2 more questions:
>
> 1. Could I compile just the fileupload project (at my first attempt, it
> complains about missing parent pom.xml)
> 2. Is the svn repository at
> http://svn.apache.org/viewvc/commons/proper/fileupload/trunk/
>
> I am behind a corporate proxy, so I'm not sure about these things. For 2.
> I get the following error:
> Redirect cycle detected for URL
> 'http://svn.apache.org/viewvc/commons/proper/fileupload/trunk'
>
> +-[ Gergely Kontra <pi...@gmail.com> ]------------------+
> | |
> | Mobile:(+36 20)356 9656 |
> | |
> +- "Olyan lángész vagyok, hogy poroltóval kellene járnom!" -+
>
>
> On Fri, Mar 1, 2013 at 5:46 PM, Mark Thomas <ma...@apache.org> wrote:
>
>> On 01/03/2013 08:41, KONTRA, Gergely wrote:
>>
>>> On Fri, Mar 1, 2013 at 5:06 PM, Benedikt Ritter <br...@apache.org>
>>> wrote:
>>>
>>> Sorry, but the github mirrors are read only (AFAIK). Usually
>>>> contributions
>>>> are made through SVN diff files uploaded to Jira. Would it be possible
>>>> for
>>>> you to upload an SVN diff to jira? Don't forget to add some unit tests
>>>> ;-)
>>>>
>>>>
>>> Yep, github mirror maybe readonly, but you can fork the repo, make
>>> changes,
>>> and submit a pull request. Does anybody watches
>>> https://github.com/apache/**commons-fileupload/pulls<https://github.com/apache/commons-fileupload/pulls>for pull requests?
>>>
>>
>> Pull requests for all read-only mirrors of ASF projects on github should
>> be routed to the relevant project dev list.
>>
>> Mark
>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@commons.apache.org>
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
Re: [fileupload] Uploading large files - DONE
Posted by Simone Tripodi <si...@apache.org>.
>> that should be enough to bump to 1.3.0 since there are APIs addition -
>> do you agree?
>
> Yes, except it should be 1.3, not 1.3.0.
> If a point release is then required, it is 1.3.1, but point releases
> are fairly rare.
OK thanks :)
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [fileupload] Uploading large files - DONE
Posted by Felix Meschberger <fm...@adobe.com>.
Hi Simo
Thanks for confirming. Very much appreciated.
Regards
Felix
Am 06.03.2013 um 16:16 schrieb Simone Tripodi:
> Hi Felix!
>
> indeed, we are putting effort on NOT breaking the backwards
> compatibility with 1.2.X, we updated to version 1.3 - due to some APIs
> update - and I personally planned to cut the next release keeping that
> version, so projects like Struts, Sling, ... could adopt it without
> feeling pain :)
>
> Thanks a lot for supervising that! :)
>
> Alles Gute!
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
> On Wed, Mar 6, 2013 at 3:54 PM, Felix Meschberger <fm...@adobe.com> wrote:
>> Hi,
>>
>> Am 06.03.2013 um 14:56 schrieb Simone Tripodi:
>>
>>> And, just for the sake of putting more steaks on the barbeque, the
>>> bundle-plugin takes care of adjusting the version in the MANIFEST.MF
>>> according to the SemVer recommendations; version is now 1.3-SNAPSHOT
>>> and look below how the MANIFEST.MF has been generated.
>>
>> So here's the topping: The Commons parent POM has configuration to set the export package version to the same as the project version:
>>
>>> <commons.osgi.export>org.apache.commons.*;version=${project.version};-noimport:=true</commons.osgi.export>
>>
>> Which is the background, why I spoke about taking care of the export package version, should you decide to release as 2.0. This would have exported the packages at 2.0 which in OSGi semantic versioning terms would constitute a backwards compatibility breaking release, which is probably not the intent of the Commons project....
>>
>> Regards
>> Felix
>>
>>>
>>> alles gute!
>>> -Simo
>>>
>>> $ cat target/osgi/MANIFEST.MF
>>> Manifest-Version: 1.0
>>> Bnd-LastModified: 1362567127928
>>> Build-Jdk: 1.6.0_37
>>> Built-By: stripodi
>>> Bundle-Description: The FileUpload component provides a simple yet flexi
>>> ble means of adding support for multipart file upload functionality
>>> to servlets and web applications.
>>> Bundle-DocURL: http://commons.apache.org/fileupload/
>>> Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.txt
>>> Bundle-ManifestVersion: 2
>>> Bundle-Name: Commons FileUpload
>>> Bundle-SymbolicName: org.apache.commons.fileupload
>>> Bundle-Vendor: The Apache Software Foundation
>>> Bundle-Version: 1.3.0.SNAPSHOT
>>> Created-By: Apache Maven Bundle Plugin
>>> DynamicImport-Package: javax.portlet
>>> Export-Package: org.apache.commons.fileupload.util;version="1.3.0.SNAPSH
>>> OT",org.apache.commons.fileupload.disk;version="1.3.0.SNAPSHOT",org.apa
>>> che.commons.fileupload;version="1.3.0.SNAPSHOT",org.apache.commons.file
>>> upload.servlet;version="1.3.0.SNAPSHOT",org.apache.commons.fileupload.p
>>> ortlet;version="1.3.0.SNAPSHOT"
>>> Import-Package: javax.servlet,javax.servlet.http,org.apache.commons.io,o
>>> rg.apache.commons.io.output
>>> Include-Resource: META-INF/LICENSE.txt=LICENSE.txt,META-INF/NOTICE.txt=N
>>> OTICE.txt
>>> Tool: Bnd-1.50.0
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://simonetripodi.livejournal.com/
>>> http://twitter.com/simonetripodi
>>> http://www.99soft.org/
>>>
>>>
>>> On Wed, Mar 6, 2013 at 2:32 PM, Benedikt Ritter <br...@apache.org> wrote:
>>>> 2013/3/6 Felix Meschberger <fm...@adobe.com>
>>>>
>>>>> Hi,
>>>>>
>>>>> Am 06.03.2013 um 12:51 schrieb Benedikt Ritter:
>>>>>
>>>>>> 2013/3/6 sebb <se...@gmail.com>
>>>>>>
>>>>>>> On 6 March 2013 08:53, Simone Tripodi <si...@apache.org> wrote:
>>>>>>>>>> Is there anybody that can suggest how to handle that situation?
>>>>>>>>>
>>>>>>>>> Create new methods which return long rather than int; deprecate the
>>>>> old
>>>>>>> methods.
>>>>>>>>>
>>>>>>>>> e.g.
>>>>>>>>>
>>>>>>>>> @Deprecated
>>>>>>>>> public int getContentLength() { ... }
>>>>>>>>>
>>>>>>>>> /**
>>>>>>>>> * @since x.x
>>>>>>>>> */
>>>>>>>>>
>>>>>>>>> public long getLongContentLength() { ... }
>>>>>>>>> or
>>>>>>>>> public long getContentLengthLong() { ... }
>>>>>>>>> or
>>>>>>>>> public long longContentLength() { ... }
>>>>>>>>
>>>>>>>> that should be enough to bump to 1.3.0 since there are APIs addition -
>>>>>>>> do you agree?
>>>>>>>
>>>>>>> Yes, except it should be 1.3, not 1.3.0.
>>>>>>> If a point release is then required, it is 1.3.1, but point releases
>>>>>>> are fairly rare.
>>>>>>>
>>>>>>
>>>>>> Having OSGi this may not be the best convention, as OSGi requires version
>>>>>> numbers to have 3 digits.
>>>>>
>>>>> Not really, 1.3 is a perfectly valid OSGi version, too. Actually, even 1
>>>>> is a valid version (according to the OSGi Syntax)
>>>>>
>>>>
>>>> Hi Felix,
>>>>
>>>> thanks for enlighting me about OSGi once again :)
>>>>
>>>> Benedikt
>>>>
>>>>
>>>>>
>>>>> Regards
>>>>> Felix
>>>>>
>>>>>>
>>>>>> Benedikt
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>> -Simo
>>>>>>>>
>>>>>>>> http://people.apache.org/~simonetripodi/
>>>>>>>> http://simonetripodi.livejournal.com/
>>>>>>>> http://twitter.com/simonetripodi
>>>>>>>> http://www.99soft.org/
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> http://people.apache.org/~britter/
>>>>>> http://www.systemoutprintln.de/
>>>>>> http://twitter.com/BenediktRitter
>>>>>> http://github.com/britter
>>>>>
>>>>>
>>>>> --
>>>>> Felix Meschberger | Principal Scientist | Adobe
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> http://people.apache.org/~britter/
>>>> http://www.systemoutprintln.de/
>>>> http://twitter.com/BenediktRitter
>>>> http://github.com/britter
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>>
>> --
>> Felix Meschberger | Principal Scientist | Adobe
>>
>>
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
--
Felix Meschberger | Principal Scientist | Adobe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [fileupload] Uploading large files - DONE
Posted by Simone Tripodi <si...@apache.org>.
Hi Felix!
indeed, we are putting effort on NOT breaking the backwards
compatibility with 1.2.X, we updated to version 1.3 - due to some APIs
update - and I personally planned to cut the next release keeping that
version, so projects like Struts, Sling, ... could adopt it without
feeling pain :)
Thanks a lot for supervising that! :)
Alles Gute!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Wed, Mar 6, 2013 at 3:54 PM, Felix Meschberger <fm...@adobe.com> wrote:
> Hi,
>
> Am 06.03.2013 um 14:56 schrieb Simone Tripodi:
>
>> And, just for the sake of putting more steaks on the barbeque, the
>> bundle-plugin takes care of adjusting the version in the MANIFEST.MF
>> according to the SemVer recommendations; version is now 1.3-SNAPSHOT
>> and look below how the MANIFEST.MF has been generated.
>
> So here's the topping: The Commons parent POM has configuration to set the export package version to the same as the project version:
>
>> <commons.osgi.export>org.apache.commons.*;version=${project.version};-noimport:=true</commons.osgi.export>
>
> Which is the background, why I spoke about taking care of the export package version, should you decide to release as 2.0. This would have exported the packages at 2.0 which in OSGi semantic versioning terms would constitute a backwards compatibility breaking release, which is probably not the intent of the Commons project....
>
> Regards
> Felix
>
>>
>> alles gute!
>> -Simo
>>
>> $ cat target/osgi/MANIFEST.MF
>> Manifest-Version: 1.0
>> Bnd-LastModified: 1362567127928
>> Build-Jdk: 1.6.0_37
>> Built-By: stripodi
>> Bundle-Description: The FileUpload component provides a simple yet flexi
>> ble means of adding support for multipart file upload functionality
>> to servlets and web applications.
>> Bundle-DocURL: http://commons.apache.org/fileupload/
>> Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.txt
>> Bundle-ManifestVersion: 2
>> Bundle-Name: Commons FileUpload
>> Bundle-SymbolicName: org.apache.commons.fileupload
>> Bundle-Vendor: The Apache Software Foundation
>> Bundle-Version: 1.3.0.SNAPSHOT
>> Created-By: Apache Maven Bundle Plugin
>> DynamicImport-Package: javax.portlet
>> Export-Package: org.apache.commons.fileupload.util;version="1.3.0.SNAPSH
>> OT",org.apache.commons.fileupload.disk;version="1.3.0.SNAPSHOT",org.apa
>> che.commons.fileupload;version="1.3.0.SNAPSHOT",org.apache.commons.file
>> upload.servlet;version="1.3.0.SNAPSHOT",org.apache.commons.fileupload.p
>> ortlet;version="1.3.0.SNAPSHOT"
>> Import-Package: javax.servlet,javax.servlet.http,org.apache.commons.io,o
>> rg.apache.commons.io.output
>> Include-Resource: META-INF/LICENSE.txt=LICENSE.txt,META-INF/NOTICE.txt=N
>> OTICE.txt
>> Tool: Bnd-1.50.0
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>> On Wed, Mar 6, 2013 at 2:32 PM, Benedikt Ritter <br...@apache.org> wrote:
>>> 2013/3/6 Felix Meschberger <fm...@adobe.com>
>>>
>>>> Hi,
>>>>
>>>> Am 06.03.2013 um 12:51 schrieb Benedikt Ritter:
>>>>
>>>>> 2013/3/6 sebb <se...@gmail.com>
>>>>>
>>>>>> On 6 March 2013 08:53, Simone Tripodi <si...@apache.org> wrote:
>>>>>>>>> Is there anybody that can suggest how to handle that situation?
>>>>>>>>
>>>>>>>> Create new methods which return long rather than int; deprecate the
>>>> old
>>>>>> methods.
>>>>>>>>
>>>>>>>> e.g.
>>>>>>>>
>>>>>>>> @Deprecated
>>>>>>>> public int getContentLength() { ... }
>>>>>>>>
>>>>>>>> /**
>>>>>>>> * @since x.x
>>>>>>>> */
>>>>>>>>
>>>>>>>> public long getLongContentLength() { ... }
>>>>>>>> or
>>>>>>>> public long getContentLengthLong() { ... }
>>>>>>>> or
>>>>>>>> public long longContentLength() { ... }
>>>>>>>
>>>>>>> that should be enough to bump to 1.3.0 since there are APIs addition -
>>>>>>> do you agree?
>>>>>>
>>>>>> Yes, except it should be 1.3, not 1.3.0.
>>>>>> If a point release is then required, it is 1.3.1, but point releases
>>>>>> are fairly rare.
>>>>>>
>>>>>
>>>>> Having OSGi this may not be the best convention, as OSGi requires version
>>>>> numbers to have 3 digits.
>>>>
>>>> Not really, 1.3 is a perfectly valid OSGi version, too. Actually, even 1
>>>> is a valid version (according to the OSGi Syntax)
>>>>
>>>
>>> Hi Felix,
>>>
>>> thanks for enlighting me about OSGi once again :)
>>>
>>> Benedikt
>>>
>>>
>>>>
>>>> Regards
>>>> Felix
>>>>
>>>>>
>>>>> Benedikt
>>>>>
>>>>>
>>>>>>
>>>>>>> -Simo
>>>>>>>
>>>>>>> http://people.apache.org/~simonetripodi/
>>>>>>> http://simonetripodi.livejournal.com/
>>>>>>> http://twitter.com/simonetripodi
>>>>>>> http://www.99soft.org/
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> http://people.apache.org/~britter/
>>>>> http://www.systemoutprintln.de/
>>>>> http://twitter.com/BenediktRitter
>>>>> http://github.com/britter
>>>>
>>>>
>>>> --
>>>> Felix Meschberger | Principal Scientist | Adobe
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> http://people.apache.org/~britter/
>>> http://www.systemoutprintln.de/
>>> http://twitter.com/BenediktRitter
>>> http://github.com/britter
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> --
> Felix Meschberger | Principal Scientist | Adobe
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> 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: [fileupload] Uploading large files - DONE
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am 06.03.2013 um 14:56 schrieb Simone Tripodi:
> And, just for the sake of putting more steaks on the barbeque, the
> bundle-plugin takes care of adjusting the version in the MANIFEST.MF
> according to the SemVer recommendations; version is now 1.3-SNAPSHOT
> and look below how the MANIFEST.MF has been generated.
So here's the topping: The Commons parent POM has configuration to set the export package version to the same as the project version:
> <commons.osgi.export>org.apache.commons.*;version=${project.version};-noimport:=true</commons.osgi.export>
Which is the background, why I spoke about taking care of the export package version, should you decide to release as 2.0. This would have exported the packages at 2.0 which in OSGi semantic versioning terms would constitute a backwards compatibility breaking release, which is probably not the intent of the Commons project....
Regards
Felix
>
> alles gute!
> -Simo
>
> $ cat target/osgi/MANIFEST.MF
> Manifest-Version: 1.0
> Bnd-LastModified: 1362567127928
> Build-Jdk: 1.6.0_37
> Built-By: stripodi
> Bundle-Description: The FileUpload component provides a simple yet flexi
> ble means of adding support for multipart file upload functionality
> to servlets and web applications.
> Bundle-DocURL: http://commons.apache.org/fileupload/
> Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.txt
> Bundle-ManifestVersion: 2
> Bundle-Name: Commons FileUpload
> Bundle-SymbolicName: org.apache.commons.fileupload
> Bundle-Vendor: The Apache Software Foundation
> Bundle-Version: 1.3.0.SNAPSHOT
> Created-By: Apache Maven Bundle Plugin
> DynamicImport-Package: javax.portlet
> Export-Package: org.apache.commons.fileupload.util;version="1.3.0.SNAPSH
> OT",org.apache.commons.fileupload.disk;version="1.3.0.SNAPSHOT",org.apa
> che.commons.fileupload;version="1.3.0.SNAPSHOT",org.apache.commons.file
> upload.servlet;version="1.3.0.SNAPSHOT",org.apache.commons.fileupload.p
> ortlet;version="1.3.0.SNAPSHOT"
> Import-Package: javax.servlet,javax.servlet.http,org.apache.commons.io,o
> rg.apache.commons.io.output
> Include-Resource: META-INF/LICENSE.txt=LICENSE.txt,META-INF/NOTICE.txt=N
> OTICE.txt
> Tool: Bnd-1.50.0
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
> On Wed, Mar 6, 2013 at 2:32 PM, Benedikt Ritter <br...@apache.org> wrote:
>> 2013/3/6 Felix Meschberger <fm...@adobe.com>
>>
>>> Hi,
>>>
>>> Am 06.03.2013 um 12:51 schrieb Benedikt Ritter:
>>>
>>>> 2013/3/6 sebb <se...@gmail.com>
>>>>
>>>>> On 6 March 2013 08:53, Simone Tripodi <si...@apache.org> wrote:
>>>>>>>> Is there anybody that can suggest how to handle that situation?
>>>>>>>
>>>>>>> Create new methods which return long rather than int; deprecate the
>>> old
>>>>> methods.
>>>>>>>
>>>>>>> e.g.
>>>>>>>
>>>>>>> @Deprecated
>>>>>>> public int getContentLength() { ... }
>>>>>>>
>>>>>>> /**
>>>>>>> * @since x.x
>>>>>>> */
>>>>>>>
>>>>>>> public long getLongContentLength() { ... }
>>>>>>> or
>>>>>>> public long getContentLengthLong() { ... }
>>>>>>> or
>>>>>>> public long longContentLength() { ... }
>>>>>>
>>>>>> that should be enough to bump to 1.3.0 since there are APIs addition -
>>>>>> do you agree?
>>>>>
>>>>> Yes, except it should be 1.3, not 1.3.0.
>>>>> If a point release is then required, it is 1.3.1, but point releases
>>>>> are fairly rare.
>>>>>
>>>>
>>>> Having OSGi this may not be the best convention, as OSGi requires version
>>>> numbers to have 3 digits.
>>>
>>> Not really, 1.3 is a perfectly valid OSGi version, too. Actually, even 1
>>> is a valid version (according to the OSGi Syntax)
>>>
>>
>> Hi Felix,
>>
>> thanks for enlighting me about OSGi once again :)
>>
>> Benedikt
>>
>>
>>>
>>> Regards
>>> Felix
>>>
>>>>
>>>> Benedikt
>>>>
>>>>
>>>>>
>>>>>> -Simo
>>>>>>
>>>>>> http://people.apache.org/~simonetripodi/
>>>>>> http://simonetripodi.livejournal.com/
>>>>>> http://twitter.com/simonetripodi
>>>>>> http://www.99soft.org/
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> http://people.apache.org/~britter/
>>>> http://www.systemoutprintln.de/
>>>> http://twitter.com/BenediktRitter
>>>> http://github.com/britter
>>>
>>>
>>> --
>>> Felix Meschberger | Principal Scientist | Adobe
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>> --
>> http://people.apache.org/~britter/
>> http://www.systemoutprintln.de/
>> http://twitter.com/BenediktRitter
>> http://github.com/britter
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
Felix Meschberger | Principal Scientist | Adobe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [fileupload] Uploading large files - DONE
Posted by Simone Tripodi <si...@apache.org>.
And, just for the sake of putting more steaks on the barbeque, the
bundle-plugin takes care of adjusting the version in the MANIFEST.MF
according to the SemVer recommendations; version is now 1.3-SNAPSHOT
and look below how the MANIFEST.MF has been generated.
alles gute!
-Simo
$ cat target/osgi/MANIFEST.MF
Manifest-Version: 1.0
Bnd-LastModified: 1362567127928
Build-Jdk: 1.6.0_37
Built-By: stripodi
Bundle-Description: The FileUpload component provides a simple yet flexi
ble means of adding support for multipart file upload functionality
to servlets and web applications.
Bundle-DocURL: http://commons.apache.org/fileupload/
Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.txt
Bundle-ManifestVersion: 2
Bundle-Name: Commons FileUpload
Bundle-SymbolicName: org.apache.commons.fileupload
Bundle-Vendor: The Apache Software Foundation
Bundle-Version: 1.3.0.SNAPSHOT
Created-By: Apache Maven Bundle Plugin
DynamicImport-Package: javax.portlet
Export-Package: org.apache.commons.fileupload.util;version="1.3.0.SNAPSH
OT",org.apache.commons.fileupload.disk;version="1.3.0.SNAPSHOT",org.apa
che.commons.fileupload;version="1.3.0.SNAPSHOT",org.apache.commons.file
upload.servlet;version="1.3.0.SNAPSHOT",org.apache.commons.fileupload.p
ortlet;version="1.3.0.SNAPSHOT"
Import-Package: javax.servlet,javax.servlet.http,org.apache.commons.io,o
rg.apache.commons.io.output
Include-Resource: META-INF/LICENSE.txt=LICENSE.txt,META-INF/NOTICE.txt=N
OTICE.txt
Tool: Bnd-1.50.0
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Wed, Mar 6, 2013 at 2:32 PM, Benedikt Ritter <br...@apache.org> wrote:
> 2013/3/6 Felix Meschberger <fm...@adobe.com>
>
>> Hi,
>>
>> Am 06.03.2013 um 12:51 schrieb Benedikt Ritter:
>>
>> > 2013/3/6 sebb <se...@gmail.com>
>> >
>> >> On 6 March 2013 08:53, Simone Tripodi <si...@apache.org> wrote:
>> >>>>> Is there anybody that can suggest how to handle that situation?
>> >>>>
>> >>>> Create new methods which return long rather than int; deprecate the
>> old
>> >> methods.
>> >>>>
>> >>>> e.g.
>> >>>>
>> >>>> @Deprecated
>> >>>> public int getContentLength() { ... }
>> >>>>
>> >>>> /**
>> >>>> * @since x.x
>> >>>> */
>> >>>>
>> >>>> public long getLongContentLength() { ... }
>> >>>> or
>> >>>> public long getContentLengthLong() { ... }
>> >>>> or
>> >>>> public long longContentLength() { ... }
>> >>>
>> >>> that should be enough to bump to 1.3.0 since there are APIs addition -
>> >>> do you agree?
>> >>
>> >> Yes, except it should be 1.3, not 1.3.0.
>> >> If a point release is then required, it is 1.3.1, but point releases
>> >> are fairly rare.
>> >>
>> >
>> > Having OSGi this may not be the best convention, as OSGi requires version
>> > numbers to have 3 digits.
>>
>> Not really, 1.3 is a perfectly valid OSGi version, too. Actually, even 1
>> is a valid version (according to the OSGi Syntax)
>>
>
> Hi Felix,
>
> thanks for enlighting me about OSGi once again :)
>
> Benedikt
>
>
>>
>> Regards
>> Felix
>>
>> >
>> > Benedikt
>> >
>> >
>> >>
>> >>> -Simo
>> >>>
>> >>> http://people.apache.org/~simonetripodi/
>> >>> http://simonetripodi.livejournal.com/
>> >>> http://twitter.com/simonetripodi
>> >>> http://www.99soft.org/
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> 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
>> >>
>> >>
>> >
>> >
>> > --
>> > http://people.apache.org/~britter/
>> > http://www.systemoutprintln.de/
>> > http://twitter.com/BenediktRitter
>> > http://github.com/britter
>>
>>
>> --
>> Felix Meschberger | Principal Scientist | Adobe
>>
>>
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [fileupload] Uploading large files - DONE
Posted by Benedikt Ritter <br...@apache.org>.
2013/3/6 Felix Meschberger <fm...@adobe.com>
> Hi,
>
> Am 06.03.2013 um 12:51 schrieb Benedikt Ritter:
>
> > 2013/3/6 sebb <se...@gmail.com>
> >
> >> On 6 March 2013 08:53, Simone Tripodi <si...@apache.org> wrote:
> >>>>> Is there anybody that can suggest how to handle that situation?
> >>>>
> >>>> Create new methods which return long rather than int; deprecate the
> old
> >> methods.
> >>>>
> >>>> e.g.
> >>>>
> >>>> @Deprecated
> >>>> public int getContentLength() { ... }
> >>>>
> >>>> /**
> >>>> * @since x.x
> >>>> */
> >>>>
> >>>> public long getLongContentLength() { ... }
> >>>> or
> >>>> public long getContentLengthLong() { ... }
> >>>> or
> >>>> public long longContentLength() { ... }
> >>>
> >>> that should be enough to bump to 1.3.0 since there are APIs addition -
> >>> do you agree?
> >>
> >> Yes, except it should be 1.3, not 1.3.0.
> >> If a point release is then required, it is 1.3.1, but point releases
> >> are fairly rare.
> >>
> >
> > Having OSGi this may not be the best convention, as OSGi requires version
> > numbers to have 3 digits.
>
> Not really, 1.3 is a perfectly valid OSGi version, too. Actually, even 1
> is a valid version (according to the OSGi Syntax)
>
Hi Felix,
thanks for enlighting me about OSGi once again :)
Benedikt
>
> Regards
> Felix
>
> >
> > Benedikt
> >
> >
> >>
> >>> -Simo
> >>>
> >>> http://people.apache.org/~simonetripodi/
> >>> http://simonetripodi.livejournal.com/
> >>> http://twitter.com/simonetripodi
> >>> http://www.99soft.org/
> >>>
> >>> ---------------------------------------------------------------------
> >>> 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
> >>
> >>
> >
> >
> > --
> > http://people.apache.org/~britter/
> > http://www.systemoutprintln.de/
> > http://twitter.com/BenediktRitter
> > http://github.com/britter
>
>
> --
> Felix Meschberger | Principal Scientist | Adobe
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: [fileupload] Uploading large files - DONE
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am 06.03.2013 um 12:51 schrieb Benedikt Ritter:
> 2013/3/6 sebb <se...@gmail.com>
>
>> On 6 March 2013 08:53, Simone Tripodi <si...@apache.org> wrote:
>>>>> Is there anybody that can suggest how to handle that situation?
>>>>
>>>> Create new methods which return long rather than int; deprecate the old
>> methods.
>>>>
>>>> e.g.
>>>>
>>>> @Deprecated
>>>> public int getContentLength() { ... }
>>>>
>>>> /**
>>>> * @since x.x
>>>> */
>>>>
>>>> public long getLongContentLength() { ... }
>>>> or
>>>> public long getContentLengthLong() { ... }
>>>> or
>>>> public long longContentLength() { ... }
>>>
>>> that should be enough to bump to 1.3.0 since there are APIs addition -
>>> do you agree?
>>
>> Yes, except it should be 1.3, not 1.3.0.
>> If a point release is then required, it is 1.3.1, but point releases
>> are fairly rare.
>>
>
> Having OSGi this may not be the best convention, as OSGi requires version
> numbers to have 3 digits.
Not really, 1.3 is a perfectly valid OSGi version, too. Actually, even 1 is a valid version (according to the OSGi Syntax)
Regards
Felix
>
> Benedikt
>
>
>>
>>> -Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://simonetripodi.livejournal.com/
>>> http://twitter.com/simonetripodi
>>> http://www.99soft.org/
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
--
Felix Meschberger | Principal Scientist | Adobe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [fileupload] Uploading large files - DONE
Posted by sebb <se...@gmail.com>.
On 6 March 2013 11:51, Benedikt Ritter <br...@apache.org> wrote:
> 2013/3/6 sebb <se...@gmail.com>
>
>> On 6 March 2013 08:53, Simone Tripodi <si...@apache.org> wrote:
>> >>> Is there anybody that can suggest how to handle that situation?
>> >>
>> >> Create new methods which return long rather than int; deprecate the old
>> methods.
>> >>
>> >> e.g.
>> >>
>> >> @Deprecated
>> >> public int getContentLength() { ... }
>> >>
>> >> /**
>> >> * @since x.x
>> >> */
>> >>
>> >> public long getLongContentLength() { ... }
>> >> or
>> >> public long getContentLengthLong() { ... }
>> >> or
>> >> public long longContentLength() { ... }
>> >
>> > that should be enough to bump to 1.3.0 since there are APIs addition -
>> > do you agree?
>>
>> Yes, except it should be 1.3, not 1.3.0.
>> If a point release is then required, it is 1.3.1, but point releases
>> are fairly rare.
>>
>
> Having OSGi this may not be the best convention, as OSGi requires version
> numbers to have 3 digits.
Well, all the other Commons components omit the .0 so I assume the
generated OSGi manifest must take care of this somehow.
I don't believe our numbering scheme should be dictated by OSGi.
> Benedikt
>
>
>>
>> > -Simo
>> >
>> > http://people.apache.org/~simonetripodi/
>> > http://simonetripodi.livejournal.com/
>> > http://twitter.com/simonetripodi
>> > http://www.99soft.org/
>> >
>> > ---------------------------------------------------------------------
>> > 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
>>
>>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [fileupload] Uploading large files - DONE
Posted by Benedikt Ritter <br...@apache.org>.
2013/3/6 sebb <se...@gmail.com>
> On 6 March 2013 08:53, Simone Tripodi <si...@apache.org> wrote:
> >>> Is there anybody that can suggest how to handle that situation?
> >>
> >> Create new methods which return long rather than int; deprecate the old
> methods.
> >>
> >> e.g.
> >>
> >> @Deprecated
> >> public int getContentLength() { ... }
> >>
> >> /**
> >> * @since x.x
> >> */
> >>
> >> public long getLongContentLength() { ... }
> >> or
> >> public long getContentLengthLong() { ... }
> >> or
> >> public long longContentLength() { ... }
> >
> > that should be enough to bump to 1.3.0 since there are APIs addition -
> > do you agree?
>
> Yes, except it should be 1.3, not 1.3.0.
> If a point release is then required, it is 1.3.1, but point releases
> are fairly rare.
>
Having OSGi this may not be the best convention, as OSGi requires version
numbers to have 3 digits.
Benedikt
>
> > -Simo
> >
> > http://people.apache.org/~simonetripodi/
> > http://simonetripodi.livejournal.com/
> > http://twitter.com/simonetripodi
> > http://www.99soft.org/
> >
> > ---------------------------------------------------------------------
> > 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
>
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: [fileupload] Uploading large files - DONE
Posted by sebb <se...@gmail.com>.
On 6 March 2013 08:53, Simone Tripodi <si...@apache.org> wrote:
>>> Is there anybody that can suggest how to handle that situation?
>>
>> Create new methods which return long rather than int; deprecate the old methods.
>>
>> e.g.
>>
>> @Deprecated
>> public int getContentLength() { ... }
>>
>> /**
>> * @since x.x
>> */
>>
>> public long getLongContentLength() { ... }
>> or
>> public long getContentLengthLong() { ... }
>> or
>> public long longContentLength() { ... }
>
> that should be enough to bump to 1.3.0 since there are APIs addition -
> do you agree?
Yes, except it should be 1.3, not 1.3.0.
If a point release is then required, it is 1.3.1, but point releases
are fairly rare.
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
> ---------------------------------------------------------------------
> 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: [fileupload] Uploading large files - DONE
Posted by Simone Tripodi <si...@apache.org>.
>> Is there anybody that can suggest how to handle that situation?
>
> Create new methods which return long rather than int; deprecate the old methods.
>
> e.g.
>
> @Deprecated
> public int getContentLength() { ... }
>
> /**
> * @since x.x
> */
>
> public long getLongContentLength() { ... }
> or
> public long getContentLengthLong() { ... }
> or
> public long longContentLength() { ... }
that should be enough to bump to 1.3.0 since there are APIs addition -
do you agree?
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [fileupload] Uploading large files - DONE
Posted by sebb <se...@gmail.com>.
On 5 March 2013 15:46, Simone Tripodi <si...@apache.org> wrote:
> Hi again Gergo,
>
> patch looks OK to me, the problem we would have ATM is the backward
> compatibility, since there methods signature change.
>
> Is there anybody that can suggest how to handle that situation?
Create new methods which return long rather than int; deprecate the old methods.
e.g.
@Deprecated
public int getContentLength() { ... }
/**
* @since x.x
*/
public long getLongContentLength() { ... }
or
public long getContentLengthLong() { ... }
or
public long longContentLength() { ... }
etc.
> TIA,
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
> ---------------------------------------------------------------------
> 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: [fileupload] Uploading large files - DONE
Posted by Simone Tripodi <si...@apache.org>.
Hi again Gergo,
patch looks OK to me, the problem we would have ATM is the backward
compatibility, since there methods signature change.
Is there anybody that can suggest how to handle that situation?
TIA,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [fileupload] Uploading large files - DONE
Posted by Simone Tripodi <si...@apache.org>.
Hi Gergo,
> I've finished my patch for 2Gb+ uploads.
> Since I don't use portlets, it needs some additional fix for portlets (it's
> not broken, just returns -1 as the total size of the file, when it's over
> 2Gb.
>
> Gergo
very good, thanks, since I am doing some work on [fileupload], I am
reviewing your patch right now.
I'll let you know ASAP.
best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Tue, Mar 5, 2013 at 4:37 PM, KONTRA, Gergely <pi...@gmail.com> wrote:
> Dear all!
>
> I've finished my patch for 2Gb+ uploads.
> Since I don't use portlets, it needs some additional fix for portlets (it's
> not broken, just returns -1 as the total size of the file, when it's over
> 2Gb.
>
> Gergo
>
> see
> https://github.com/pihentagy/commons-fileupload/commit/16a677dd3c61acde530a5f54a59402faed1a953a
>
> ps: feel free to contact me if you need additional info for the merge.
>
> +-[ Gergely Kontra <pi...@gmail.com> ]------------------+
> | |
> | Mobile:(+36 20)356 9656 |
> | |
> +- "Olyan lángész vagyok, hogy poroltóval kellene járnom!" -+
>
>
> On Mon, Mar 4, 2013 at 10:25 AM, KONTRA, Gergely <pi...@gmail.com>wrote:
>
>> 2 more questions:
>>
>> 1. Could I compile just the fileupload project (at my first attempt, it
>> complains about missing parent pom.xml)
>> 2. Is the svn repository at
>> http://svn.apache.org/viewvc/commons/proper/fileupload/trunk/
>>
>> I am behind a corporate proxy, so I'm not sure about these things. For 2.
>> I get the following error:
>> Redirect cycle detected for URL
>> 'http://svn.apache.org/viewvc/commons/proper/fileupload/trunk'
>>
>> +-[ Gergely Kontra <pi...@gmail.com> ]------------------+
>> | |
>> | Mobile:(+36 20)356 9656 |
>> | |
>> +- "Olyan lángész vagyok, hogy poroltóval kellene járnom!" -+
>>
>>
>> On Fri, Mar 1, 2013 at 5:46 PM, Mark Thomas <ma...@apache.org> wrote:
>>
>>> On 01/03/2013 08:41, KONTRA, Gergely wrote:
>>>
>>>> On Fri, Mar 1, 2013 at 5:06 PM, Benedikt Ritter <br...@apache.org>
>>>> wrote:
>>>>
>>>> Sorry, but the github mirrors are read only (AFAIK). Usually
>>>>> contributions
>>>>> are made through SVN diff files uploaded to Jira. Would it be possible
>>>>> for
>>>>> you to upload an SVN diff to jira? Don't forget to add some unit tests
>>>>> ;-)
>>>>>
>>>>>
>>>> Yep, github mirror maybe readonly, but you can fork the repo, make
>>>> changes,
>>>> and submit a pull request. Does anybody watches
>>>> https://github.com/apache/**commons-fileupload/pulls<https://github.com/apache/commons-fileupload/pulls>for pull requests?
>>>>
>>>
>>> Pull requests for all read-only mirrors of ASF projects on github should
>>> be routed to the relevant project dev list.
>>>
>>> Mark
>>>
>>>
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<de...@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