On Tue, 2009-05-12 at 18:08 +0200, Paul Sandoz wrote:
> On May 12, 2009, at 5:45 PM, Paul C. Bryan wrote:
>
> > Right, as it's serialized. I don't see a way to get the entity in its
> > encoded form when in the handle() method.
> >
> > So, I could assume the entity is a MultivaluedMap, which I think the
> > majority of the time, it will be when it's POST
> > application/x-www-form-urlencoded. But it could be other types, up to
> > the caller of the client library, correct? For example, String
> > (pre-encoded) seems to work if I pass that in as the entity to the
> > client library.
> >
> > What I'm trying to do: I want to get the entity body to extract form
> > parameters, in order to calculate a digital signature.
> >
>
> > I considered just assuming it's MultivaluedMap, and throwing exception
> > otherwise, but was hoping there could be a way I could get the encoded
> > entity (which I would then decode) to allow virtually any object
> > type to
> > be provided -- flexibility.
> >
>
> Why do you need to decode it?
I need the name-value pairs of parameters. Again, this is easy if it's a
MultivaluedMap -- and I think for this case, which I expect to occur the
majority of the time, I should just consume the values from the
MultivaluedMap.
I'm trying to cover the edge case where it's not MultivaluedMap. In such
a case, I'll need to decode the name-value pairs from the entity, so
that I can use them to sign the request in a header.
>
> You can perform such an operation in a ClientRequestAdapter. Your
> filter can add the adapter. Essentially the adapter defers processing
> until the Jersey client is ready to serialize the entity. Your adapter
> could buffer the request entity by adapting the output stream, on
> closing of the stream additional headers can be set and then the
> buffered entity can then be written to the output stream that was
> passed to the adapt method.
1. Could be bad if the entity is large because now there will be at
least two copies of it.
2. I didn't know it was safe for the adapter to modify the request when
it's triggered. This would be sanctioned behaviour?
>
> The alternative is to use the Providers interface on Client to obtain
> a message body writer to serialize out the request entity
> independently. That might be the easiest approach for you. See the
> following thread for more details, which should work generically for
> any type.
>
> http://markmail.org/search/?q=list
> %3Anet.java.dev.jersey.users#query:list%3Anet.java.dev.jersey.users
> +page:1+mid:boxdj4k6vshgzjqd+state:results
This approach sounds better. I think I'll dig into this case. Thanks.
>
> Paul.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>