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.
>
> 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
> <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
> <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
> <http://n2.nabble.com/jersey-multipart-throwing-NPE-tp1560622p1560664.html>
> Sent from the Jersey mailing list archive
> <http://n2.nabble.com/Jersey-f576304.html> at Nabble.com.