I assume that owe --> owb Actually, I think that there are two different aspects of the integration;
1* *Discovery and Definition* I think that *owb* is responsible for defining *EJB WebBeans* from the classes or ejb-jar.xmls that are discovered by the *oe*. To do this, *owb* could define a SPI that could be implemented by the *oe*. After owb gets the classes from the oe, it defines the ejb style webbeans. *Current Bootstrapping in the OWB : *Currently in the owb, we support the web and standalone deployments. We have created a SPI for the discovery process. This SPI is located in the https://svn.apache.org/repos/asf/incubator/openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/spi/deployer/ > . > In this location, there is an interface, MetaDataDiscoveryService and its abstract implementation. public interface MetaDataDiscoveryService > { > public void scan() throws WebBeansDeploymentException; > > public Map<String, InputStream> getWEBBEANS_XML_LOCATIONS(); > > public AnnotationDB getANNOTATION_DB(); > > public void init(Object object); > } > > Actual implementations of the above SPI are located in the https://svn.apache.org/repos/asf/incubator/openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/spi/ee/deployer/ > . > For web deployment, there is a class **WarMetaDataDiscoveryImpl** for doing the discovery of the webbeans. Basically, it looks for the *beans.xml* files ,in the /WEB-INF/ and /META-INF/ metadata directories of the application current classloader (Thread.current.getContexCLassLoader). It is called by the ServletContextListener that is started by the container in the *war* deployment. *How do we use SPI implementation currently?* To use the SPI implementation, one can provide *openwebbeans/openwebbeans.properties* file in the META-INF directory. If it is not found we are using the default implementations. You can look at this default file content in svn location https://svn.apache.org/repos/asf/incubator/openwebbeans/trunk/webbeans-impl/src/main/resources/META-INF/openwebbeans/openwebbeans-default.properties > *ClassLoader Related* We have some singletons in the OWB, that are paired with classloader Thread.current.getContexCLassLoader. So, each web application's owb defined beans are different and seperated from each other. (Each web application has separate javax.inject.manager.Manager instance that is defined as a *container* in the specification.). *EJB Bootstrapping : *How do we bootstrap the EJB discovery process ? I think that this task may be done by the oe as follows It implements the *MetaDataDiscoveryService*. Maybe we can define another SPI interface for EJB that extends *MetaDataDiscoveryService*. It could be public EjbMetaDataDiscoveryService extends MetaDataDiscoveryService { public Set<Class<?>> getEjbLocalBeans(); public EjbMetaData getEjbMetaData(Class<?> ejbClass); public EjbMetaData getEjbMetaData(String ejbName); ....other methods } *oe* will look for the *beans.xml* file in the */META-INF/* of the deployment artifacts in the application class path. It discovers all the classes from the deployment. How do we start this process? Who is responsible for starting the discovery process ? There are some scenarios for this * EAR Deployment : ? * EJB-JAR Deployment : *oe* is responsible. * WAR Deployment with EJB (collapsed-EAR) --> ServletContextListener also starts the ejb scanning using the *EJBMetaDataDiscovery SPI* implementation. * WAR Deployment --> No ejb discovery. 2* Lifecycle and injection On the other hand, creating proxy instances and doing webbeans related injections must be handled by the *oe*. But, to inject webbeans instances into the ejb instances, *oe* has to be interacted with the *owb Manager* to get injected fields of the ejb session bean. This may be explained by giving an example; Lets say that developer defines the following stateless session bean @Stateless @MyProcessor public class PaymentProcessor implements Processor { @MyLogger ILogger logger; } Also there is an another simple webbean @ApplicationScoped @MyLogger public class Logger implements ILogger { } And there is an another simple webbean that uses session bean @RequestScoped public class Pay { @MyProcessor Processor processor; public void pay() { processor.pay(); } } OWB Side ----------------------- When the *owb* tries to create *Pay* instance, it injects the session bean with API Type *Processor* and Binding Type *MyProcessor*. *owb* has to create session bean proxy. When the actual *pay* method is called on the proxy, proxy calls the method of the actual session bean instance getting from the *oe*(local object of the session bean). Somehow, we have to manage proxy&local object map. OE Side ----------------------- After *oe* creates the session bean instance (local object instance), it will inject the session bean's injected fields that are defined by the *owb* in the discovery and definition phase. *oe* has to get all *owb* related informations (injected fields, initializer methods, etc.) of the session bean from the *owb*. For example, after getting the injected fields of the *PaymentProcessor*, it will ask the *owb Manager* about the injected field with API Type *ILogger* and Binding Type *MyLogger*. After getting the instance from the Manager, it sets the field with it. Basically this is the workflow between the *owb* and *oe*. In other words, *owb* defines the ejb style webbeans. But all of the injections and lifecycle of the instances are managed by the *oe* via helping from the *owb*. Gurkan 2009/3/26 Jacek Laskowski <[email protected]> > On Thu, Mar 26, 2009 at 8:37 AM, Gurkan Erdogdu > <[email protected]> wrote: > > > > WDYT ? How could we work on these requirements together? How could > > OpenWebBeans integrate with the OpenEJB? > > I don't know, but I am interested. Perhaps, the very first integration > could be that owb (openwebbeans) would figure out if oe (openejb) is > available and if so initialize it so it could take a chance to handle > the ejb interactions. From my very fuzzy understanding of the entire > integration, it's owe who drives the interaction not oe. Once OE is > initialized and up for request processing all should be fine and would > not be different than setting up owe and oe together as it's possible > now with some manual configuration. I mean, you can use EJBs from > owe-managed beans (as a local/remote ejb client). Is my thinking > correct? > > Jacek > > -- > Jacek Laskowski > Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl > -- Gurkan Erdogdu http://gurkanerdogdu.blogspot.com
