Hello Jakub,
It's just a small reminder - could you please take a look at the test
code I provided in the last post?
I would like to close my workspace, and don't know if the artifacts are
acceptable :-)
Thanks in advance,
Pedro
On 10/13/2011 06:22 PM, Jakub Podlesak wrote:
> Hi Pedro,
>
> The patch looks good!
>
> I am going to feed it to our internal formal review tool
> and commit to the main trunk afterward.
>
> Some more (one bigger and another minor) things bellow:
>
> 1. I noticed that (and it also applies to FileDataBodyPart class)
> the tests only cover "constructor works fine" stuff.
> Would you be willing to also contribute some more tests to get
> at least the "and also works fine with multipart reader/writer"
> stuff covered?
>
> 2. a minor comment: i suggest to fix the tests where an exception is
> expected from:
>
> try {
> expectedToThrow();
> } catch (ExpectedException e) {
> }
>
> to
>
> try {
> expectedToThrow();
> fail(); // should never get here
> } catch (ExpectedException e) {
> }
>
> but that i will fix by myself, no need to send updated diff for that.
>
>
> And again: many thanks for your contribution!
>
> ~Jakub
>
>
> On 5.10.2011 9:35, Pedro Kowalski wrote:
>> Sure thing Jakub,
>>
>> Will wait for your review.
>> Have a nice time at J1 - I envy you - at least I can read some news
>> from Twitter :-)
>>
>> Cheers!
>>
>>
>> 2011/10/4 Jakub Podlesak <jakub.podlesak_at_oracle.com
>> <mailto:jakub.podlesak_at_oracle.com>>
>>
>> Hi Pedro,
>>
>> Thanks for the patch!
>>
>> I apologize for delayed response. Attending J1 this week.
>> Will try to have a look and get back to you.
>>
>> Thanks,
>>
>> ~Jakub
>>
>>
>> On 29.9.2011 15:34, Palli wrote:
>>> Hi,
>>>
>>> I've attached the patch to the JIRA:
>>> http://java.net/jira/browse/JERSEY-777
>>> It adds the support for sending InputStream as a
>>> multipart/form-data body part entity, which I think is more
>>> adequate and still can be used for byte[] with ByteArrayInputStream.
>>>
>>> Can anyone take a look if it's acceptable?
>>>
>>> Cheers!
>>> Pedro
>>>
>>> On 09/21/2011 07:41 PM, Jakub Podlesak wrote:
>>>> Thanks. Looking forward to your contribution.
>>>> Please keep the list posted if you have any question.
>>>>
>>>> ~Jakub
>>>>
>>>> On 21.9.2011 18:09, Palli wrote:
>>>>> Hi Jakub,
>>>>>
>>>>> Great, there is a JIRA for this enhancement:
>>>>> http://java.net/jira/browse/JERSEY-777
>>>>>
>>>>> As soon as I'll be able I'll take a look at it, as I'm quite
>>>>> fancy getting known Jersey :-)
>>>>>
>>>>> Cheers!
>>>>>
>>>>> Pedro
>>>>>
>>>>> On 09/21/2011 02:46 PM, Jakub Podlesak wrote:
>>>>>> Hi Pedro,
>>>>>>
>>>>>> +1 for the 2. option.
>>>>>>
>>>>>> And yes, contributions are warmly welcome.
>>>>>> Please file a RFE, and attach a patch there.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> ~Jakub
>>>>>>
>>>>>> On 21.9.2011 12:05, pallipp_at_gmail.com
>>>>>> <mailto:pallipp_at_gmail.com> wrote:
>>>>>>> Howdy!
>>>>>>>
>>>>>>> I think it would be nice if we could have an additional
>>>>>>> support for
>>>>>>> byte[] instead of just flat File objects in
>>>>>>> FormDataBodyPart. I think
>>>>>>> there are situations in which we don't need to hit the disk
>>>>>>> before
>>>>>>> sending the data through the wire (or do we?)
>>>>>>>
>>>>>>> According to the javadoc [1] there is only a File object
>>>>>>> support.
>>>>>>>
>>>>>>> If you agree that such feature is acceptable, than I think
>>>>>>> that either:
>>>>>>> 1. The FileDataBodyPart should be adjusted to support byte[]
>>>>>>> or,
>>>>>>> 2. Another subclass of FormDataBodyPart should be created
>>>>>>> which will
>>>>>>> support the byte[].
>>>>>>>
>>>>>>> Personally, I'd prefer the 2. option.
>>>>>>>
>>>>>>> What do you think about that?
>>>>>>> Are you open for contributions?
>>>>>>>
>>>>>>> The idea for this feature was born in Arquillian project [2].
>>>>>>>
>>>>>>> Cheers!
>>>>>>>
>>>>>>> Pedro
>>>>>>>
>>>>>>> [1] -
>>>>>>> http://jersey.java.net/nonav/apidocs/1.9.1/contribs/jersey-multipart/co
>>>>>>>
>>>>>>> m/sun/jersey/multipart/file/FileDataBodyPart.html
>>>>>>> [2] - https://issues.jboss.org/browse/ARQ-569
>>>>>>>
>>>>>
>>>>>
>>>
>>