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
