On Oct 31, 2010, at 11:15 PM, David Jencks wrote: > > On Oct 31, 2010, at 10:49 PM, David Jencks wrote: > >> >> On Oct 31, 2010, at 5:46 PM, David Blevins wrote: >> >>> >>> On Oct 30, 2010, at 11:41 PM, [email protected] wrote: >>> >>>> Author: djencks >>>> Date: Sun Oct 31 06:41:46 2010 >>>> New Revision: 1029263 >>>> >>>> URL: http://svn.apache.org/viewvc?rev=1029263&view=rev >>>> Log: >>>> OPENEJB-1382 Put the xml configurer back in, it's needed to determine >>>> active decorators. >>> >>> We were already handing it the list of decorators from the beans.xml via >>> the Beans JAXB tree. >>> >>> Any details on what was not working there? Ideally we would just fix that. >> >> Nothing was marking the decorators mentioned in beans.xml as enabled in owb. >> I didn't see the openejb code that looks at beans.xml. Does openejb need >> to know what's in beans.xml other than what owb needs? > > I found the code you are thinking of in CdiScanner. At the moment in > geronimo-openejb we're using an Osgi scanner that finds all classes just like > the owb scanners do. Thus, your code that registers the decorators wasn't > getting called. So, I agree we need a better solution.
Aha. Strange thing is we use the same code to find the ejb-jar.xml -- or so I thought. Starting to get hazzy memories of some Geronimo integration code that adds the URL of the ejb-jar.xml file to the org.apache.openejb.config.EjbModule.getAltDDs map. If that's the case, we simply need to add the beans.xml URL as well and it will get picked up even if an alternate was specified. > Have we demonstrated unequivocally that owb can work fine without all the > classes, just the ones cdiscanner finds? I have the required support we need from xbean-finder partially working now. Not sure how much time I'm going to get at ApacheCon -- likely not much as I still have to write my presentation -- but it's looking good. Meanwhile, we can continue to get by with the load-all-classes approach you wired in. On a related integration note, I know we weren't previously, but we should be able to share the AbstractFinder that is used to scan a module -- since a module can be so many things these days. Probably some good reuse we could get by explicitly setting the AbstractFinder in the EjbModule on the G-side before handing it over to OpenEJB. -David
