Marc,
> 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.
> > 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". 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.
> My main concern is that a class written using the JSR 311
> APIs should
> be portable between implementations based on different underlying
> technologies (Servlet, Restlet, ...). I'm not against injecting
> something technology specific for those cases where the class wants
> to do something tchnology-specific but that shouldn't be the norm.
We agreed then, I was not even proposing to be able to inject container
specific information. The use is always able to do it manually if he find it
absolutely necessary, but we shouldn't support/encourage this practice.
> 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.
Best regards,
Jerome