JAXRS EJBInvoker

[Ryan Zoerner <ry...@gmail.com>]

It has been a while since I have written to the dev list, but I am working
on putting an JAXRSEJBInvoker together. The naive implementation (in this
case, that means rough draft), consists of taking JAXRSInvoker, replacing
all instances of that word with EJBInvoker, extending AbstractInvoker, and
adding in the code from the EJBInvoker found in geronimo. The main key
difference between JAXWSInvoker and EJBInvoker is that EJBInvoker hands
actual invocation responsibilities off to the EJB container instead of to
java method reflection. For the invoke method with 4 params, in
AbstractInvoker, the method can be directly replaced by the methods in
EJBInvoker. The only place where an actual invocation call is made is in
that method. The entire method is devoted to getting ready for the call to
performInvocation.

So that's what I've done so far, is merge EJBInvoker into JAXRSInvoker.

I now have had trouble building openEJB, however, I remember easyBeans
building fine. Also, I see that easyBeans is deployable on Jetty. I am
uncertain whether or how declaring an EJB container resource, using
?ResourceProvider? will cause jetty to deploy the endpoint through that
container, instead of through the Servlet container that it had been using
in the jaxrs examples (i think).

Since cxf abstract invoker is used, it may be that, without adding all of
the additional code from geronimo to cxf, it might be deployable anyway, as
EJB container, using jetty to deploy ejb resource ?

I am uncertain whether testing this invoker in this way is best, but it
seems that deploying easyBeans by converting the jaxrs basic http example to
EJB might be the simplest way to test this.

It all goes back to what information do you need to pass in to call the
method? Where are you passing it? What are you getting back? Where is it
going? That is all that the JAXRS Invoker was taking care of, as far as I
know, other than maintaining some record (stack) of contextual information
(and I'm not sure how long that history is saved, but from method call to
method call is my guess).

The only thing that the EJBInvoker does is retrieve a different set of
contextual information and defer to a different container.

It is now 11:13 which is sort of late for me, so I just listed what I think
I know; I did not publish a formal paper here. However, I would like to know
whether it sounds like I'm on the right track.

Thanks,

Ryan

Re: JAXRS EJBInvoker

[Sergey Beryozkin <sb...@gmail.com>]

Hi Ryan

On Sun, Jun 19, 2011 at 5:16 AM, Ryan Zoerner <ry...@gmail.com> wrote:
> It has been a while since I have written to the dev list, but I am working
> on putting an JAXRSEJBInvoker together. The naive implementation (in this
> case, that means rough draft), consists of taking JAXRSInvoker, replacing
> all instances of that word with EJBInvoker, extending AbstractInvoker, and
> adding in the code from the EJBInvoker found in geronimo. The main key
> difference between JAXWSInvoker and EJBInvoker is that EJBInvoker hands
> actual invocation responsibilities off to the EJB container instead of to
> java method reflection. For the invoke method with 4 params, in
> AbstractInvoker, the method can be directly replaced by the methods in
> EJBInvoker. The only place where an actual invocation call is made is in
> that method. The entire method is devoted to getting ready for the call to
> performInvocation.
>
> So that's what I've done so far, is merge EJBInvoker into JAXRSInvoker.
>

I looked at this code:
https://svn.apache.org/repos/asf/geronimo/server/trunk/plugins/cxf/

It's difficult for me to give a concrete advise at this stage. I can
only say what I'd do if I were to try integrating
CXF JAX-RS with Geronimo. I'd spend all my time on understanding how
the whole https://svn.apache.org/repos/asf/geronimo/server/trunk/plugins/cxf/
code works, by debugging and asking questions.

I can see you spotted EJbInvoker is dealing with the actual invocation
- but as you can see it's appears it's only part of the picture and it
does not even deal with managing the instance life-cycle. IMHO trying
to merge EJbInvoker into JAXRSInvoker without debugging most of
https://svn.apache.org/repos/asf/geronimo/server/trunk/plugins/cxf/ as
part of CXF JAX-WS endpoint deployment and invocation is not
realistic. You meed to *feel* what you are doing and the only way to
do it, IMHO, is to understand
https://svn.apache.org/repos/asf/geronimo/server/trunk/plugins/cxf/.
As well as to understand how CXF JAXRS invoker works. Understanding
how Geronimo EJBInvoker and CXF JAX-RS invoker work is the key toward
creating something like (Geronimo)EJBJAXRSInvoker.  CXF JAX-RS may
need to be refactored a bit, may be AbstractJAXRSInvoker needs to be
introduced.

 https://svn.apache.org/repos/asf/geronimo/server/trunk/plugins/cxf/
may need to copied into something like
https://svn.apache.org/repos/asf/geronimo/server/trunk/plugins/cxf-jaxrs/
and a fair bit of code may need to be changed because most of
https://svn.apache.org/repos/asf/geronimo/server/trunk/plugins/cxf/ is
JAX-WS centric. But the first thing is to make sure you understand how
https://svn.apache.org/repos/asf/geronimo/server/trunk/plugins/cxf/
works and how CXF JAX-RS Invoker works,

