Paul,
I do shape often, but I'm really not looking at this from the same point of
view. I assume that we don't want to impose any particular POJO design while
you want to enforce one and only one solution.
I really don't see what is wrong with these two annotations. It's like
saying that your approach is wrong because you can either return an instance
of HttpResponse and set the status to 307, or return an instance of
TemporaryRedirect...
Best regards,
Jerome
> -----Message d'origine-----
> De : Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
> Envoyé : lundi 16 avril 2007 12:18
> À : dev_at_jsr311.dev.java.net
> Objet : Re: 3 solutions or 1 solution <was> Re: Redirection
> and creation <was> Re: Container Independence
>
> Hi Jerome,
>
> Jerome Louvel wrote:
> > I would present it differently: with the annotation
> @RedirectionRef and the
> > more general @WebContext one, I can solve the following
> redirection use
> > cases:
> > - the redirection URI is dynamically produce with a POJO method
> > - the redirection can be expressed as a static URI template
> > - the redirection must be manually handled inside a
> processing method
> >
> > I'm not proposing three ways of handling redirections,
>
> The developer has *three* different solutions to choose from. That is
> what concerns me most. Although i don't shave as often as
> someone very
> close to me would like :-) i am applying Occam's razor in
> this respect.
>
>
> > I'm proposing two
> > complimentary tools to solve all redirection use cases,
> including the one
> > illustrated above.
> >
>
> I am trying to illustrate, in this case, that using Java annotations
> introduces more complexity for the developer than just using a Java
> class or a Java method. So we really need to justify whether the
> annotation is warranted.
>
> There are clear cases where annotations offer a significant advantage
> over using Java classes/methods. The HttpMethod/UriTemplate
> Consume/Produce or WebMethod/WebResource/Input/Output do offer such
> advantages that would otherwise require configuration
> classes/methods or
> deployment descriptors where, in either case, information is
> distributed
> and repeated. I don't see such a clear case for
> @RedirectionRef in this
> respect.
>
> Perhaps you could provide some 'real-world' examples for this
> case using
> annotations and contrasting with using a Java method/class?
> Then we can
> better judge whether the annotations offer a significant
> advantage over
> the use of a Java class/method.
>
> Paul.
>
>
> > Best regards,
> > Jerome
> >
> >> -----Message d'origine-----
> >> De : Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
> >> Envoyé : jeudi 12 avril 2007 23:11
> >> À : dev_at_jsr311.dev.java.net
> >> Objet : 3 solutions or 1 solution <was> Re: Redirection and
> >> creation <was> Re: Container Independence
> >>
> >> Hi Jerome,
> >>
> >> I will try once more to get my point across.
> >>
> >> You are proposing 3 different solutions to solve the redirect use-
> >> case. I am proposing 1 solution *.
> >>
> >> We need to have some really compelling use-cases to justify the
> >> increased complexity and triplication your solutions introduce.
> >>
> >> Paul.
> >>
> >> * debates about the number of classes vs. annotations and method
> >> signature constraints are just red herrings. Each can use
> a similar
> >> number of classes or annotations and each imposes
> constraints on the
> >> return type of the method signatures. There are minor
> >> differences and
> >> we don't need to quibble about them.
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> >> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
> >>
> >
> >
> ---------------------------------------------------------------------
> > 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
>