Sounds good thanks for the effort. It might be related to some other
issues I have. I will make a new post for that. Registering the
FormData provider works, thanks for that.
Patrick.
On Aug 25, 2010, at 12:55 PM, Paul Sandoz wrote:
> Hi Patrick/Stefan,
>
> Ah! It makes sense now and i can reproduce (the unit tests did not
> fail because of the precedence you point out). Drat. This is a
> regression introduced in an effort to improve error reporting.
> Though i cannot explain Stefan's case where one annotated parameter
> works.
>
> In this case errors are prematurely registered when processing the
> resource methods. We need to somehow stash errors temporarily and
> refer to them later if necessary.
>
> A work around is to explicitly register the class:
>
> com.sun.jersey.multipart.impl.FormDataMultiPartDispatchProvider
>
> with the resource config.
>
> I will try and fix for 1.4:
>
> https://jersey.dev.java.net/issues/show_bug.cgi?id=575
>
> Paul.
>
> On Aug 25, 2010, at 12:00 PM, Patrick Duin wrote:
>
>> Hi,
>>
>> I am new but I am experiencing similar problems. The @FormDataParam
>> are reported as missing dependencies. It seems to be related to the
>> order in which the multipart jar is loaded in the classpath, if I
>> run a test in eclipse where I set the multipart jar to load after
>> the jersey-core/jersey-server jars I get the error. If I set it to
>> load before the jars it works fine, when I deploy my app in tomcat
>> I get the error again. I stumbled into this when migrating from
>> jersey 1.1.5 to 1.3.
>>
>> I hope this helps.
>>
>> Kind regards,
>> Patrick.
>>
>> On Aug 25, 2010, at 11:14 AM, Stefan Heinz wrote:
>>
>>> Hi!
>>> I switched to a workaround using @FormDataParam("file")
>>> FormDataBodyPart bodyPart and then
>>> FormDataContentDisposition contentDisp =
>>> bodyPart.getFormDataContentDisposition(); and InputStream in =
>>> bodyPart.getValueAs(InputStream.class);. This approach also works
>>> in the unit tests (also I switched a second time to @Context
>>> HttpServletRequest using Apache Commons FileUpload). Still haven't
>>> found out the reason for the problem. All Jersey modules have
>>> version 1.3 and I also tried switching all to 1.4-ea5 with the
>>> same result (I had a maven property in place to try this, so all
>>> modules should have the same version number).
>>>
>>> Nevertheless, thank you for the response.
>>>
>>> Regards,
>>> Stefan
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>