> I now have had trouble building openEJB, however, I remember easyBeans
> building fine. Also, I see that easyBeans is deployable on Jetty. I am
> uncertain whether or how declaring an EJB container resource, using
> ?ResourceProvider? will cause jetty to deploy the endpoint through that
> container, instead of through the Servlet container that it had been using
> in the jaxrs examples (i think).
>
> Since cxf abstract invoker is used, it may be that, without adding all of
> the additional code from geronimo to cxf, it might be deployable anyway, as
> EJB container, using jetty to deploy ejb resource ?
>
> I am uncertain whether testing this invoker in this way is best, but it
> seems that deploying easyBeans by converting the jaxrs basic http example to
> EJB might be the simplest way to test this.
>

Personally I'd welcome OpenEJB being integrated with CXF JAX-RS as
well. But each container/EJB framework offers its own integration
point and thus I don't think you can
use Geronimo EJBInvoker with OpenEJB. If you feel now, after
experimenting with Geronimo, that OpenEJB integration could be the
simplest way forward, then sure, give it a try.
please interact with Romain, ask questions, etc. The same what I said
above would apply here though as well - understanding how OpenEJB CXF
JAX-WS integration is done and how it can be mapped to the way CXF
JAX-RS invoker works is the key,,.May be CXF JAX-RS needs to be
refactored a bit, etc. It (OpenEJB code) did look simple and easy to
understand actually...

Cheers, Sergey

> It all goes back to what information do you need to pass in to call the
> method? Where are you passing it? What are you getting back? Where is it
> going? That is all that the JAXRS Invoker was taking care of, as far as I
> know, other than maintaining some record (stack) of contextual information
> (and I'm not sure how long that history is saved, but from method call to
> method call is my guess).
>
> The only thing that the EJBInvoker does is retrieve a different set of
> contextual information and defer to a different container.
>
> It is now 11:13 which is sort of late for me, so I just listed what I think
> I know; I did not publish a formal paper here. However, I would like to know
> whether it sounds like I'm on the right track.
>
> Thanks,
>
> Ryan
>



-- 
Sergey Beryozkin

Application Integration Division of Talend
http://sberyozkin.blogspot.com

Re: JAXRS EJBInvoker

[David Blevins <da...@visi.com>]

On Jun 18, 2011, at 9:16 PM, Ryan Zoerner wrote:

> It has been a while since I have written to the dev list, but I am working
> on putting an JAXRSEJBInvoker together. The naive implementation (in this
> case, that means rough draft), consists of taking JAXRSInvoker, replacing
> all instances of that word with EJBInvoker, extending AbstractInvoker, and
> adding in the code from the EJBInvoker found in geronimo. The main key
> difference between JAXWSInvoker and EJBInvoker is that EJBInvoker hands
> actual invocation responsibilities off to the EJB container instead of to
> java method reflection. For the invoke method with 4 params, in
> AbstractInvoker, the method can be directly replaced by the methods in
> EJBInvoker. The only place where an actual invocation call is made is in
> that method. The entire method is devoted to getting ready for the call to
> performInvocation.
> 
> So that's what I've done so far, is merge EJBInvoker into JAXRSInvoker.
> 
> I now have had trouble building openEJB

Should be building fine now.  Also note that the OpenEJB/CXF integration (also based on the G code) will automatically use Jetty if the libraries are in the classpath.  Works in embedded or standalone modes.

Another committer, Romain, just started hacking on adding JAX-RS support right into the core of OpenEJB (just committed some of that yesterday).  He hasn't yet gotten to the transport part yet (the CXF part), but it sounds like between the two of you you'd have something working in no time.


-David


> , however, I remember easyBeans
> building fine. Also, I see that easyBeans is deployable on Jetty. I am
> uncertain whether or how declaring an EJB container resource, using
> ?ResourceProvider? will cause jetty to deploy the endpoint through that
> container, instead of through the Servlet container that it had been using
> in the jaxrs examples (i think).
> 
> Since cxf abstract invoker is used, it may be that, without adding all of
> the additional code from geronimo to cxf, it might be deployable anyway, as
> EJB container, using jetty to deploy ejb resource ?
> 
> I am uncertain whether testing this invoker in this way is best, but it
> seems that deploying easyBeans by converting the jaxrs basic http example to
> EJB might be the simplest way to test this.
> 
> It all goes back to what information do you need to pass in to call the
> method? Where are you passing it? What are you getting back? Where is it
> going? That is all that the JAXRS Invoker was taking care of, as far as I
> know, other than maintaining some record (stack) of contextual information
> (and I'm not sure how long that history is saved, but from method call to
> method call is my guess).
> 
> The only thing that the EJBInvoker does is retrieve a different set of
> contextual information and defer to a different container.
> 
> It is now 11:13 which is sort of late for me, so I just listed what I think
> I know; I did not publish a formal paper here. However, I would like to know
> whether it sounds like I'm on the right track.
> 
> Thanks,
> 
> Ryan

Re: JAXRS EJBInvoker

[Ryan Zoerner <ry...@gmail.com>]

Here is a link to the rough draft:

http://pages.cs.wisc.edu/~zoerner/downloads/dev/samples/EJBInvoker/EJBInvoker.java