Re: [fileupload] Uploading large files - DONE

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [fileupload] Uploading large files - DONE

KONTRA, Gergely
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 <[hidden email]> ]------------------+
|                                                           |
| 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 <[hidden email]>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 <[hidden email]> ]------------------+
> |                                                           |
> | 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 <[hidden email]> wrote:
>
>> On 01/03/2013 08:41, KONTRA, Gergely wrote:
>>
>>> On Fri, Mar 1, 2013 at 5:06 PM, Benedikt Ritter <[hidden email]>
>>> 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<[hidden email]>
>> For additional commands, e-mail: [hidden email]
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: [fileupload] Uploading large files - DONE

Simone Tripodi-2
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 <[hidden email]> 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 <[hidden email]> ]------------------+
> |                                                           |
> | 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 <[hidden email]>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 <[hidden email]> ]------------------+
>> |                                                           |
>> | 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 <[hidden email]> wrote:
>>
>>> On 01/03/2013 08:41, KONTRA, Gergely wrote:
>>>
>>>> On Fri, Mar 1, 2013 at 5:06 PM, Benedikt Ritter <[hidden email]>
>>>> 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<[hidden email]>
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [fileupload] Uploading large files - DONE

Simone Tripodi-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [fileupload] Uploading large files - DONE

sebb-2-2
On 5 March 2013 15:46, Simone Tripodi <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [fileupload] Uploading large files - DONE

Simone Tripodi-2
>> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [fileupload] Uploading large files - DONE

sebb-2-2
On 6 March 2013 08:53, Simone Tripodi <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [fileupload] Uploading large files - DONE

Simone Tripodi-2
>> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [fileupload] Uploading large files - DONE

Benedikt Ritter-4
In reply to this post by sebb-2-2
2013/3/6 sebb <[hidden email]>

> On 6 March 2013 08:53, Simone Tripodi <[hidden email]> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Reply | Threaded
Open this post in threaded view
|

Re: [fileupload] Uploading large files - DONE

sebb-2-2
On 6 March 2013 11:51, Benedikt Ritter <[hidden email]> wrote:

> 2013/3/6 sebb <[hidden email]>
>
>> On 6 March 2013 08:53, Simone Tripodi <[hidden email]> 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: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [fileupload] Uploading large files - DONE

Felix Meschberger
In reply to this post by Benedikt Ritter-4
Hi,

Am 06.03.2013 um 12:51 schrieb Benedikt Ritter:

> 2013/3/6 sebb <[hidden email]>
>
>> On 6 March 2013 08:53, Simone Tripodi <[hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> --
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [fileupload] Uploading large files - DONE

Benedikt Ritter-4
2013/3/6 Felix Meschberger <[hidden email]>

> Hi,
>
> Am 06.03.2013 um 12:51 schrieb Benedikt Ritter:
>
> > 2013/3/6 sebb <[hidden email]>
> >
> >> On 6 March 2013 08:53, Simone Tripodi <[hidden email]> 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: [hidden email]
> >>> For additional commands, e-mail: [hidden email]
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
> >
> >
> > --
> > 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Reply | Threaded
Open this post in threaded view
|

Re: [fileupload] Uploading large files - DONE

Simone Tripodi-2
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 <[hidden email]> wrote:

> 2013/3/6 Felix Meschberger <[hidden email]>
>
>> Hi,
>>
>> Am 06.03.2013 um 12:51 schrieb Benedikt Ritter:
>>
>> > 2013/3/6 sebb <[hidden email]>
>> >
>> >> On 6 March 2013 08:53, Simone Tripodi <[hidden email]> 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: [hidden email]
>> >>> For additional commands, e-mail: [hidden email]
>> >>>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [hidden email]
>> >> For additional commands, e-mail: [hidden email]
>> >>
>> >>
>> >
>> >
>> > --
>> > 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [fileupload] Uploading large files - DONE

Felix Meschberger
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 <[hidden email]> wrote:
>> 2013/3/6 Felix Meschberger <[hidden email]>
>>
>>> Hi,
>>>
>>> Am 06.03.2013 um 12:51 schrieb Benedikt Ritter:
>>>
>>>> 2013/3/6 sebb <[hidden email]>
>>>>
>>>>> On 6 March 2013 08:53, Simone Tripodi <[hidden email]> 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: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>>
>> --
>> http://people.apache.org/~britter/
>> http://www.systemoutprintln.de/
>> http://twitter.com/BenediktRitter
>> http://github.com/britter
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


--
Felix Meschberger | Principal Scientist | Adobe








---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [fileupload] Uploading large files - DONE

Simone Tripodi-2
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 <[hidden email]> 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 <[hidden email]> wrote:
>>> 2013/3/6 Felix Meschberger <[hidden email]>
>>>
>>>> Hi,
>>>>
>>>> Am 06.03.2013 um 12:51 schrieb Benedikt Ritter:
>>>>
>>>>> 2013/3/6 sebb <[hidden email]>
>>>>>
>>>>>> On 6 March 2013 08:53, Simone Tripodi <[hidden email]> 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: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>>
>>> --
>>> http://people.apache.org/~britter/
>>> http://www.systemoutprintln.de/
>>> http://twitter.com/BenediktRitter
>>> http://github.com/britter
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> --
> Felix Meschberger | Principal Scientist | Adobe
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [fileupload] Uploading large files - DONE

Felix Meschberger
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 <[hidden email]> 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 <[hidden email]> wrote:
>>>> 2013/3/6 Felix Meschberger <[hidden email]>
>>>>
>>>>> Hi,
>>>>>
>>>>> Am 06.03.2013 um 12:51 schrieb Benedikt Ritter:
>>>>>
>>>>>> 2013/3/6 sebb <[hidden email]>
>>>>>>
>>>>>>> On 6 March 2013 08:53, Simone Tripodi <[hidden email]> 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: [hidden email]
>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> http://people.apache.org/~britter/
>>>> http://www.systemoutprintln.de/
>>>> http://twitter.com/BenediktRitter
>>>> http://github.com/britter
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>>
>> --
>> Felix Meschberger | Principal Scientist | Adobe
>>
>>
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


--
Felix Meschberger | Principal Scientist | Adobe








---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]