On Sep 8, 2008, at 4:21 PM, Reza Rahman wrote:
> Paul,
>
> I think I am missing something? Why just singleton session beans? Is
> there are a hard requirement for JAX-RS resources to be stateful?
> Why not stateless session beans too? At any rate, how does this
> really differ from Spring/WebBeans component life-cycles? Spring
> singletons are designed for stateless usage (state is shared across
> clients), as is WebBeans request scoped beans?
>
The default life-cycle for resource classes in JAX-RS is per-request.
Jersey's Spring integration supports per-request and singleton for
Spring beans. Jersey also supports per-HTTP-session, which IIRC we
also support with Spring. For those life-cycles it is possible to
utilize a constructor (although for Spring the constructor is limited
to Spring-based annotated parameters).
> I am also not sure what you mean by field injection? EJB 3 supports
> both method and field injection?
The issue is that it is hard for me to integrate that support with EJB
implementations. For example, if i obtain the remote EJB reference
using JNDI the fields are obviously not there for Jersey to operate on
as it only has the interface. Same for constructors. JAX-RS does have
support for bean setters so it is not all that bad.
With JAX-RS classes using Spring it is just a POJO there is no split
between the implementation and the remote/home interfaces, but yet
developers can utilize AOP, transacted methods etc. Jersey can easily
obtain an instance of a Spring bean and still perform it's own
injection on the instances (even for AOP wrapped instances). The
Spring POJO approach fits very nicely with the Jersey POJO approach
both of which IMHO improve the developer ease of use experience.
Further more when using JAX-RS the interface of most importance is the
HTTP interface, thus anything that requires one to split interface
from implementation may be a distraction. In addition i can do
everything in the Web tier, there is no need for an ear file.
> Could you help me understand in what other ways you think session
> beans are less flexible than WebBeans/Spring?
Did the above help?
> I am on the EJB 3.1 EG, so can certainly try to help in this regard
> and would really like to understand the underlying issues. Is it
> difficulty in looking up things from JNDI? If that's the case, EJB
> session bean JNDI names are being standardized so names are portable
> across application servers?
The use of JNDI proved to be really easy :-) i dunno if i am standard
names or not, more details in my next email after i commit the code
(probably in about 10 mins).
Paul.
> Thanks in advance,
> Reza
>
>
> Paul Sandoz wrote:
>> Hi Reza,
>>
>> WebBeans, or say Spring, would give me a way to get full EJB-
>> related functionality without requiring that a resource class be a
>> session bean i.e. it is much more flexible e.g. the life-cycle is
>> not restricted to singletons, it is possible to inject on to
>> fields. I have not looked into EJB Lite yet, so maybe that will
>> improve things. I hope all this can be worked out in the 311 EG
>> when to tackles EE6 integration.
>>
>> W.r.t. session beans being resource classes, i have a working
>> solution. Once the code is committed back i will explain how things
>> work.
>>
>> Paul.
>>
>> On Sep 8, 2008, at 3:29 PM, Reza Rahman wrote:
>>
>>> Paul,
>>>
>>> Good to hear that there is some plans to this end. A few other
>>> Java EE vendors also responded that they intend to integrate EJB 3
>>> and JAX-RS in EJB 3/JAX-WS fashion.
>>>
>>> To me it makes the most sense in the scenario of exposing the back-
>>> end service layer directly instead of getting yet another layer
>>> involved (I'm not sure WebBeans would be use for service tier
>>> implementations). As you mentioned, it wouldn't be too bad in
>>> terms of utilizing the existing EJB services too - like
>>> transaction management, security, asynchronous processing (added
>>> in EJB 3.1) and scheduling (via the older timeouts facility, not
>>> the newer cron-like declarative scheduling). Not all these
>>> services are available directly via WebBeans.
>>>
>>> I think for most EJB 3 users, the CORBA interoperability part is
>>> just a historical curiosity, although I am sure a lot of effort is
>>> spent on this on the vendor end. Luckily, EJB Lite makes CORBA
>>> interoperability optional for vendors (another EJB 3.1 feature).
>>> However, I do see your point about the potential paradigm mismatch
>>> between RPC and REST style code, I just wonder of that's really
>>> enough of a reason not to do it.
>>>
>>> Cheers,
>>> Reza
>>>
>>>
>>> Paul Sandoz wrote:
>>>> Hi Reza,
>>>>
>>>> It would indeed seem odd if JAX-RS would not have such
>>>> functionality. The plan is to produce a maintenance release of
>>>> JAX-RS that aligns with EE 6.
>>>>
>>>> With respect to Jersey you can obtain EE functionality for JAX-RS
>>>> resource classes by using Spring [1]. In fact for EE 6
>>>> integration the current plan is to use WebBeans.
>>>>
>>>> IMHO the use of EJBs defined to be JAX-RS resources may be
>>>> somewhat limited because (session) EJBs are designed for RCP-
>>>> style interactions (CORBA, WS-*) thus resource methods may not
>>>> make any sense in terms of equivalent calls using CORBA. What is
>>>> more interesting is reusing some of the capabilities of EJBs.
>>>> Having said that i think something should be possible, there may
>>>> be two ways:
>>>>
>>>> 1) You can extend the Jersey servlet to register singleton
>>>> instances of annotated EJBs obtain using JNDI lookup.
>>>>
>>>> 2) The Jersey servlet when in an EE environment could perform
>>>> look up of registered classes using JNDI with
>>>> class names as the JNDI names, and if instances exist register
>>>> those as singleton instances.
>>>>
>>>> Paul.
>>>>
>>>> On Sep 7, 2008, at 7:07 PM, Reza Rahman wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I am wondering if there are any concrete plans on supporting JAX-
>>>>> RS annotations on EJB 3 Beans, perhaps as part of project
>>>>> GlassFish? I am looking for something in the flavor that the
>>>>> JBoss implementing RESTEasy, supports in terms of EJB 3/JAX-RS
>>>>> integration? Since such integration already exists between JAX-
>>>>> WS and EJB 3, it seems odd that JAX-RS should not have the same?
>>>>>
>>>>> Thanks in advance,
>>>>> Reza
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>