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 *************************/
