On Jul 15, 2010, at 9:31 AM, David Blevins wrote: > > On Jul 11, 2010, at 5:34 AM, Gurkan Erdogdu wrote: > >> Hello folks; >> >> As of https://issues.apache.org/jira/browse/OPENEJB-1197, I have implemented >> initial version of the integration between OpenEJB and OpenWebBeans. This >> code >> is not perfect but at least we could discuss based on it regrading how we >> could >> proceed next. > > Hi Gurkan! > > This is a decent start. I recreated our cdi branch and checked the code in > there. Build status is 67 failures and 25 errors, but that is to be expected > :) > > So one of the things we should nail down is exactly what is the "reach" of > the BeanManager implementation. It's currently implemented as a per > classloader VM singleton, but OpenEJB lets you create multiple applications > in the same classloader (common for the embedded case). > > This appears overall with the general WebBeansFinder.getSingletonInstance use. > > Ideally we'd be able to just create the BeanManager and related objects once > per app and not use a vm static to lookup those things.
Been hacking on this a bit and have changed things up slightly. The BeansDeployer class is not intended to stay, but overall the goal is to make the deployment process a little more like the normal OpenEJB process. We read the beans.xml in the ReadDescriptors and if someone specified an altDD prefix, then it will also apply to the beans.xml. Same with includes and excludes. We process the beans.xml data into a JAXB tree and that information is moved to the assembler as an BeansInfo object. It previously loaded all classes in the jar and turned them into potential managed beans. I've switched it up so that we can move this into a model where we potentially do all that kind of scanning in the config phase based on the data in the ClassFinder. There is some work still to be done there. With a bit of improvement to xbean-finder we could get a list of all classes that have any annotations at all and pass that in as possible CDI classes which will get us pretty far. Down to "Failures: 6, Errors: 20" on build status. Gurkan has done some related work which brings the failures down to 2. Digging into that next. -David
