Marc Hadley wrote:
> On Jan 8, 2008, at 12:15 PM, Bill Burke wrote:
>>> I think it depends on where you intend to put the
>>> serialization/deserialization logic. Using MessageBodyReaders and
>>> MessageBodyWriters you can have the same datatype being serialized
>>> to/from a variety of formats while only using a single resource
>>> class. E.g.:
>>> @Path("foo")
>>> public class FooResource {
>>> @GET
>>> FooData getData() {...}
>>> }
>>> FooData is the Java bean you work with in your code and is the only
>>> type understood directly by the resource. You can then have
>>> MessageBodyWriters for a variety or formats without duplicating the
>>> resource logic in additional resource classes.
>>
>> You have a good point, but that doesn't mean this way of designing
>> resources would cause resource logic duplication.
>> Inheritance/delegation can take care of that.
>>
> Yes, that's true.
>
>> Still, in my particular use case, MessageBodyReaders/Writers aren't a
>> good enough abstraction for what I'm doing as I'm not working with an
>> object model, but just raw metadata.
>>
> Can you say a little more about why MBR/MBW isn't suitable. Is there
> something we could do to improve those interfaces that would make them
> workable for you ? Can you describe the use-case in more detail ?
>
I'm working with Hibernate's raw Map mode and XML mode. The Map format
is for JSON and I need to massage the raw Map format returned from
Hibernate before I can serialize it to JSON. The XML mode returns a
Dom4j document. I'd rather have these things in separate classes.
So, you see I'm not working with an object model, just rawness.
>> I just don't see what the big deal is of supporting multiple
>> resources/different media types, same path.
>>
> I guess it just makes the matching algorithm a bit more complex.
>
Depends on how you implement it I guess...
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com