geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Lifecycle mapping change between Configuration and Bundle
Date Thu, 27 Jan 2011 08:47:01 GMT
Hi Ivan,

Thanks for doing this great work and pursuing the discussion.  While I hope we can move completely
away from gbeans, that work will take some time and I think having this in place will make
moving to more pure-osgi services much easier.  I may have more to say later but have a couple
thoughts now, inline.
On Jan 26, 2011, at 11:48 PM, Ivan wrote:

>     In the past weeks, I worked on the lifecycle mapping change between Configuration
and Bundle, some background info could be find : http://www.mail-archive.com/dev@geronimo.apache.org/msg83998.html
>     A draft patch is attached to GERONIMO-5761, not the final one, might need much work,
especially the admin console. With the patch, now some car packages are left as resovled state,
e.g. client related moduels. with this, we would never get duplicate naming services.
>     
>     I noticed that David was working on some Karaf features refactoring, and I have not
checked the detailed information now, guess that it is something similar with Geronimo plugin
system, but more OSGi friendly. So before I continued to work on it, I hope to get comments
from the dev community. Maybe we would not need this change since we would finally turn to
Karaf features based arch or someone could help to figure out whether there is a better solution.

So far the karaf work has brought some of the plugin install capabilities to karaf so there's
a convenient way to install a lot of bundles at once.  It doesn't have anything to do with
services in the bundles.  I think we'll be able to replace the list of dependencies in a plugin
with the karaf feature xml.  However I'm not sure it will be worth converting our plugins
to features-with-gbeans and then again to features-without-gbeans; it might make more sense
to do both conversions at once.

>    But I would like to address some interesting issues while working on it, and I guess
that we might need to handle them even if we turn to other arch.
>    a. An extender named ConfigurationExtender is added to load configuration data from
car file, while we use the activator in the past. With this extender, we could free the activator
configuration, so that the users could configure their own activators, also I feel that this
style is less aggressive. The issue is that the extender needs to implement SynchronousBundleListener,
or the ConfigurationManager may not get the configuration data in the correct time slot. But
the problem is that the events are delivered to the listener out of order, so I have to recursively
load the configuration based on the geronimo-plugin.xml.   
>    b. After the first start, all the bundles are cached, so we would never receive the
installed event and resolved event, so many codes are required to handle this correctly. 

If I remember correctly the problem here is that we want a state in which the gbean metadata
is available but the gbeans aren't started.  I can remember two situations where this is useful:

1. verifying gbean references between modules at deploy time.
2. getting activation spec info out of  resource adapter that isn't running.  I don't know
if openejb is actually using this, I think it may not be.  Let's assume this isn't a problem.

for (1), we might either be
1.a just verifying that all gbean references will be satisfied.  We could just stop verifying.
1.b. looking to complete gbean query information.  If the gbean we are looking for is in the
same module/bundle as the one with a reference, we'll have all the info we need already. 
If it's in a different bundle, I think we can probably determine the correct query without
actually looking up the gbean.

So I wonder if during deployment we can just resolve the runtime bundles so the classes are
available but completely not load the gbean metadata.  What do you think?

If this doesn't work, we might also be able to put enough of the gbean metadata in a service
reference so we could use osgi's ability to supply service references without starting the
service.  I think this would require us to register all or most of the gbeans as services
which I would rather avoid.

>    c. Usually, most bundles are ready for classloading once they are in the resolved
state, but some not :-(. e.g. all of our spec api and impl packages, as we use OSGi service
to look up providers. So I add an "eagerstart" flag, 
>    ....
> 
>   Something needs to improve 
>   a. In our deployment system, we are depending on the Configuration instance for adding
GBeans, but after the lifecycle change, we would not have that, since all the GBean is created
while the configuration is started, some hack codes were added to make it work.
>   b. The module states are lost in many places, we need to consider it carefully later,
maybe we could combine it with dependeny manager in some ways.
>   c. Consider how the repository should work, in current codes, it almost lost its value.

Do you mean the maven-structured repository we deploy bundles and plugins in to?  I have also
been wondering if this is of any use or if we can just install bundles directly into the osgi
framework.

thanks!!!

david jencks

>    
>    Thoughts ? Thanks.   
> -- 
> Ivan


Mime
View raw message