You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Ryan Zoerner <ry...@gmail.com> on 2011/07/06 02:27:10 UTC

EJBInvoker, progress, observations, questions about EJB creation organization, other various questions.

Hi Sergey,

I am wondering about the 'finally' block in the
'public Object invoke(Exchange exchange, Object request)' method of the
JAXRSInvoker class.

For me, it is line numbers: 113-139.

These lines call the resourceProvider to release the object instance in
certain cases. Is this something that
we can exclude from the JAXRSEJBInvoker? Should the bean manage all of its
lifecycle based on the
annotation or lifecycle-type (as when declared in xml)?

In the InvokerFactory model, it releases the instance. In that model, the
invoker plays the role of the resourceProvider
by containing the Factory.

I went through the CXFEasyBeansInvoker from easybeans, and compared it with
the Jonas version, by commenting each
line or group of lines with their location in the Jonas/CXF version. I think
that now, we need to:

Get the bean instance from the factory and use java.lang.reflect.Method to
invoke the method.

After the method is invoked, the bean is released. The InvokerFactory does
that by way of the Invoker in the Jonas model.

The Jonas model has JAXWSInvoker (with no invoke methods) managing other
aspects of cleanup during invocation.

The EasyBeansCXFInvoker invoke(w/ 4 params) method, contains, all the way
down to the exceptionHandling, the essentials
of the EasyBeans portion of the invocation. The remainder is common to
AbstractInvoker.

Right now, then, I am looking at JAXRSInvoker. If
serverFactory.setResourceClass() won't work, how will we adjust it to allow
for @Stateless, @Stateful, etc. annotations? I think that it currently
throws an exception for an unknown annotation.

Also, I've noticed that the JContainer3 has a method for creating a factory
for itself. I am wondering about passing in factories.
How will the factories be created? How will the IDeployable be created? I
was thinking about passing that in to the RP and
creating the factories that way, but maybe it would be better, somehow, to
create the bean instance somewhere.. where??,
and pass that into the RP, which can then invoke the JContainer3's start()
method, which calls createBeanFactories(), which
calls both createMessageDrivenBeanFactory and createSessionBeanFactory. So,
passing the bean in, seems to be the,
now, preferred, method, however, where and how is the bean going to be
created? Do we declare it as a resourceClass?
It does not seem to be focused on as being a class, in Easybeans, rather,
the focus seems to be that of the entire deployable
package or folder or archive.

So, I am wondering what you think about the idea of passing the bean in and
using it to start the factory, but am concerned about
how cxf proposes to deploy this container? Should I be looking at the
CXF/Jetty (such as cxfServlet) interface and finding out
how the bean should be deploying through jetty? or are we just going to have
the bean resource, lifecycle managed by factory,
sitting alone as accessible through a servlet?

I think that I am close to having the invoker finished. My main concern is
how are we going to get the beans instantiated so that I can
test them as being deployed? My main concern with the invoker is, what parts
of JAXRSInvoker correspond to sf.declareResourceClass?
If that method will not run for EJB annotations, what will become of cri and
ori? Will we change declareResourceClasses? Will it be
necessary?

I just wanted to update you on my progress. The class-scanner in the RP
might be moved out of the RP into whatever class creates an
EJB IDeployable and packages it into a bean, returing a factory instance.

Thanks,

Ryan

Re: EJBInvoker, progress, observations, questions about EJB creation organization, other various questions.

Posted by Sergey Beryozkin <sb...@gmail.com>.
>
> the easybeans package is called easybeans-cxf-extension, am I correct that
> the easybeans bootstrap or cxfListener should be registered as an extension?
> Perhaps I could set up an easybeans extension in cxf and try to deploy by
> way of cxf jaxws serverFactory, or equivalent? I would need help verifying
> correctness of JAX-WS Java code and xml config files and namespaces,
> and perhaps help with Maven setup, such as ?plugin setup? I think to set
> up a file without a parent would be best (if we go this direction) and to
> place
> all dependencies in that file.
>

