On Apr 1, 2010, at 8:42 PM, Marc Hadley wrote:
> On Apr 1, 2010, at 12:12 PM, Florian Hehlen wrote:
>>
>> Thanks for the feedback. Storing the link as value is interesting
>> since I mainly want to use this for optimization situations where a
>> client wants to know about a large set ids but only a small set of
>> them will ever need to be fully loaded on the client-side.
>>
>> Do you have any clue how I can extend the existing readers and
>> writers so that I do not have to re-write my own? I have peaked
>> inside the jersey library and there are so many providers I am not
>> sure which I should extend.
>>
> Presumably you want to re-use the std JAXB reader/writer for the
> application/ids media type ?
>
> The easiest way to do it is to write your own (mostly empty) reader/
> writer for the application/ids media type and use the Providers
> interface:
>
> https://jsr311.dev.java.net/nonav/releases/1.0/javax/ws/rs/ext/Providers.html
>
> to look up the std reader/writer using "application/xml" for the
> media type. You can then defer to the std reader/writer from your
> reader/writer.
>
Not sure if i am missing something or not, but If one can use
different resource methods annotated with different @Produces (as you
presented below) then why not just use different JAXB classes? and
then there is no need to develop specific or wrapping message body
writers.
Paul.
> Marc.
>
>>
>> -----Original Message-----
>> From: Marc Hadley [mailto:marc.hadley_at_oracle.com]
>> Sent: Thursday, April 01, 2010 4:46 PM
>> To: users_at_jersey.dev.java.net
>> Subject: Re: [Jersey] 2 different xml representation for the same
>> data
>>
>> What you have so far looks fine to me - no media-type abuse detected.
>>
>> You might consider adding links to the representations (e.g. each
>> order could include a link to resource for that order) so clients
>> don't have to construct them.
>>
>> Marc.
>>
>> On Apr 1, 2010, at 8:55 AM, Florian Hehlen wrote:
>>
>>> I have this interesting use case....
>>>
>>>
>>> I would like to be able to retrieve a list of objects or
>>> alternatively just a list of id's. I am thinking that this is just
>>> a different representation of the same data so I would like to use
>>> the same url with different media types.
>>>
>>> So it looks a like this...
>>>
>>> Request 1:
>>> curl http://store/orders/query?state=back-ordered
>>>
>>> reply 1:
>>> <orders>
>>> <order>
>>> <id>1</id>
>>> <state>back-ordered</state>
>>> /* plus all other properties */
>>> </order>
>>> <order>
>>> <id>2</id>
>>> <state>back-ordered</state>
>>> /* plus all other properties */
>>> </order>
>>> </orders>
>>>
>>> Request 2:
>>> curl -s -H Accept:application/ids http://store/orders/query?state=back-ordered
>>>
>>> reply 2:
>>> <pairs>
>>> <pair key="1" value="order" />
>>> <pair key="2" value="order" />
>>> </pairs>
>>>
>>>
>>> Has anyone else been down this path? It feels quite elegant to
>>> want to do it this way. I have written my own MessageBodyWriter
>>> and it works fine. But since both representations are xml I was
>>> hoping to be able to re-use existing jersey providers so I do not
>>> have to write my own serialization/deserialization code.
>>>
>>> At the end of the day I just want to re-direct the calls to
>>> different methods in my resource
>>>
>>> @Path("orders/query")
>>> Public class Resource {
>>>
>>> @GET
>>> @Produces({"application/xml"})
>>> Public Order[] findByState(@QueryParam("state")String state) {
>>> //...
>>> }
>>>
>>> @GET
>>> @Produces({"application/ids"})
>>> Public Pair[] findByStateAsId(@QueryParam("state")String
>>> state) {
>>> //...
>>> }
>>> }
>>>
>>> Am I barking up the wrong tree? Am I abusing media-types?
>>>
>>> Cheers,
>>> Flo.
>>>
>>> The information in this e-mail is intended only for the person or
>>> entity to which it is addressed.
>>>
>>> It may contain confidential and /or privileged material. If
>>> someone other than the intended recipient should receive this e-
>>> mail, he / she shall not be entitled to read, disseminate,
>>> disclose or duplicate it.
>>>
>>> If you receive this e-mail unintentionally, please inform us
>>> immediately by "reply" and then delete it from your system.
>>> Although this information has been compiled with great care,
>>> neither IMC Financial Markets & Asset Management nor any of its
>>> related entities shall accept any responsibility for any errors,
>>> omissions or other inaccuracies in this information or for the
>>> consequences thereof, nor shall it be bound in any way by the
>>> contents of this e-mail or its attachments. In the event of
>>> incomplete or incorrect transmission, please return the e-mail to
>>> the sender and permanently delete this message and any attachments.
>>>
>>> Messages and attachments are scanned for all known viruses. Always
>>> scan attachments before opening them.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>>
>> The information in this e-mail is intended only for the person or
>> entity to which it is addressed.
>>
>> It may contain confidential and /or privileged material. If
>> someone other than the intended recipient should receive this e-
>> mail, he / she shall not be entitled to read, disseminate, disclose
>> or duplicate it.
>>
>> If you receive this e-mail unintentionally, please inform us
>> immediately by "reply" and then delete it from your system.
>> Although this information has been compiled with great care,
>> neither IMC Financial Markets & Asset Management nor any of its
>> related entities shall accept any responsibility for any errors,
>> omissions or other inaccuracies in this information or for the
>> consequences thereof, nor shall it be bound in any way by the
>> contents of this e-mail or its attachments. In the event of
>> incomplete or incorrect transmission, please return the e-mail to
>> the sender and permanently delete this message and any attachments.
>>
>> Messages and attachments are scanned for all known viruses. Always
>> scan attachments before opening them.
>>
>> ---------------------------------------------------------------------
>> 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
>