David, really appreciate your detailed comments. I might need a little bit more time to fully digest those information.
Will ping this thread if I have any other questions. Jeff On Thu, Aug 12, 2010 at 3:41 AM, David Jencks <[email protected]>wrote: > 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 > >
