> 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.
Of course, I don't know your situation in great detail but maybe what your experiencing is due to the binding policy of your references. ... <reference policy="static" /> vs. <reference policy="dynamic" /> On 8/7/07, BJ Hargrave <[EMAIL PROTECTED]> wrote: > If the pid is a factory configuration, then the component will be > activated once for each configuration of the factory. > -- > > 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 > > > > > "Jan Stette" <[EMAIL PROTECTED]> > Sent by: [EMAIL PROTECTED] > 2007-08-07 08:46 > Please respond to > OSGi Developer Mail List <[email protected]> > > > To > "OSGi Developer Mail List" <[email protected]> > cc > > Subject > Re: [osgi-dev] Declarative Services and Configuration Admin > > > > > > > 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 > -- Alexander Horn http://www2.truman.edu/~ah428 _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
