geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan <>
Subject Re: Lifecycle mapping change between Configuration and Bundle
Date Fri, 28 Jan 2011 02:12:59 GMT
Thanks, David.

2011/1/27 David Jencks <>

> 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 :
>     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.

    Yes, that is an annoying issue while changing the mapping. Now, I hacked
in the DeploymentConfigurationManager to make the configuration started, but
those sub gbeans are not started, and certainly it is a temporary solution.
    I think that the verification is required, as it is better for users to
receive the errors in the deployment process, not the start up time. My
initial idea is to move the deployment API from Configuration to
ConfigurationData, as all the gbean meta information should be found there.,
while exposing the verification function via OSGi is a good idea.

>    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.

   Yes, it might be the same topic. I remembered that there was similar
discussion in the past, from my side, the most concern is the stability of
the OSGi cache, and we have a reported issue recently for the OSGi metadata
is not serialized correctly with a hard stop of the server. The better way
is that OSGi framework could take our repository as the data area, and I
remembered that Jarek had figured out there is a SPI for Equonix.

   Another question is that, whether we would need the conception of
ConfigurationStore, as now we feed the configuration data directly to the
configuration manager in the extender or activator, and currently a map is
kept in the configuration manager. If we still use configurationStore, maybe
we need to move that map to it, and we might just call install method on the
ConfigurationStore in the extender, for configuration manager, it just loads
the data from the configuration store. Thoughts ?

  If the lifecycle mapping makes sense, I would continue to make other
components (like admin console) to adapt the changes, and provide a solid
patch. But that might be more than one week later, as I would be back to my
hometown for the spring festival vacation soon, and might loss the
connection to the Internet.

> thanks!!!
> david jencks
>    Thoughts ? Thanks.
> --
> Ivan


View raw message