On 4/12/07, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>
> Jerome Louvel wrote:
> >> I know you want to avoid classes/interfaces but in this case I think
> >> they really simplify things.
> >
> > Here is something that I have in mind:
> >
> > @WebResource("/orders/{orderId}")
> > public Order {
> >
> > @WebMethod
> > @RedirectionRef("/target/{orderId}")
> > public void post(InputStream data) {
> > ...
> > }
> > }
> >
<snip>
I think this is an improvement over your previous thoughts on having:
>
> @CreationRef
> public String getIdentifier() {...}
>
> which IMHO introduces much more complexity than annotating the HTTP
> method.
>
> The idea of using a URI template is a nice touch. Also I also find
> rather appealing the renaming of UriTemplate and HttpMethod to
> WebResource (i consider the issue with the WebResource interface as
> separate thing) and WebMethod respectively.
I dont think this is wise as @WebMethod is a jws annotation used to expose
EJB methods via WSDL-style webservices.
Neat as it reads, I believe it is too general--not only risking conflicts
with other apis but purporting to be too much (a la RTF/ASF's objection to
the use of "rest").
A more specific naming scheme would serve better:
@RSMethod
@RSName("/target/{id}")
> > @Resource
> > Context ctx;
>
> 'ctx' would need to be a field on the class or a parameter of the method
> for standard injection to work. (we could do some byte code injection
> :-) but that is tricky!)
I would be wary of supporting @Resource without having a full understanding
of various deployment targets.
In EE containers for instance you will need to search jndi for a resource
named "ctx" (which may have nothing to do with the current Context) and
potentially support other things like auth semantics (or risk confusing the
end-user if you dont).
If we're using it simply to mark an injection point for the Context
artifact, I'd suggest a custom annotation. Leveraging @Resource can open the
door to a whole lot of stuff to consider (or to ignore as the case may be),
which can make life tough for an end user.
The other common annotations (@PostConstruct, @PreDestroy) also drag us into
the world of application containers. Their canonical uses (EJBs, JSF beans)
have clearly defined ideas of scope and lifecycle. Do we have (and do we
want to) this as a separate discussion?
> How are the two approaches above simpler than having just one solution
> to solve the problem, namely the returning of a Java object (as Marc has
> previously shown):
>
> return new PermanentRedirect("/target/{orderId}");
I like this one too. And the use of a static factory makes this easy to
read:
return Redirect.to("/target/...");
Dhanji.