Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 10948 invoked from network); 28 Jan 2011 02:13:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 28 Jan 2011 02:13:26 -0000 Received: (qmail 87688 invoked by uid 500); 28 Jan 2011 02:13:26 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 87589 invoked by uid 500); 28 Jan 2011 02:13:25 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 87556 invoked by uid 99); 28 Jan 2011 02:13:25 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 28 Jan 2011 02:13:25 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of xhhsld@gmail.com designates 209.85.214.182 as permitted sender) Received: from [209.85.214.182] (HELO mail-iw0-f182.google.com) (209.85.214.182) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 28 Jan 2011 02:13:20 +0000 Received: by iwn39 with SMTP id 39so2693187iwn.13 for ; Thu, 27 Jan 2011 18:12:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=xJ2yS1FQt5c5D8aEBddFi2vjngG/a2/knCpV4JDtUm0=; b=efaZumdJJBf1rbx1oDKAu6Y17znSLuK6X0MAuFOiWHr9Ojtkeckb+LbYBqmkvGmn1f iR4Vrd8GWkbxUKxSetUufhGO1KrUR16HUhDhg+OmS7xIPxSLxI9wsVcM1yS4ZCW3oV7Z lJ4uCcd9EmnC5W9BwvPOgVhjMPz5RDF4UP3n0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=skwI4c8gGgEsLrWitSQ8tnTVt7JIXv0PuIixXqXAa7a8/JqENHOmJ4UaZaShBKYSN3 E+SxQ+i83Mk8V0pLG2OhUOv81+tAOBCzWst7j7hGiNbqnfG8Il3YBh3h6RIWSXzD+qVj m0jdBJhwD6xGff73ac3yRXdt+iXPi5P+fUWBM= MIME-Version: 1.0 Received: by 10.231.38.10 with SMTP id z10mr1930179ibd.107.1296180779733; Thu, 27 Jan 2011 18:12:59 -0800 (PST) Received: by 10.231.148.142 with HTTP; Thu, 27 Jan 2011 18:12:59 -0800 (PST) In-Reply-To: <245D0729-1B14-4038-8B8D-F47FB19E3E56@yahoo.com> References: <245D0729-1B14-4038-8B8D-F47FB19E3E56@yahoo.com> Date: Fri, 28 Jan 2011 10:12:59 +0800 Message-ID: Subject: Re: Lifecycle mapping change between Configuration and Bundle From: Ivan To: dev@geronimo.apache.org Content-Type: multipart/alternative; boundary=0022152d5fcdf0d453049ade9ad6 --0022152d5fcdf0d453049ade9ad6 Content-Type: text/plain; charset=ISO-8859-1 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 : > 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. > > > 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 > > > -- Ivan --0022152d5fcdf0d453049ade9ad6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks, David.

2011/1/27 David Jencks <david_jencks@y= ahoo.com>
Hi Ivan,

Thanks fo= r doing this great work and pursuing the discussion. =A0While I hope we can= move completely away from gbeans, that work will take some time and I thin= k having this in place will make moving to more pure-osgi services much eas= ier. =A0I may have more to say later but have a couple thoughts now, inline= .
On Jan 26, 2011, at 11:48 PM, Ivan wrote:
=
=A0=A0=A0 In the past weeks, I worked on the = lifecycle mapping change between Configuration and Bundle, some background = info could be find : http://www.mail-arch= ive.com/dev@geronimo.apache.org/msg83998.html3D""
=A0=A0=A0 A draft patch is attached to GERONIMO-5761, not the final one, mi= ght 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.
=A0=A0=A0
=A0=A0=A0 I noticed that David was working on some Karaf feat= ures refactoring, and I have not checked the detailed information now, gues= s that it is something similar with Geronimo plugin system, but more OSGi f= riendly. So before I continued to work on it, I hope to get comments from t= he dev community. Maybe we would not need this change since we would finall= y turn to Karaf features based arch or someone could help to figure out whe= ther there is a better solution.