Are you asking how to deploy CXF JAXWS Easybeans endpoints ?
You need to understand how that works, every single bit. I can't help
there, you need to talk to Easybeans
experts, deploy it, and then we will discuss how a similar procedure
can be achieved for JAX-RS. You are asking questions which I can only
attempt to answer by doing exactly what I'm asking you to do, deploy
JAX-WS endpoint and learn and then repeat the similar process for
JAX-RS.

thanks, Sergey
> I sent 4 other messages btw., in case you didn't read them.
>
> Thanks,
>
> Ryan
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/EJBInvoker-progress-observations-questions-about-EJB-creation-organization-other-various-questions-tp4555258p4563210.html
> Sent from the cxf-dev mailing list archive at Nabble.com.
>



-- 
Sergey Beryozkin

http://sberyozkin.blogspot.com
Talend - http://www.talend.com

Re: EJBInvoker, progress, observations, questions about EJB creation organization, other various questions.

Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Ryan

I'll try to reply asap. Please, make sure you can deploy a live CXF
JAXWS EJB endpoint and proceed further with your investigations re
JAXRS...   Looks like you are getting real close...

thanks, Sergey

On Fri, Jul 8, 2011 at 3:56 AM, Ryan Zoerner <ry...@gmail.com> wrote:
> There was a bit of a typo:
>
>    "because Jonas InvokerFactory
>    only extends, for invocation(..) method calls from AbstractInvoker
> (including
>    performInvocation)"
>
> because Jonas InvokerFactory ( the only other code referenced
> in EasyBeansCXFInvoker.invoke(4 params) ) extends AbstractInvoker
> for all practical purposes, in terms of calls to invoke(..),
> performInvocation,
> and related sub-methods of AbstractInvoker,
>
> (it seems good to extend JAXRSInvoker with calls to AbstractInvoker
> rather than synthesizing them into one invoke(4 params) method
> in EJBInvoker.
>
> Thanks,
>
> Ryan
>
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/EJBInvoker-progress-observations-questions-about-EJB-creation-organization-other-various-questions-tp4555258p4563226.html
> Sent from the cxf-dev mailing list archive at Nabble.com.
>



-- 
Sergey Beryozkin

http://sberyozkin.blogspot.com
Talend - http://www.talend.com

Re: EJBInvoker, progress, observations, questions about EJB creation organization, other various questions.

Posted by Ryan Zoerner <ry...@gmail.com>.
There was a bit of a typo: 
 
    "because Jonas InvokerFactory
    only extends, for invocation(..) method calls from AbstractInvoker
(including
    performInvocation)" 
 
because Jonas InvokerFactory ( the only other code referenced 
in EasyBeansCXFInvoker.invoke(4 params) ) extends AbstractInvoker 
for all practical purposes, in terms of calls to invoke(..),
performInvocation, 
and related sub-methods of AbstractInvoker, 
 
(it seems good to extend JAXRSInvoker with calls to AbstractInvoker 
rather than synthesizing them into one invoke(4 params) method 
in EJBInvoker. 
 
Thanks, 
 
Ryan 

 


--
View this message in context: http://cxf.547215.n5.nabble.com/EJBInvoker-progress-observations-questions-about-EJB-creation-organization-other-various-questions-tp4555258p4563226.html
Sent from the cxf-dev mailing list archive at Nabble.com.

Re: EJBInvoker, progress, observations, questions about EJB creation organization, other various questions.

Posted by Ryan Zoerner <ry...@gmail.com>.
>Do you agree or do you still see the need to have custom
>JAXRSEJBInvoker & custom EJBResourceProvider ? I'm not sure what
>JAXRSEJBInvoker will do ? 
 
Then, in order to create the EJBInstance, it would be nice to have some
create EJB Instance method, as described before, which
would take things like the web.xml file as params, and then create the
IDeployable, create the EJBInstance, and from that JContainer3,
create the appropriate factory, since the container already automatically
selects which factory to instantiate. That factory can either
sit in RP, which is where these methods might go, or possibly as some
EJBPackageCreationUtility class that is called by RP, or
perhaps, factory could be passed to InvokerFactory, but I think that because
JAX-RS, you might want to keep the RP model. 
 
>Do you mean Invoker asks InvokerFactory to manage the lifecycle ?
 
Yes, invoker calls create and release in InvokerFactory. 
So the instance from pool management specifically happens in Invoker
Factory.
 
>Do you think JAXRSEJBInvoker should extend JAXRSInvoker 

yes. 

>and decorate
>the invocation with something similar to what
>EasyBeansCXFInvoker does ? 
 
Ok. So, EasyBeansCXFInvoker copies stuff from the AbstractInvoker that it
extends 
 
http://pages.cs.wisc.edu/~zoerner/downloads/dev/referenced_in_mailing_list_question/test_easybeans_invoke.java 
 
You can see that in the invoke method, until the exception catching occurs,
that all of the 
lines, with the exception of packaging the response into a list, are taken
exactly from 
either the InvokerFactory, or the AbstractInvoker, so, because Jonas
InvokerFactory 
only extends, for invocation(..) method calls from AbstractInvoker
(including 
performInvocation), I would like to possibly refactor, as just mentioned,
Invoker and 
InvokerFactory into RP (factory) provider and Invoker, with outside method
to 
construct EJB packageable resource from component items, such as class
source, 
web.xml file, etc. EJBInvoker would then extend JAXRSInvoker. RP would be
settable 
as RP to JAXRSServerFactoryBean. If you disagree, obviously the final code
organization 
policy is up to Apache and yourself, not me. 
 
>Don't worry about the class scaner for now, please try to understand
>how EasyBeans sets up a CXF JAX-WS endpoint and follow the same
>process...
 
the easybeans package is called easybeans-cxf-extension, am I correct that 
the easybeans bootstrap or cxfListener should be registered as an extension? 
Perhaps I could set up an easybeans extension in cxf and try to deploy by 
way of cxf jaxws serverFactory, or equivalent? I would need help verifying 
correctness of JAX-WS Java code and xml config files and namespaces, 
and perhaps help with Maven setup, such as ?plugin setup? I think to set 
up a file without a parent would be best (if we go this direction) and to
place 
all dependencies in that file. 
 
I sent 4 other messages btw., in case you didn't read them. 
 
Thanks, 
 
Ryan 
 


--
View this message in context: http://cxf.547215.n5.nabble.com/EJBInvoker-progress-observations-questions-about-EJB-creation-organization-other-various-questions-tp4555258p4563210.html
Sent from the cxf-dev mailing list archive at Nabble.com.

Re: EJBInvoker, progress, observations, questions about EJB creation organization, other various questions.

Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Ryan

On Wed, Jul 6, 2011 at 1:27 AM, Ryan Zoerner <ry...@gmail.com> wrote:
> Hi Sergey,
>
> I am wondering about the 'finally' block in the
> 'public Object invoke(Exchange exchange, Object request)' method of the
> JAXRSInvoker class.
>
> For me, it is line numbers: 113-139.
>
> These lines call the resourceProvider to release the object instance in
> certain cases.

One can configure CXF JAX-RS to use RP to release the instance only
after JAXRSOutInterceptor finalized writing out the response object to
output stream, so this is why you see "if" branch there, but in most
cases, the instance will be released in finally (which is no op really
for singletons).
ResourceProvider also manages the allocation of instances, it's hidden
inside JAXRsInvoker.getServiceObject. The allocation occurs only
initially, no need to do it in case of recursive subresource
invocations.


> Is this something that
> we can exclude from the JAXRSEJBInvoker? Should the bean manage all of its
> lifecycle based on the
> annotation or lifecycle-type (as when declared in xml)?
>
> In the InvokerFactory model, it releases the instance. In that model, the
> invoker plays the role of the resourceProvider
> by containing the Factory.
>

I think it is InvokerFactory which acts exactly as our EJB
ResourceProvider does. JAXWS Invoker simply delegates to
InvokerFactory, JAXRSInvoker will delegate to our custom
ResourceProvider.

Do you agree or do you still see the need to have custom
JAXRSEJBInvoker & custom EJBResourceProvider ? I'm not sure what
JAXRSEJBInvoker will do ?

> I went through the CXFEasyBeansInvoker from easybeans, and compared it with
> the Jonas version, by commenting each
> line or group of lines with their location in the Jonas/CXF version. I think
> that now, we need to:
>
> Get the bean instance from the factory and use java.lang.reflect.Method to
> invoke the method.
>
> After the method is invoked, the bean is released. The InvokerFactory does
> that by way of the Invoker in the Jonas model.
>

Do you mean Invoker asks InvokerFactory to manage the lifecycle ?

> The Jonas model has JAXWSInvoker (with no invoke methods) managing other
> aspects of cleanup during invocation.
>
> The EasyBeansCXFInvoker invoke(w/ 4 params) method, contains, all the way
> down to the exceptionHandling, the essentials
> of the EasyBeans portion of the invocation. The remainder is common to
> AbstractInvoker.
>

Do you think JAXRSEJBInvoker should extend JAXRSInvoker and decorate
the invocation with something similar to what
EasyBeansCXFInvoker does ?

> Right now, then, I am looking at JAXRSInvoker. If
> serverFactory.setResourceClass() won't work, how will we adjust it to allow
> for @Stateless, @Stateful, etc. annotations? I think that it currently
> throws an exception for an unknown annotation.
>

JAXRS server factory does not know about @Stateless, @Stateful, etc.
It is only concerned about JAX-RS annotations.
It is the job of ResourceProvider to handle those annotations -
similarly to the way InvokerFactory does...

> Also, I've noticed that the JContainer3 has a method for creating a factory
> for itself. I am wondering about passing in factories.
> How will the factories be created? How will the IDeployable be created? I
> was thinking about passing that in to the RP and
> creating the factories that way, but maybe it would be better, somehow, to
> create the bean instance somewhere.. where??,
> and pass that into the RP, which can then invoke the JContainer3's start()
> method, which calls createBeanFactories(), which
> calls both createMessageDrivenBeanFactory and createSessionBeanFactory. So,
> passing the bean in, seems to be the,
> now, preferred, method, however, where and how is the bean going to be
> created? Do we declare it as a resourceClass?
> It does not seem to be focused on as being a class, in Easybeans, rather,
> the focus seems to be that of the entire deployable
> package or folder or archive.
>
> So, I am wondering what you think about the idea of passing the bean in and
> using it to start the factory, but am concerned about
> how cxf proposes to deploy this container? Should I be looking at the
> CXF/Jetty (such as cxfServlet) interface and finding out
> how the bean should be deploying through jetty? or are we just going to have
> the bean resource, lifecycle managed by factory,
> sitting alone as accessible through a servlet?
>
> I think that I am close to having the invoker finished. My main concern is
> how are we going to get the beans instantiated so that I can
> test them as being deployed? My main concern with the invoker is, what parts
> of JAXRSInvoker correspond to sf.declareResourceClass?
> If that method will not run for EJB annotations, what will become of cri and
> ori? Will we change declareResourceClasses? Will it be
> necessary?
>
> I just wanted to update you on my progress. The class-scanner in the RP
> might be moved out of the RP into whatever class creates an
> EJB IDeployable and packages it into a bean, returing a factory instance.
>

Don't worry about the class scaner for now, please try to understand
how EasyBeans sets up a CXF JAX-WS endpoint and follow the same
process...

thanks, Sergey

> Thanks,
>
> Ryan
>



-- 
Sergey Beryozkin

http://sberyozkin.blogspot.com
Talend - http://www.talend.com

Re: EJBInvoker, progress, observations, questions about EJB creation organization, other various questions.

Posted by Ryan Zoerner <ry...@gmail.com>.
Everything below EasyBeansJaxWsServerFactoryBean is available in easybeans
without the aid of Jonas.

Ryan

Re: EJBInvoker, progress, observations, questions about EJB creation organization, other various questions.

Posted by Ryan Zoerner <ry...@gmail.com>.
For reference purposes, here is the call hierarchy up from
EasyBeansInvokerFactory:

EasyBeansInvokerFactory
EasyBeansMethodInvoker
EasyBeansJaxWsServerFactoryBean
LifeCycleCallback (in Jonas and in easybeans-cxf)
(in easybeans-cxf) CXFConfigurationExtension
(in Jonas) CXFConfigurationExtension
CXFConfigurationExtension (in easybeans only) EasyBeansCXFBootstrap

this class extends EmbeddedBootstrap, has no constructor, so class is only
a name to call and an additional method for the EmbeddedBootstrap.

org.ow2.easybeans.server.war.EasyBeansContextListener loads
EmbeddedBootstrap class.

org.ow2.easybeans.cxf.EasyBeansCXFListener loads
org.ow2.easybeans.cxf.EasyBeansCXFBootstrap.

No further info could be found except that EasyBeansCXFListener is described
as:
 * Listener class which is notified of lifecycle events. It allows to start
 * EasyBeans at startup and stop it at the end.

It is a contextListener that has a method -- getBootstrapClassName() --
which returns the bootstrap class to load.

It may be that this class is called by Jetty.

--Ryan

Re: EJBInvoker, progress, observations, questions about EJB creation organization, other various questions.

Posted by Ryan Zoerner <ry...@gmail.com>.
Hi again Sergey,

I noticed that there is a CXFResourceInjector class, in Jonas, which does
annotation processing, presumably on an ejb-annotated resource class.
However, this may be only for integration of cxf with Jonas. Because the
easybeans version of the invoker is exactly the same, it seems that
easybeans, is, itself, deployable on jetty and that some of these supporting
classes in Jonas might not be necessary. Also, the Invoker and
InvokerFactory, within Jonas are instantiated in a single line in
EasyBeansJaxWsServiceFactoryBean, which corresponds to the JAXRSServer or
JAXRSService Factory approximately, so you can see that the invoker is
treated in the same way as in CXF JAXRS. The resource injection is
approximate to AbstractResourceInfo processing, I think.

Thanks,

Ryan

Re: EJBInvoker, progress, observations, questions about EJB creation organization, other various questions.

Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi,

On Wed, Jul 6, 2011 at 4:42 AM, Ryan Zoerner <ry...@gmail.com> wrote:
> Hi Sergey,
>
> I have tested @Stateless in CustomerService.java, from the http basic
> example in jaxrs-samples.
>
> The annotation appears in the list in
> ServerFactory.Service.ClassResourceInfos[].ResourceClass.annotations.
>
> Therefore, sf.setResourceClasses does not interfere with the annotation
> being processed, but I had seen it
> throw an exception before, for some unknown reason.
>
> The point that I was making before is that CXFEasyBeansInvoker is precisely
> the difference between cxf-easybeans
> and CXF-JAXWS-easybeans. Also, the jonas version, which was the second group
> mentioned in the last "between"
> statement, does the Invoker and InvokerFactory. The Invoker does not do
> invoker it just extends jaxwsAbstractInvoker
> and gets and releases resource. Perhaps, similar to RP. I think that there
> is no RP in the Jonas model. The jonas model
> keeps a factory field that is instantiated at construction time, in the
> InvokerFactory. The invoker factory actually manages
> the specific releasing of the pool gotten object.
>

Custom InvokerFactory is RP for JAX-WS endpoints. How does the actual
invocation is done in JAX-WS case ?
You are saying  Invoker does no do any invocations but it must. It
does use InvokerFactory (RP).

> So. Basically, I think that the InvokerFactory and Invoker from that model
> can be refactored out into RP-- refactored partially.
> Second, if the Invoker extends JAXRS Invoker, it would precisely be the
> EasyBeans version of the Invoker, but with factory-pool
> model, and with JAXRS instead of JAXWS. So, for starters, that is what I
> would recommend to myself as doing next. Then, if it
> needs to be adjusted (JAXRSInvoker) then that would be the other step.
> Perhaps it will now be doing things that are not needed.
>
> Then, in order to create the EJBInstance, it would be nice to have some
> create EJB Instance method, as described before, which
> would take things like the web.xml file as params, and then create the
> IDeployable, create the EJBInstance, and from that JContainer3,
> create the appropriate factory, since the container already automatically
> selects which factory to instantiate. That factory can either
> sit in RP, which is where these methods might go, or possibly as some
> EJBPackageCreationUtility class that is called by RP, or
> perhaps, factory could be passed to InvokerFactory, but I think that because
> JAX-RS, you might want to keep the RP model.
>
JAX-WS also uses RP model and it's called InvokerFactory

I'm sorry I don't quite understand what are you saying above about IDeployable.
IMHO, trying to create a solution will be futile without understanding
how pieces fit together for
CXF JAX-WS Easybeans solutions...I also think that our solution would
involve providing a custom RP which will do exactly what
InvokerFactory does, possibly overriding JAXRSInvoker somehow - only
if providing RP alone won't be enough...But again, that is not enough
in itself - you have to confirm it's working and thus you'll need to
deploy JAX-RS endpoint with Easybeans and thus you need to understand
how CXF JAX-WS Easybeans works

thanks, Sergey

> So, there is my synopsis on where the answer is, and if permission, I will
> create the Invoker in the steps that I described here.
>
> Thanks again,
>
> Ryan
>



-- 
Sergey Beryozkin

http://sberyozkin.blogspot.com
Talend - http://www.talend.com

Re: EJBInvoker, progress, observations, questions about EJB creation organization, other various questions.

Posted by Ryan Zoerner <ry...@gmail.com>.
Hi Sergey,

I have tested @Stateless in CustomerService.java, from the http basic
example in jaxrs-samples.

The annotation appears in the list in
ServerFactory.Service.ClassResourceInfos[].ResourceClass.annotations.

Therefore, sf.setResourceClasses does not interfere with the annotation
being processed, but I had seen it
throw an exception before, for some unknown reason.

The point that I was making before is that CXFEasyBeansInvoker is precisely
the difference between cxf-easybeans
and CXF-JAXWS-easybeans. Also, the jonas version, which was the second group
mentioned in the last "between"
statement, does the Invoker and InvokerFactory. The Invoker does not do
invoker it just extends jaxwsAbstractInvoker
and gets and releases resource. Perhaps, similar to RP. I think that there
is no RP in the Jonas model. The jonas model
keeps a factory field that is instantiated at construction time, in the
InvokerFactory. The invoker factory actually manages
the specific releasing of the pool gotten object.

So. Basically, I think that the InvokerFactory and Invoker from that model
can be refactored out into RP-- refactored partially.
Second, if the Invoker extends JAXRS Invoker, it would precisely be the
EasyBeans version of the Invoker, but with factory-pool
model, and with JAXRS instead of JAXWS. So, for starters, that is what I
would recommend to myself as doing next. Then, if it
needs to be adjusted (JAXRSInvoker) then that would be the other step.
Perhaps it will now be doing things that are not needed.

Then, in order to create the EJBInstance, it would be nice to have some
create EJB Instance method, as described before, which
would take things like the web.xml file as params, and then create the
IDeployable, create the EJBInstance, and from that JContainer3,
create the appropriate factory, since the container already automatically
selects which factory to instantiate. That factory can either
sit in RP, which is where these methods might go, or possibly as some
EJBPackageCreationUtility class that is called by RP, or
perhaps, factory could be passed to InvokerFactory, but I think that because
JAX-RS, you might want to keep the RP model.

So, there is my synopsis on where the answer is, and if permission, I will
create the Invoker in the steps that I described here.

Thanks again,

Ryan

Re: EJBInvoker, progress, observations, questions about EJB creation organization, other various questions.

Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi,

On Wed, Jul 6, 2011 at 1:27 AM, Ryan Zoerner <ry...@gmail.com> wrote:
> Hi Sergey,
>
> I am wondering about the 'finally' block in the
> 'public Object invoke(Exchange exchange, Object request)' method of the
> JAXRSInvoker class.
>
> For me, it is line numbers: 113-139.
>
> These lines call the resourceProvider to release the object instance in
> certain cases. Is this something that
> we can exclude from the JAXRSEJBInvoker? Should the bean manage all of its
> lifecycle based on the
> annotation or lifecycle-type (as when declared in xml)?
>
> In the InvokerFactory model, it releases the instance. In that model, the
> invoker plays the role of the resourceProvider
> by containing the Factory.
>
> I went through the CXFEasyBeansInvoker from easybeans, and compared it with
> the Jonas version, by commenting each
> line or group of lines with their location in the Jonas/CXF version. I think
> that now, we need to:
>
> Get the bean instance from the factory and use java.lang.reflect.Method to
> invoke the method.
>
> After the method is invoked, the bean is released. The InvokerFactory does
> that by way of the Invoker in the Jonas model.
>
> The Jonas model has JAXWSInvoker (with no invoke methods) managing other
> aspects of cleanup during invocation.
>
> The EasyBeansCXFInvoker invoke(w/ 4 params) method, contains, all the way
> down to the exceptionHandling, the essentials
> of the EasyBeans portion of the invocation. The remainder is common to
> AbstractInvoker.
>
> Right now, then, I am looking at JAXRSInvoker. If
> serverFactory.setResourceClass() won't work, how will we adjust it to allow
> for @Stateless, @Stateful, etc. annotations? I think that it currently
> throws an exception for an unknown annotation.
>
> Also, I've noticed that the JContainer3 has a method for creating a factory
> for itself. I am wondering about passing in factories.
> How will the factories be created? How will the IDeployable be created? I
> was thinking about passing that in to the RP and
> creating the factories that way, but maybe it would be better, somehow, to
> create the bean instance somewhere.. where??,
> and pass that into the RP, which can then invoke the JContainer3's start()
> method, which calls createBeanFactories(), which
> calls both createMessageDrivenBeanFactory and createSessionBeanFactory. So,
> passing the bean in, seems to be the,
> now, preferred, method, however, where and how is the bean going to be
> created? Do we declare it as a resourceClass?
> It does not seem to be focused on as being a class, in Easybeans, rather,
> the focus seems to be that of the entire deployable
> package or folder or archive.
>
As I said earlier on, I'd go and deploy CXF JAXWS EJB endpoint, you
will learn how Easybeans picks up
CXF JAX-Ws service class. You'd need then to follow a similar process
for JAX-RS. The sooner you do it the better, ask questions on
easybeans list, deploy the JAX-WS endpoint. You are asking how are we
going to declare resource class in Easybeans -  the answer is in the
way Easybeans/Jonas deploys CXF JAX-WS endpoint.

Cheers, Sergey

> So, I am wondering what you think about the idea of passing the bean in and
> using it to start the factory, but am concerned about
> how cxf proposes to deploy this container? Should I be looking at the
> CXF/Jetty (such as cxfServlet) interface and finding out
> how the bean should be deploying through jetty? or are we just going to have
> the bean resource, lifecycle managed by factory,
> sitting alone as accessible through a servlet?
>
> I think that I am close to having the invoker finished. My main concern is
> how are we going to get the beans instantiated so that I can
> test them as being deployed? My main concern with the invoker is, what parts
> of JAXRSInvoker correspond to sf.declareResourceClass?
> If that method will not run for EJB annotations, what will become of cri and
> ori? Will we change declareResourceClasses? Will it be
> necessary?
>
> I just wanted to update you on my progress. The class-scanner in the RP
> might be moved out of the RP into whatever class creates an
> EJB IDeployable and packages it into a bean, returing a factory instance.
>
> Thanks,
>
> Ryan
>



-- 
Sergey Beryozkin

http://sberyozkin.blogspot.com
Talend - http://www.talend.com