Hi Paul,
If the developer as some freedom to modify and adapt the design of his POJOs
to the JSR API, then your approach (or something similar) is probably the
best.
I am concerned with cases where this may not be the case. As you suggest, I
should come up with compelling use cases. Let me think more about this and
come back to you later.
Best regards,
Jerome
> -----Message d'origine-----
> De : Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
> Envoyé : mardi 17 avril 2007 13:20
> À : dev_at_jsr311.dev.java.net
> Objet : Re: 3 solutions or 1 solution <was> Re: Redirection
> and creation <was> Re: Container Independence
>
> Jerome Louvel wrote:
> > 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.
> >
>
> Yes, one very simple constraint:
>
> "Return an instance of the TemporaryRedirect class to respond to a
> request with a 307 (Temporary Redirect) response that contains a
> Location header field."
>
>
> Any use of an API will result in constraints on design. The use of
> annotations are no different in this respect, they impose on
> design too
> in their own particular ways (e.g. constraints on method
> signatures and
> method requirements, static declaration vs. runtime
> declaration, runtime
> vs. compile time errors, runtime vs. compile time type checking,
> creation of new classes that wrap, quite a few of edge cases, more
> documentation).
>
> It would be most helpful if you could provide some 'real-world'
> use-cases for redirection showing that the use of annotations as you
> propose do not impose any particular POJO design (perhaps taking some
> existing code e.g. from Java blueprints or EE 5 examples?).
> Then we can
> judge better whether such use-cases are important.
>
>
> Does the following:
>
> @HttpMethod
> TemporaryRedirect get() { return new TemporaryRedirect("..."); )
>
> or:
>
> static final TemporaryRedirect TR =
> new TemporaryRedirect("...");
>
> @HttpMethod
> TemporaryRedirect get() { return TR; }
>
> or:
>
> static final String TR = "...";
>
> @HttpMethod
> TemporaryRedirect get() { return new TemporaryRedirect(TR); }
>
> or:
>
> private String getRedirectedUri() { ... }
>
> @HttpMethod
> TemporaryRedirect get() {
> return new TemporaryRedirect(getRedirectedUri());
> }
>
> or:
>
> @HttpMethod
> Object get() {
> if (redirect required)
> return new TemporaryRedirect("...");
> else
> return new T();
> }
>
>
> impose on POJO design to the extent that additional annotation-based
> solutions are required?
>
>
> > I really don't see what is wrong with these two annotations.
>
> Because it introduces additional complexity for the developer, and we
> need to justify that additional complexity with good
> use-cases that show
> it is impossible, or difficult, or too imposing, to support by the
> returning of a Java class.
>
>
> > 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...
> >
>
> Respectfully, i think you have missed my point. We do not
> need to tell
> developers how to use the "low-level escape hatch". We can tell
> developers *the* (80%) solution to support temporary
> redirection is to:
>
> "Return an instance of the TemporaryRedirect class to respond to a
> request with a 307 (Temporary Redirect) response that contains a
> Location header field."
>
> That is it! Simple, precise and concise.
>
> Paul.
>
> > 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
> >>
> >
> >
> ---------------------------------------------------------------------
> > 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
>