Hi, Stoyan Boshev schrieb: >> OK, here is the difference, as short as I can describe it: >> >> 1. Felix implementation of ComponentFactory provides also a >> ManagedServiceFactory interface and self-registers as a >> ManagedServiceFactory (thus recieving Configuration objects from >> ConfigurationAdmin) >> http://svn.apache.org/viewvc/felix/trunk/scr/src/main/java/org/apache/felix/scr/impl/ComponentFactoryImpl.java?view=markup >> >> >> 2. Equinox implementation does no such thing (I haven't found any >> occurence of "ManagedServiceFactory" in related files) >> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.equinox/compendium/bundles/org.eclipse.equinox.ds/src/org/eclipse/equinox/internal/ds/impl/ComponentFactoryImpl.java?root=RT_Project&view=markup >> >> >> What I need is the behavior #1. What I want to know is which behavior >> is "right" according to the specification. If Felix is right, then I >> think we should post a bug to Equinox. If not - post a bug to OSGi >> Specification asking to clarify this matter (or add the description of >> Felix's behavior - 'cause I think it is completely logical) > > Equinox and Felix DS implementations are both correct. They just do one > thing in different ways. Equinox DS implementation is using a > ConfigurationListener to listen for configuration changes. > Since there is no difference in the functional behavior I think this is > not a bug either in the OSGi specification or in any of the DS > implementations. > Originally I thought you have had functional problems with Equinox DS, > that's why I asked for more details. Did you actually experience any > functional problems with Equinox DS? I am referring to your explanation: > "I however use Equinox and when I switched the SCR (or DS) package back > to equinox it just stopped working the way it did (and the way I want)"
Just an idea, not sure how it works out ... At one time I also used the ConfigurationListener approach in Felix SCR, but I missed quite a few configurations. The problem with the listener approach is, that the listener is only notified if a configuration has been changed. If a listener is registered _after_ the configuration has already been created, the listener is never notified. So you have to ask for these configurations first. For ManagedService[Factory] services things are different: Whenever such a service is registered, the ConfigurationAdmin service has to provide whatever it has: If it has nothing (in the case of a ManagedService), it has to call the ManagedService with nothing. If it has anything, it must call the services accordingly. Thus, because using the ManagedService[Factory] approach is simpler from the perspective of SCR, I ended up using this in Felix SCR. Of course the price is the number of services registered -- regardless of whether there will ever be configuration or not. I think the next spec revision might bring some relief in that a component may declare, that it is not interested in configuration and thus a ManagedService[Factory] registration is not needed. Hope this helps. Regards Felix _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
