Thanks David I'm going to start looking around at the code to find an approach for best embedding Eve (LDAP Server) within Geronimo.
Alex > > From: David Jencks <[EMAIL PROTECTED]> > Date: 2003/12/01 Mon PM 02:38:50 EST > To: [EMAIL PROTECTED] > Subject: Re: making JSR 77 / 88 reusable for component authors (& container > developers) > > > On Monday, December 1, 2003, at 10:49 AM, Dain Sundstrom wrote: > > > > > On Sunday, November 30, 2003, at 09:34 PM, Alex Karasulu wrote: > > > >> Dain, David, > >> > >> � > >> > >> Could one of you guys point me to the right packages where this > >> code is located.� I want to begin to understand the amount of effort > >> it would take to get existing components that run in Merlin or > >> Phoenixto run within Geronimo.� And I suspect from our conversations > >> you know what I want to doJ.� It was nice talking to you guys over > >> beers btw. > > > > All of the code is in > > modules/kernel/src/java/org/apache/geronimo/kernel/service but I don't > > think that will help you as it is mostly framework code. I think an > > example would be the best place to start. Unfortunately, I don't know > > where the good examples are anymore. David Jencks converted most of > > the old AbstractManagedObject style components to GeronimoMBeans, so > > I'll defer to him for good examples. > > I guess the examples are: > > connector deployer sets up instances of connector components as > Geronimo mbeans (ResourceAdapter and ManagedConnectionFactory). These > use the multiple target facilities of Geronimo MBeans to add helper > objects that expose additional attributes (such as class names of other > connector components) and adapt connector lifecycle events that require > direct access to instances of resource adapter classes to the > "all-proxy" environment of geronimo mbeans. > > OpenEJB/Nova ejb deployment in which the entirely > non-geronimo-mbean-aware nova ejb containers are deployed as geronimo > mbeans. There is one concession to endpoint lifecycle here: the > TransactionManager is set after the container is created. I think this > can be fixed by making a dependency from the CreateGeronimoMbean task > to the TransactionManager. > > I think the approach of these deployers is very good, in terms of > converting pojo deployment descriptors into constructor arguments and > attributes (for classes we don't control the structure of) for > non-geronimo-mbean aware classes that do the work. The code seems > easier to understand than the xsl approach I tried in the JBoss > connector deployment framework. However, I think it may still be too > complicated for long-term maintainability. > > Thanks > david jencks > > > >> From the looks of Pico I don?t think it?s that hard to get framework > >> based > >> component lifecycles working w/ adapters.� BTW Dain just as background > >> info Avalon framework is a set of interfaces and that?s all it does > >> not > >> contain any of the kernel code.� Lots of folks like these interfaces > >> whether > >> or not they support type 1, 2, or 3. > >> > >> And if you guys say Pico is the most natural fit to the way jsr 77/88 > >> lifecycles work then it should not be that hard.� I just want to > >> start looking > >> at the details where we?re sure to find the devil. > > > > I'm not sure on that. Most Geronimo components should be able to run > > in a pico container but we still have some hangups. I think > > GeronimoMBeans will be a good fit for 77 but I don't know enough about > > 88 to make a call. It will take more time to see for sure. > > > >> <snip> > >> > >> http://sourceforge.net/projects/aaaframework > > > > I'll take a look at this. > > > > -dain > > > > /************************* > > * Dain Sundstrom > > * Partner > > * Core Developers Network > > *************************/ > > > >
