dev@jsr311.java.net

RE: Issue 1: Adding additional conneg metadata to _at_Produce/ConsumeXXX

From: Jerome Louvel <jerome.louvel_at_noelios.com>
Date: Mon, 25 Jun 2007 22:37:20 +0200

Hi Paul,

If annotations on Representation POJOs don't make sense (I don't remember
the exact reasons anymore... hence the interest in the Wiki, issue tracker),
then maybe the POJO to Representation conversion service could help here.

As a result, the developer wouldn't even need the "isAcceptable" mechanism.

Best regards,
Jerome

> -----Message d'origine-----
> De : Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
> Envoyé : lundi 25 juin 2007 16:05
> À : dev_at_jsr311.dev.java.net
> Objet : Re: Issue 1: Adding additional conneg metadata to
> @Produce/ConsumeXXX
>
> Hi Jerome,
>
> We already have the Response.(Builder) mechanism to return meta data
> plus an entity. So I don't see the need to provide such
> annotations on a
> Java class that is representation (plus there are issues with this we
> have discussed at length before).
>
> The key bit i see that is missing is how the developer can ascertain
> what is acceptable and to signal when something is not
> acceptable. That
> is what i was proposing via some helper methods.
>
> if (x.isAcceptable(..., ..., ...)) {
> } else if x.isAcceptable(...)) {
> } else { return null; }
>
> The developer could do things dynamically via their own Response
> implementation or they could use the Response.Builder.
>
> Paul.
>
>
> Jerome Louvel wrote:
> > Hi Paul,
> >
> >> Agreed, we can do that now with Produce*. But, the cases i am
> >> trying to
> >> highlight are when what is acceptable cannot be determined
> statically:
> >>
> >> 1) a method is declared to produce more than one acceptable
> >> thing, for
> >> example "image/*" but only certain image formats are
> supported, the
> >> number of which grows over time; and
> >
> > In this case, we need a @MediaType annotation on the
> representation class
> > itself, indicating the method that exposes the media type
> dynamically.
> >
> >> 2) if we choose not to do non-declarative negotiation on certain
> >> acceptable information, such as language (i suspect that
> for language
> >> the common case is to grow the number of supported languages
> >> over time
> >> without changing existing networking every time a new
> >> language is added).
> >
> > The same @Language annotation approach could works equally
> well for dynamic
> > scenarios.
> >
> > Best regards,
> > Jerome
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> > For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
> >
>
> --
> | ? + ? = To question
> ----------------\
> Paul Sandoz
> x38109
> +33-4-76188109
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>