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