geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan <xhh...@gmail.com>
Subject Lifecycle mapping change between Configuration and Bundle
Date Thu, 27 Jan 2011 07:48:30 GMT
    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.
   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.
   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.

   Thoughts ? Thanks.
-- 
Ivan

Mime
View raw message