Hi Jeff, Thanks for nudging me to try to answer some of these questions. I've been meaning to for a long time.
First of all, in my mind, most of the basic infrastructure in geronimo trunk is in a temporary state of transition. My eventual goals include - using osgi services for all inter-component wiring - eliminating gbeans and the geronimo kernel - wiring objects together in what is now a plugin using either blueprint or custom code adapted to Declarative Services - use of config admin instead of artifact_aliases.propertes and config-substitutions.properties and config.xml - using karaf features to install dependencies - using OBR much more extensively - consider relying on the bundles installed into the framework instead of the "source" bundles in our repository directory At a slightly higher level I think that most of our ee support would benefit from using a strategy like openejb with basically a single component per module that includes an info tree that describes all the stuff for that module. For example, openejb could have one component (currently a gbean) that contains the info tree for all the ejbs in the module. Web apps could be converted to one component (again currently a gbean) that has an info tree for the entire web app. However, we aren't there yet and I think we want to get pretty complete ee support in place before changing the fundamental architecture yet again. On Aug 11, 2010, at 2:36 AM, chi runhua wrote: > Hi devs, > > I'm trying to sort out how the geronimo plugin works in 3.0 and what the > differences are comparing to the ones in the previous version. After reading > some code and JIRAs, I'm quite confused...., such as > * is a geronimo-plugin.xml file required any longer? yes. It has two essential purposes at the moment: - act like a karaf features descriptor and tell what other dependencies need to be installed for this plugin - act like a config admin descriptor and install stuff into config.xml, config-substitutions.properties and artifact_aliases.properties > * what's relationship between a geronimo plugin and an OSGi bundle? A > plugin is a bundle actually now? All plugins are bundles. I think there's still some xml in a plan that has no effect that describes our previous classloading strategy (hidden-classes, non-overridable-classes, etc). However you can specify explicit import-package and export-package (to extend what we generate automatically) The plugins that we build to construct the server out of only have configuration in them, no classes. This seems to be an unusual strategy for osgi, where people usually seem to have blueprint bundles with both classes and configuration. I'm not sure what I think about trying to combine classes and configuration. It seems to me that it makes use of the classes much more restricted, although it does allow much more encapsulation. > * How to expose services from a geronimo plugin? You can get any gbean into the osgi service registry with a little bit of configuration: - use the org.apache.geronimo.gbean.annotation.OsgiService annotation on the gbean class. If desired you can specify the exposed service interfaces in this annotation. - if desired have the gbean implement org.osgi.framework.ServiceFactory - you can add service interfaces and service properties to the GBeanData. At the moment you can only do this in code in a builder but if there's a reason we could add xml for this. > * What purpose does a repository.xml in a geronimo-plugin package serve? Geronimo has an OBR instance that is mostly used for aries EBA deployment right now. Currently it is set up from scanning the repository directory in the server. I'm not sure this reliance on the actual repository directory is a good idea. My idea is that each plugin (or karaf feature) should have a repository.xml for its dependencies and that all of these should get merged together in the geronimo OBR. The repository.xml is a first step towards trying this out to see if it is workable. > * How to manage the Lifecyle of a geronimo plugin? One of the bad fits between geronimo and osgi is that our plugins have an additional lifecycle state beyond the bundle being started, namely having the gbeans started. Theoretically we can eliminate this problem by using lazy service activation for osgi services. One difference is that starting gbeans in a plugin is done through and explicit command and lazy service activation occurs whenever something requests the service. We may have to be careful to be sure that deployment work doesn't start runtime services, e.g. processing a web app to fill out its deployment info doesn't start a web connector. So, right now you have to use the geronimo ConfigurationManager to manage the state of a plugin. Hopefully this will help :-) thanks david jencks > ........ > > Could anyone shed some light on me? > > Thanks a lot. > > Jeff
