dev@jsr311.java.net

RE: Container Independence

From: Jerome Louvel <jerome.louvel_at_noelios.com>
Date: Tue, 10 Apr 2007 18:03:58 +0200

Marc,

> > @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.

In most cases, those annotations won't be necessary as the default status
will work fine and there won't be any redirection.

> 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.

There might be better ways to express this. We could express static
redirections simply using annotations, like for resource URIs. Also the
custom status could be directly returned by post() methods:

@Resource
public MyResource {
   ...

   @Redirect("/target/{var}")
   public @Status int post(InputStream data) {
      ...
   }
}

I came up with these ideas pretty quickly. Maybe we should step back a
little and see how those rough edges should be best polished. Are some
questions I have in mind:

 - How would someone writing domain POJOs (with no knowledge of JSR 311 API)
would express redirections and custom HTTP status?
 - Would he even express them the way we think of them (HTTP centric)?
 - How can we compensate for the lack of expression for redirections and
custom status for existing POJOs that we want to expose as resources?

Probably the final solution will be a mix on several design paths, but I'm
sure it is worth exploring as many of them before committing to a final
design.

> > 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 ?

Sorry, here is the decoded version :)

"The user code annotated with JSR311 shouldn't have any direct dependency on
the parent container (whatever it is), it shouldn't even be necessary. All
the useful context info should be injected in the annotated POJOs instead."

> 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.

Agreed. @Resource("someUriTemplate") would be even simpler, with the option
to specify @Resource(id="someUriTemplate", otherParam="xxx") if necessary.

Best regards,
Jerome