Hi;

Thanks a lot for answering.

In JSR-299, integration with the EJBs tightly depends on an EJB Container.
There are actually three use cases that we require to get help from you;

1* Discovery and definition of the *EJB 3.1 Style Session Beans (Exposing a
*Local* view) * from an application deployment.
*
Spec says that *: If metadata directory of the application deployment
(WEB-INF or META-INF) contains *beans.xml* with *ejb-jar.xml*, then the
deployment is candidate for  defining *JSR-299 Session Beans*

After the deployed EJB classes are our hands, we are able to define "JSR-299
Session Beans".*

Spec Section : *More of the information could be found in the Section : *3.3
Session Beans *of the specification.

2* Life cycle of the EJB Beans including the Message Driven Beans

In JSR-299 there is a term called "API Type". For EJB3 style session beans
(providing Local View), API type is defined in the specification as follows:

All local interfaces of the bean that do not have wildcard type parameters
> or type vairables and their super interfaces. If the EJB bean has a bean
> class local view and the bean class is not a parametrized type, the set of
> bean types contains the bean class and all of its superclasses.


This means that, whenever an EJB injection is done by the container into the
client, client can type-cast to instance into any class type that is
contained in the API type list. To satisfy this requirement, spec talks
about the *Session bean proxies*.

EJB local object references do not implement all local interfaces of the
> EJB. A local object reference may not be typecast to different local
> interface type (API type). Therefore the container proxies the local object
> reference. A session bean proxy implements all local interfaces of the EJB.
> When the proxy is invoked, the proxy obtains the appropriate EJB local
> object reference and delegates the invocation to it.


So, we require to get a session bean proxy from the EJB container.

Spec also talks about the "Lifecycle" of the EJBs


   - Lifecycle of Stateful Session Beans (*Spec Section : 6.5*)
   - Lifecycle of Stateless and Singleton Session Beans (*Spec Section 6.6*)
   - Lifecycle of general EJBs (*Spec Section 6.11)*

Simply, these are related with the creating and destroying the EJBs and
injection of its dependencies. But I think that all of these stuffs must be
done internally by the EJB container. Because some of the requirements are
not handled by using hooks into the container such as *defining
interceptors*. For example, spec talks about the injection that has to be
done before the @PostConstruct

When the EJB container creates a new instance of an EJB, the container must
> perform the following steps after Java EE injection has been performed and
> *before the @PostConstruct c*allback occurs;.....
>


3* Injection of the Java EE Resources

We are required to inject some Java EE resources related with the EJB
specification, for example;

   - Container managed PersistentUnit
   - Container managed PersistentContext


Basically these are the requirements that we have to collaborate with you.

WDYT ? How could we work on these requirements together? How could
OpenWebBeans integrate with the OpenEJB?

I also attached the specification document.

Thanks;

Gurkan


2009/3/26 Jacek Laskowski <[email protected]>

> On Wed, Mar 25, 2009 at 2:12 PM, Gurkan Erdogdu
> <[email protected]> wrote:
>
> > If you have time, I am more than happy to discuss the details of
> > integration.
>
> What's required from ejb's side to make openwebbeans happy? Are there
> any annotations to take care of or more than that? Please elaborate
> and I'm sure we'll find a solution (and possible takers).
>
> Jacek
>
> --
> Jacek Laskowski
> Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl
>



-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

Reply via email to