dev@jsr311.java.net

RE: 3 solutions or 1 solution <was> Re: Redirection and creation <was> Re: Container Independence

From: Jerome Louvel <jerome.louvel_at_noelios.com>
Date: Wed, 18 Apr 2007 14:30:30 +0200

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
>