On Apr 10, 2007, at 1:06 PM, Jerome Louvel wrote:
>
>>> Beside, my suggestion to rely on (iv) in this case, it is also
>>> important to
>>> note that it unlikely that you would want to expose POJOs as
>>> RESTful Web
>>> services if you don't even have control on the source case.
>>
>> There's a difference between the POJO that forms the resource
>> and the
>> class you use for representations. I think its entirely reasonable
>> that the methods of a POJO will work with things like String and
>> InputStream and you can't directly annotate either of those.
>
> Is there some standard way to express annotations using an external
> file
> (like JAXB config files)? Maybe that is something worth suggesting
> to the
> Annotation JSR EG.
>
I'm not aware of any way to do that, I'll investigate.
> Anyway, it is seems reasonable to rely on an annotated wrapper
> resource in
> this case.
>
IMO, it seems better to provide a pre-cooked wrapper like Entity<T>
and Representation<T>.
>>> Note that I consider the usage of JAXB to serialize
>> representations
>>> as an
>>> important use case. But if you autogenerate your POJOs from an XSD
>>> schema,
>>> then it is unlikely that your POJOs will expose media types other
>>> than XML
>>> ones, otherwise you would need to have control on them to generate
>>> them
>>> (JSON for example).
>>
>> That is true but there are many application/*+xml media types and
>> other attributes like language to consider.
>
> Agreed.
>
... and therefore its important to provide a way to specify this
additional metadata. Again, I think the generic wrapper class is a
better solution than requiring developers to define their own wrapper
or subclasses whenever the metadata can't be statically inferred.
>>> I agree that this is an important case to consider. There are
>>> annotation based solution like:
>>>
>>> @Method
>>> public Entry postEntry(@Input InputStream data, @MediaType String
>>> type) {
>>>
>> There's already a general purpose @HeaderParam("Content-Type") that
>> could be used instead of a specific @MediaType annotation.
>
> As explained before, if would prefer to not refer to raw HTTP
> headers by
> directly adress the HTTP semantics/data model.
> The advantage of a @MediaType annotation is that you don't have to
> know the
> exact name of the "Content-Type" header and don't have to know how to
> extract the CharacterSet from textual content types (you would use the
> @CharacterSet annotation). We could also add an annotation parameter
> specifying if the parameters should be injected too (false by
> default).
>
We can define classes and/or annotations for common headers but I
think we also need a general mechanism - I don't want to define an
annotation for every possible HTTP header.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.
- application/pkcs7-signature attachment: smime.p7s