> > The problem is that he wants to inject information about the sub
> resource into the creation of the EJB.
> And this is a huge problem. It happens in every non-trivial
> application.
Well, our application is far from being trivial but the problem does not
happen in ours. We just use a JAX-RS front door internally calling into EJB
3 SLSBs which works pretty well and is rather simple to do. So "all" should
be replaced by "many". ;-)
> The simplest possible solution would be something like:
> @Stateless
> public SubResource{
> @PathParam
> long id;
> }
> or the injection of a more generic "JAX-RS" context into EJB / CDI
> bean.
So to sum up, what you're actually like to have is using a JAX-RS resource
as a SLSB, so whenever a JAX-RS method is invoked, it should be treated just
as if it would be an remote invocation of the SLSB, right?
> >>>> @EJB SB sb;
> >>>> @GET @Path("{pk}")
> >>>> public SB getSb(@PathParam("pk") T pk) {
> >>>> sb.setPk(pk);
> >>>> return sb;
> >>>> }
> >>> It doesn't work - you cannot maintain client-specific state in a
> Stateless Session bean. You will need to pass the context in different
> way.
That code snippet is not using any client-specific state since the PK is a
transitive object. So obviously it would work, besides the fact that the
returned SB will be treated as a POJO on the other side, not as an EJB
anymore (which obviously is what you want to get if I assume correctly).
> >>> Passing parameters from JAX-RS to stateless session beans as sub-
> resource locators is the problem. It happens in all non-trivial
> applications.
> >>> You could use POJOs, but then you will need another transactional
> layer or implement transactions buy yourself..
Still don't see a *problem* as we are calling SLBS from JAX-RS all day and
pass lots of params. :-(
Regards
Markus