So far the karaf work has brought so= me of the plugin install capabilities to karaf so there's a convenient = way to install a lot of bundles at once. =A0It doesn't have anything to= do with services in the bundles. =A0I think we'll be able to replace t= he list of dependencies in a plugin with the karaf feature xml. =A0However = I'm not sure it will be worth converting our plugins to features-with-g= beans and then again to features-without-gbeans; it might make more sense t= o do both conversions at once.

=A0=A0 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.
=A0=A0 a. An extender named ConfigurationExtender is added to loa= d 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 Synchro= nousBundleListener, or the ConfigurationManager may not get the configurati= on data in the correct time slot. But the problem is that the events are de= livered to the listener out of order, so I have to recursively load the con= figuration based on the geronimo-plugin.xml.=A0=A0
=A0=A0 b. After the first start, all the bundles are cached, so we would ne= ver receive the installed event and resolved event, so many codes are requi= red to handle this correctly.=A0

= If I remember correctly the problem here is that we want a state in which t= he gbean metadata is available but the gbeans aren't started. =A0I can = remember two situations where this is useful:

1. verifying gbean references between modules at deploy= time.
2. getting activation spec info out of =A0resource adapter= that isn't running. =A0I don't know if openejb is actually using t= his, I think it may not be. =A0Let's assume this isn't a problem.

for (1), we might either be
1.a just verifyin= g that all gbean references will be satisfied. =A0We could just stop verify= ing.
1.b. looking to complete gbean query information. =A0If the = gbean we are looking for is in the same module/bundle as the one with a ref= erence, we'll have all the info we need already. =A0If it's in a di= fferent 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 th= e runtime bundles so the classes are available but completely not load the = gbean metadata. =A0What do you think?

If this does= n'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 re= ferences without starting the service. =A0I think this would require us to = register all or most of the gbeans as services which I would rather avoid.<= /div>

=A0 =A0 Yes, that is an annoying is= sue while changing the mapping. Now, I hacked in the DeploymentConfiguratio= nManager to make the configuration started, but those sub gbeans are not st= arted, and certainly it is a temporary solution.
=A0=A0=A0 I think that the verification is required, as it is better for us= ers 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 Config= urationData, as all the gbean meta information should be found there., whil= e exposing the verification function via OSGi is a good idea.
=A0

=A0=A0 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 pa= ckages, as we use OSGi service to look up providers. So I add an "eage= rstart" flag,
=A0=A0 ....

=A0 Something needs to improve
=A0 a. In our deploym= ent system, we are depending on the Configuration instance for=20 adding GBeans, but after the lifecycle change, we would not have that,=20 since all the GBean is created while the configuration is started, some=20 hack codes were added to make it work.
=A0 b. The module states are lost= in many places, we need to consider it carefully later, maybe we could com= bine it with dependeny manager in some ways.
=A0 c. Consider how the rep= ository should work, in current codes, it almost lost its value.

Do you mean the maven-structured reposito= ry we deploy bundles and plugins in to? =A0I have also been wondering if th= is is of any use or if we can just install bundles directly into the osgi f= ramework.

=A0=A0 Yes, it might be the same topic. I= remembered that there was similar discussion in the past, from my side, th= e most concern is the stability of the OSGi cache, and we have a reported i= ssue 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 r= epository as the data area, and I remembered that Jarek had figured out the= re is a SPI for Equonix.

=A0=A0 Another question is that, whether we would need the conception o= f 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, may= be 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 ?

=A0 If the lifecycle mapping makes sense, I would continue to make othe= r 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 m= y hometown for the spring festival vacation soon, and might loss the connec= tion to the Internet.
=A0

thanks!!!
<= div>
david jencks

=A0=A0
=A0=A0 Thoughts ? Thanks. =A0
--
Ivan




--
Ivan
--0022152d5fcdf0d453049ade9ad6--