On Apr 10, 2007, at 4:17 AM, Jerome Louvel wrote:
>
>> I don't follow what you are proposing on the response side,
>> could you give an example of what you mean ? E.g. how would
>> you propose that a JSR 311 resource class issue a redirect ?
>
> In most of the cases, the status can be automatically guessed by the
> container. For example if it detects that the last modification
> date hasn't
> changed since the last retrieval, it can return a 304. It can also
> check
> many preconditions and return a 412 status if necessary.
>
> The case of redirections is a special, but important, one. One way
> to solve
> it could be to have the following annotations
>
> @Status
> int getStatus();
>
> and
>
> @RedirectRef
> URI getRedirection();
>
> If the first method/annotation isn't present, we could also
> generated a 303
> or 307 status. If the getRedirection() method returns null, then no
> redirection reference should be set in the response.
>
That means a developer now has to model all the details of a HTTP
response in their resource (POJO) classes. Earlier you had objected
strongly to any need for the resource POJOs to be changed to use the
API beyond adding a few annotations, this sort of approach requires
many new methods and a detailed algorithm describing how a container
generates a response based on the values returned by those methods.
I'd worry that whatever we did we'd miss use cases and end up with
something lacking in sufficient flexibility.
>>> I'm not proposing that the Resources have any knowledge on
>> the parent
>>> container. The code based on JSR311 should be dependent on the
>>> Servlet API
>>> or on the Restlet API.
>>
>> Hmm, I could read that one of two ways. Either "code based on JSR
>> 311" means the runtime code supporting an application built
>> using the
>> JSR 311 APIs -- or -- you mean something other than Servlet,
>> Restlet,
>> etc when you write "parent container".
>
> When I mean "parent container", I mean either a JAX-WS
> implementation, or a
> Servlet container or a Restlet container or a Spring container, etc.
> However, there was a typo in my reply, I meant "independent"
> instead of
> "dependent".
OK.
> The user code annotated with JSR311 should have any direct
> dependency on the parent container (whatever it is), it should be
> necessary.
> All the useful context info should be injected in the annotated POJOs
> instead.
>
s/should/shouldn't (for the first two should in the above) - right ?
>
>> Right, you could easily extract the uriPattern value from the
>> @UriTemplate annotation and generate the required attach methods
>> using apt. Alternatively you could just have a
>>
>> attach(Class targetClass)
>>
>> that extracts the UriTemplate value using reflection.
>
> Agreed, we should support both attachments. The same Resource POJO
> might be
> attached to different applications or at different paths, so it
> should also
> be possible to override the default @UriTemplate annotation value,
> or even
> not specify it at all. BTW, I would prefer @ParentRef or something
> else
> instead of @UriTemplate as the "template" suffix suggest that it
> must be an
> URI template, when it can very well be a static URI reference. But
> this is a
> minor point.
>
I don't like ParentRef, its not a reference to a parent. A uri
template doesn't have to have any template variables, it can just be
static.
I guess we could go for something like @Resource
(id="someuritemplate") instead.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.
- application/pkcs7-signature attachment: smime.p7s