On Nov 21, 2008, at 7:56 AM, Craig McClanahan wrote:
> Gili wrote:
>>
>>
>> I suspect what is going on is that I'm using Jersey 1.0
>> that ships with
>> Netbeans and your code is assuming 1.0.1-snapshot. I will now upgrade
>> across the board to 1.0.1 and maybe the client configuration might
>> even
>> work out-of-the-box.
> Possibly -- I don't know if that issue got addressed ... we'll need
> Paul to address that quesiton.
I am going to modify things so that the providers are registered via
META-INF/services and then there is no need for the developer to do
any registration, except for including the jar in the classpath.
Paul.
>
>>
>> While I am in the process of getting all of this working
>> can you please
>> explain to me BodyPart.getParameterizedHeaders()? I was expecting
>> to be
>> able to do
>> BodyPart.getParameterizedHeaders().get("Content-
>> Disposition").get("name");
>> Instead I see that you are returning a List of
>> ParameterizedHeaders. Why
>> is that?
> For *all* HTTP headers, it is legal to have multiple values for the
> same header, so a general purpose API has to support that option.
> For the simple case where you know there is only one value (or for
> where you don't care about anything other than the first value), try
> this:
>
> bodyPart.getParameterizedHeaders().getFirst("Content-
> Disposition").get("name");
>
>>
>> Thanks,
>> Gili
> Craig
>
>>
>> Craig McClanahan (via Nabble) wrote:
>>
>> > Gili wrote:
>> > > It turns out this is caused by the fact that "@Context
>> MultiPartConfig
>> > > config" in the constructor returns null. The thing is, the
>> Javadoc
>> > doesn't
>> > > explain if I'm supposed to provide some sort of configuration
>> and if
>> > so how
>> > > to do it. I could really use your help ;)
>> > >
>> > >
>> > Yep, that is definitely the root cause. I just added an error
>> message
>> > to the constructor of MultiPartReader that will complain (the
>> first time
>> > this class is instantiated) if the config bean cannot be found.
>> (+1 to
>> > maximally helpful exception messages.)
>> >
>> > This should *never* happen on the server side unless you have done
>> > something really strange with the Jersey configuration
>> parameters. On
>> > the client side, as we've discusssed, you need to explicitly
>> register
>> > the provider class.
>> >
>> > Note that there has been a package rename recently in this as
>> well as
>> > many other areas ... but if you had initialized the client as
>> indicated
>> > in your earlier email:
>> >
>> > config.getClasses().add(MultiPartConfigProvider.class);
>> >
>> > you would have gotten a compile error if you didn't update your
>> import
>> > statement. So I suspect that this error is happening on the client
>> > side, and that you haven't registered this particular provider.
>> >
>> > Try the latest jersey-multipart code with no other changes, and you
>> > should receive an IllegalArgumentException that discusses the
>> root cause
>> > more clearly.
>> >
>> > > BTW, I see
>> "com.sun.jersey.multipart.impl.MultiPartConfigProvider" being
>> > > loaded by Jersey on startup so I am expecting this to work...
>> > >
>> > >
>> > Could you cut-n-paste the system out log that shows this?
>> > > Thanks,
>> > > Gili
>> > >
>> > >
>> > Craig
>> >
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@...
>> > <http://n2.nabble.com/user/SendEmail.jtp?
>> type=node&node=1560658&i=0>
>> > For additional commands, e-mail: users-help@...
>> > <http://n2.nabble.com/user/SendEmail.jtp?
>> type=node&node=1560658&i=1>
>> >
>> >
>> >
>> >
>> ------------------------------------------------------------------------
>> > This email is a reply to your post @
>> > http://n2.nabble.com/jersey-multipart-throwing-NPE-tp1560622p1560658.html
>> > You can reply by email or by visting the link above.
>> >
>>
>> View this message in context: Re: [Jersey] jersey-multipart
>> throwing NPE
>> Sent from the Jersey mailing list archive at Nabble.com.
>