Re: JSR311: Feedback from W-JAX presentation

From: Ryan McDonough <>
Date: Wed, 7 Nov 2007 09:18:16 -0500

I think it would be counter intuitive to have to apply a

Be more explicit in the EJB integration section of the specification.
Define exactly what of the spec fits with EJB, give suggestions for how
JSR-311 should be integrated with EJB. IMO, there's no reason it should
be any different than exposing a JAX-WS service on a SLSB.

On 11/7/07, Paul Sandoz <> wrote:
> Heiko Braun wrote:
> >> - In general, pretty much everybody liked the overall approach
> >> - Some people were concerned about how to integrate this with their
> >> existing, EJB 3-based architectures, esp. regarding the SessionBean-
> >> based layer they're currently exposing as SOAP web services. I don't
> >> believe there's any easy way because of the architectural differences
> >
> >
> > It shouldn't be too hard. I think Ryan is working on that
> > and I am looking at it myself. One of the things that appeared to me,
> > is that we need to get rid of the ctor based injection, which the spec
> > enforces on root resources.
> We need to clarify this, the intent is that per-request life-cycle scope
> is the *default* but not the only way. It can be overridden with
> per-application (equivalent to the life-cycle scope of stateless session
> beans). The RI has experimental support (as Marc referenced in a reply
> to Ryan IIRC) for those wishing to experiment with life-cycle and
> resource management to see how we could improve things in the JAX-RS API.

 We did did discuss this and I like where the life cycle feature is going.
Marc's API would pave the way for EJB3 and even Spring components to be
exposed as RESTful end points. However, my only concern is that we may end
up creating custom annotations for each lifecycle type which could lead to
portability issues down the road. As I look at this more, I think we need to
find a way to make expose these different lifecycle to developers

We definitely need to clarify the integration with session beans, and in
> general for EE integration. I think that is possible without the session
> bean life-cycle becoming the default for those that don't want to use it
> and vice versa. Potentially WebBeans may be able to help here.

Absolutely agreed, we definitely need to be more specific in terms of EJB3
integration. A lot of folks are looking to see JAX-RS do for REST what
JAX-WS did for SOAP-based web services for EJBs. EJB integration different
than exposing a JAX-WS service on a SLSB. I think defining a means to
accommodate different lifecyles in the spec if a good idea. I anticipate
that a lot of folks will be deploying JAX-RS in a Java EE container, so I'd
recommend that as part of the spec, we clearly define what parts of the spec
will fit with EJB3. From a syntax perspective, it should not be a dramatic
departure from using a POJO. For exmaple, an SLSB should be as simple as:

public class PeopleServiceBean {

    public Person getPersonById(@UriParam("id") String id) {...

This way the developer doesn't have to explicitly add another annotation
declaring that this resource must use the EJB lifecycle. This is a bit more
inline with how JAX-WS works.

A per-request life-cycle model with constructors makes for a very
> natural, simple and dry way to program resources (IIRC a per-request
> life-cycle scope is the same for Rails, Django and Restlet). I have used
> it many times to good effect in the Jersey examples, no need to worry
> about state/threads, no need to repeat myself for common URI/Query
> parameters, easy to check for existence of something and throw an 404
> exception. IMHO it lowers the barrier of entry for efficiently and
> correctly developing RESTful Web applications.

You lost me with the 404 example and query params example :) I don't see how
an EJB3 would be any different? Perhaps my head with some the this is still
working with the idea of exposing Java methods to return different
representations rather than in terms of the resource itself.

> > This makes it hard to leverage other
> > container semantics. Furthermore we may think of allowing 311 annotation
> > on interfaces as Bill already suggested.
> >
> >
> >> - Somebody had written something similar (annotation-based REST API)
> >> themselves; I'm trying to get them to take a closer look and provide
> >> some feedback. One of the things they did differently was to annotate
> >> the methods with the "TypeConverter" (which is similar to
> >> EntityProvider) to be used.
> >>
> >> Based on this last feedback, I'd like to discuss two issues:
> >>
> >> - Maybe "EntityProvider" should be named different. I'm aware that
> >> "entity" is the correct term from an HTTP perspective (although to be
> >> exact, I think it would have be "entity body" in this context), but
> >> from a Java perspective it's a little unexpected.
> >
> > +1
> > 'Entity' is a subject widely used in J2EE, EE and persistence frameworks
> > in general. I totally agree, it's confusing.
> > Why not call it marshaller/unmarshaller? Or serialzer/deserialzer?
> >
> >> - Maybe there should be a way to override the EntityProvider selection
> >> based on an annotation on a method. The one case where I believe this
> >> could be useful is when a MIME type such as "application/xml" is used
> >> - e.g. the JAXB EntityProvider could handle the default, while some
> >> specific cases would be overridden.
> >>
> >> Stefan
> >> --
> >> Stefan Tilkov,
> >>
> >> [1]
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail:
> >> For additional commands, e-mail:
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> >
> --
> | ? + ? = To question
> ----------------\
> Paul Sandoz
> x38109
> +33-4-76188109
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Ryan J. McDonough