geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: making JSR 77 / 88 reusable for component authors (& container developers)
Date Mon, 01 Dec 2003 19:38:50 GMT

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.

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>
> I'll take a look at this.
> -dain
> /*************************
>  * Dain Sundstrom
>  * Partner
>  * Core Developers Network
>  *************************/

View raw message