users@jersey.java.net

Re: Collection serialization in RESTful service

From: Florian Rosenberg <florian_at_vitalab.tuwien.ac.at>
Date: Fri, 26 Oct 2007 10:24:40 -0400 (EDT)

hi paul,

On Fri, October 26, 2007 07:19, Paul Sandoz wrote:
> Hi Florian,
>
> Your attachment looks really good.
>
> It should also be possible to implement the readFrom method as a SAX
> filter that push fake start/end document events wrapped around each
> child of the root element and pass this to JAXB unmarshalling.

I guess it should work, I didn't do it in the first place because I had no
need for it, and it was just a quick try. I try to add it at some point
early next week and upload a new version if it works.

> Also not that the current JAXB entity provider supports JSON as well as
> XML, it should be easy to support marshaling, but unmarshaling may be
> tricker (depending on the low-level JSON parsing support).

I'm not sure what you mean. I don't really need JSON support in my
project, so I've not looked into that. So you mean we can serialize the
whole collection as JSON and by writing a custom entity similar to the one
I've uploaded?

> My only main concern Collection<?> is very general and this is specific
> to JAXB, and Collection<?> may make sense in other contexts for other
> Java types.

Agree, that's not the cleanest way, but I could not think of any other
ways except using Collection<?>. I have some check in the "writeTo" to see
if all elements of the collection have the JAXB @XmlRootElement
annotation.

> Perhaps we can include this but not add it by default to the
> javax.ws.rs.ext.EntityProvider file? Thus developers wishing to avail of
> this functionality need to explicitly create the services file.

+1. I'll add the service file to the next version.

Thanks,
-Florian

> Florian Rosenberg wrote:
>> On Tue, October 23, 2007 10:16, Paul Sandoz wrote:
>>> Florian Rosenberg wrote:
>>>>> Some possible solutions:
>>>>>
>>>>> 1) We could provide a Collection type entity provider that checks if
>>>>> all
>>>>> of the objects are JAXB element objects, if so a root element is
>>>>> written out and then each JAXB element is marshalled.
>>>>>
>>>>> 2) A generic collection type class with an entity provider:
>>>>>
>>>>> class CollectionType<T> {
>>>>> Collection<T> c;
>>>>>
>>>>> CollectionType(Collection<T> c) { ... }
>>>>> }
>>>>>
>>>>> The entity provider can then create a JAXBElement instance:
>>>>>
>>>>> QName q = // work out root element name from c
>>>>> new JAXBElement(q, CollectionType.class, c)
>>>> I would go with (1) just for simplicity and it allows the user to
>>>> stick
>>>> to
>>>> his preferred API without used the typed collection.
>>> Right. Since similar classes for 2) i have mentioned will be required
>>> for an implementation of 1) i think i can expose various things out
>>> depending on if developers need simplicity, performance or
>>> configuration
>>> of the root element and for each case don't require to create a
>>> collection class for each entry class.
>>>
>>> https://jersey.dev.java.net/issues/show_bug.cgi?id=18
>>
>> hopefully, I have some time to help on that issues this week...
>>
>>>> when going for (1)
>>>> you need to find a name for the root element, eg., customers if the
>>>> objects in the collection are of type Customer.
>>>>
>>> Yes, same applies for 2). I need some pluralizer code that given a
>>> singular word returns the plural. I suppose i could append an 's', know
>>> of anything better i could use?
>>
>> I send a link as a response to Mark's posting but I don't now how mature
>> it is.
>>
>> appending an "s" as a first draft seems to be fine, but there are a lot
>> of
>> exceptions, e.g., people has both, a plural and singular sense. some
>> other
>> exception are:
>>
>> man -> men
>> thief -> thieves
>> person -> people
>>
>> -Florian
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>
> --
> | ? + ? = To question
> ----------------\
> Paul Sandoz
> x38109
> +33-4-76188109
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>