On 09.03.2011, at 20:21, Markus KARG wrote:
>>> 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". ;-)
O.k. then you will have to lookup the EJBs in a POJO. It works already - you are right.
>
>> 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?
Or a local invocation of the EJB. Whether it is an EJB or CDI managed bean, it doesn't matter. A managed object needs to get a reference to the current JAX-RS context (PathParam). Otherwise you will have to instantiate the object by yourself. Then it won't be managed and DI will not work...
>
>>>>>> @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
>
>