Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (athena.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer;
  b=sPKGRsFIK0QTZRUio8q06yxbI3pygbfrIF0sDIO0ZsRU6qNF828Mn9voYNWaLxcahgrFpvv+C9P/Gz/9+9sHf4+1VZjhR+dYi33+s+Eox4mZCpILtFCewnXtGG0NM4nWbYF71+1/snCDyWytc08zTUMZtbRCRS6xw5vuhdlK9CY=
  ;
Message-Id: <C07B04FD-2622-4E40-B7B1-13F6D278274E@yahoo.com>
From: David Jencks <david_jencks@yahoo.com>
To: dev@geronimo.apache.org
In-Reply-To: <fbab58220911050717i4ad32fduce7a4e72e47a152b@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: Eliminate the ConfigurationActivator from geronimo bundles?
Date: Thu, 5 Nov 2009 08:12:59 -0800
References: <fbab58220911050717i4ad32fduce7a4e72e47a152b@mail.gmail.com>


On Nov 5, 2009, at 7:17 AM, Rex Wang wrote:

> IIUC, from the current design, the ConfigurationActivator will be  
> imported by *EVERY* geronimo plugin to help de-serialize the  
> config.ser into configurationData while starting. This might not be  
> a best practise in doing such things.
> From what I see, the extender model recommended by osgi allaince is  
> a better choice. That is the new Geronimo kernel can be considered  
> as a Geronimo extender to deal with geronimo bundles, which is  
> fairly similar with the relationship between blueprint extender and  
> blueprint bundles. So if we leverage a bundle tracker to track  
> geronimo bundles, the bundle context and resources(i.e. config.ser)  
> can be easily retrieved when the bundle starting. (Just like what  
> dependencyManager does when install bundles. //But why read geronimo- 
> plugin.xml instead of config.ser there?) Then geronimo extender can  
> construct a configurationData from the config.ser of the geronimo  
> bundle and maintain a map of them. That is just the same with the  
> blueprint extender creating a bluepirntContainer object from OSGi- 
> INF/blueprint/*.xml for each blueprint bundle.
> Did I miss anything or is there any particular difficulty so that we  
> have to use an activator? if not, I'd like to open a jira against it.

I this would work but I don't see any advantage.  With blueprint, you  
are using plain java classes and don't need any osgi specific classes  
available to the bundle.  On the other hand gbeans are considerably  
more intrusive, you need either the gbean annotations or a GBeanInfo  
object, so we have to import a bunch of geronimo classes anyway, so  
there's no harm in using a geronimo specific bundle activator class too.

I think there is a significant chance we might decide to try to stop  
using gbeans for geronimo stuff and use blueprint instead so I would  
rather focus on getting everything working with the existing kernel  
code unless we find actual problems.

I'm reluctant to combine DependencyManager with the functionality of  
ConfigurationActivator since it seems to me that DependencyManager is  
very very similar to karaf features and possibly rfp 121 so we might  
be able to work towards combining them.

thanks
david jencks

>
> -Rex