cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: JAXRS EJBInvoker
Date Sun, 19 Jun 2011 16:58:28 GMT
Hi Ryan

On Sun, Jun 19, 2011 at 5:16 AM, Ryan Zoerner <ryanzoerner@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

Mime
View raw message