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://email@example.com/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.