Hallo Jörg!
> Looks fine from a compatibility view. I wonder if we should add a comment in
> the javadoc that the new interface is just there for backward compatibility
> and it might vanish for a refactored 2.x version moving the new method into
> RequestContext again.
sounds reasonable, I am go
Hi Simo,
Simone Tripodi wrote:
> Hi again Jörg!
> I just included that modification on r1455855, may I can kindly ask
> you for a review?
Looks fine from a compatibility view. I wonder if we should add a comment in
the javadoc that the new interface is just there for backward compatibility
and
Hi again Jörg!
I just included that modification on r1455855, may I can kindly ask
you for a review?
Many thanks in advance, alles gute!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Wed, Mar 13, 20
Hallo Jörg,
>
> class RequestContext {
> // [snip]
> @Deprecated // since 1.3
> int getContentLength();
> }
>
> // @since 1.3
> class RequestContextExt extends RequestContext {
> // @since 1.3
> long contentLength();
> }
>
should work like a charm, it will require a little more work to
propagate
Hi Simo,
Simone Tripodi wrote:
>> Adding a new method to the public RequestContext interface also creates
>> an Clirr error, as classes implementing this interface are required to
>> implement this method.
>
> yup I know it, but the alternative of suppressing this breakage is
> pushing back FILE
> Adding a new method to the public RequestContext interface also creates
> an Clirr error, as classes implementing this interface are required to
> implement this method.
yup I know it, but the alternative of suppressing this breakage is
pushing back FILEUPLOAD-188 and FILEUPLOAD-195.
Do you have
On 03/09/2013 02:32 PM, Simone Tripodi wrote:
> Hi all,
>
> I've prepared the RC1 of Apache Commons-FileUpload 1.3 so I am here
> to call for a vote:
>
> Release Notes:
>
> http://people.apache.org/builds/commons/fileupload/1.3/RC1/RELEASE-NOTES.txt
>
> Tag:
>
> https://svn.apache.org/repos/a
On 03/10/2013 08:09 PM, Simone Tripodi wrote:
> Hi Thomas,
>
> thanks a lot for your help, very appreciated! :)
>
>> Critical
>>
>> * FILEUPLOAD-212: after looking more carefully into it I think it is
>>invalid, see the attached test
>>
>
> +1 I'd close it as `not a problem`
>
>> * FILEUP
mainly due to FILEUPLOAD-195 and FILEUPLOAD-228, the current vote is
no longer valid, I'll try to cut a new RC ASAP.
best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sat, Mar 9, 2013 at 2:32 PM,
>> btw. I am unsure about this change, as it now only looks at the
>> Content-Length header. If none is set, the result it -1, but before we
>> were returning request.getContentLength().
>
> as you stated in FILEUPLOAD-179 I agree that "If none is present -1 is
> returned, so I guess it would be be
Hi Thomas,
thanks a lot for your help, very appreciated! :)
> Critical
>
> * FILEUPLOAD-212: after looking more carefully into it I think it is
>invalid, see the attached test
>
+1 I'd close it as `not a problem`
> * FILEUPLOAD-193: as stated in the comments already, this was most
>li
On 03/09/2013 04:02 PM, Simone Tripodi wrote:
>> I do not think its the responsibility of the users that our provided
>> software is bug-free. If they do submit patches, great, if not, somebody
>> has to step in.
>>
>
> I agree, but at least a patch with unit test that proves the issue,
> would ce
> I do not think its the responsibility of the users that our provided
> software is bug-free. If they do submit patches, great, if not, somebody
> has to step in.
>
I agree, but at least a patch with unit test that proves the issue,
would certainly help.
> The more interesting question for me is
On 9 March 2013 14:31, Thomas Neidhart wrote:
> On 03/09/2013 03:23 PM, Simone Tripodi wrote:
>> Hi Thomas,
>>
>> The user proposed a solution - without a patch - that, in his opinion,
>> should work.
>> We do not have a testcase which proves the reported issue, which would
>> affect all past File
On 03/09/2013 03:23 PM, Simone Tripodi wrote:
> Hi Thomas,
>
> The user proposed a solution - without a patch - that, in his opinion,
> should work.
> We do not have a testcase which proves the reported issue, which would
> affect all past FileUpload releases.
>
> So, my question (to everybody) i
Hi Thomas,
The user proposed a solution - without a patch - that, in his opinion,
should work.
We do not have a testcase which proves the reported issue, which would
affect all past FileUpload releases.
So, my question (to everybody) is: could the resolution of that issue
postponed to 1.3.1 or it
On 03/09/2013 02:32 PM, Simone Tripodi wrote:
> Hi all,
>
> I've prepared the RC1 of Apache Commons-FileUpload 1.3 so I am here
> to call for a vote:
>
> Release Notes:
>
> http://people.apache.org/builds/commons/fileupload/1.3/RC1/RELEASE-NOTES.txt
>
> Tag:
>
> https://svn.apache.org/repos/a
My own +1
best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sat, Mar 9, 2013 at 2:32 PM, Simone Tripodi wrote:
> Hi all,
>
> I've prepared the RC1 of Apache Commons-FileUpload 1.3 so I am here
Hi all,
I've prepared the RC1 of Apache Commons-FileUpload 1.3 so I am here
to call for a vote:
Release Notes:
http://people.apache.org/builds/commons/fileupload/1.3/RC1/RELEASE-NOTES.txt
Tag:
https://svn.apache.org/repos/asf/commons/proper/fileupload/tags/FILEUPLOAD_1_3_RC1
Site:
http://pe
19 matches
Mail list logo
