Hi, Alright. Thanks for the feedback. I almost thought it would be something like the PID mismatch.
Regards Felix Am Dienstag, den 07.08.2007, 13:46 +0100 schrieb Jan Stette: > Thanks for all your replies. We have now succeeded in getting > configuration passed in to activate(), the issue was simply that our > component names didn't match up with the PIDs used by the config admin > service... > > We're still having some issues with declarative services, in > particular with individual services being registered and/or activated > multiple times. I can't see any circumstance where a valid DS > implementation should register a component with a single name several > times, though I guess it's possible we are doing something wrong > somewhere to trigger this condition. In other words, the > implementation may just not handle invalid usage very well. But > that's something we'll try to debug, then follow up with the > implementors... > > Thanks again, > Jan > > > On 02/08/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Hi Jan, > > Am Mittwoch, den 01.08.2007, 22:55 +0100 schrieb Jan Stette: > > We've had a quick look at getting the Apache Felix DS > implementation > > going on Equinox as well, but with no luck so far. > > As the implementor of the Apache Felix Configuration Admin > implementation as well as the respecitve integration into > Apache Felix > DS, I can tell, that Apache Felix DS works as specified: When > a > component ist being activated and has an activate method, the > Configuration Admin configuration is supplied as part of the > ComponentContext properties. As soon as the Configuration is > updated in > the Configuration Admin, the service component runtime takes > down the > respective component and recreates it with the new > configuration. > > If you have any Apache Felix specific question regarding the > Apache > Felix implementations of the Configuration Admin Service and > Declarative > Components Specifications, please followup on the respective > Apache > Felix lists. Thank you very much. > > We are using this combo at our place with great success and I > am eager > to fix eventual bugs :-) > > Hope this helps. > > Regards > Felix > > > > > Regards, > > Jan > > > > > > On 01/08/07, BJ Hargrave <[EMAIL PROTECTED]> wrote: > > The goal with DS and its ConfigAdmin support was to > relieve > > the component > > programmer of having to interact directly with > ConfigAdmin. > > The > > configuration properties would be present in the > component > > properties when > > the component was activated. Thus a component does > not have to > > implement > > ManagedService and respond to update calls. If the > > configuration > > information in ConfigAdmin is changed (by some > configurator), > > then SCR (DS > > runtime) will deactivate the component and then > create and > > activate the > > component again with the new configuration data in > the > > component > > properties. From secion 112.7: > > > > "SCR must track changes in the Configuration objects > used in > > the component > > properties of a component configuration. If a > Configuration > > object that > > is related to a component configuration changes, > then SCR must > > deactivate > > that component configuration and, if the > Configuration object > > was not > > deleted, SCR must attempt to reactive the component > > configuration with > > the updated component properties." > > > > > > -- > > > > BJ Hargrave > > Senior Technical Staff Member, IBM > > OSGi Fellow and CTO of the OSGi Alliance > > [EMAIL PROTECTED] > > > > office: +1 386 848 1781 > > mobile: +1 386 848 3788 > > > > > > > > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > http://www2.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
