minor quibles... you can enable inheritance processing the osgi annotations with bnd with the -
I'm not sure what you mean by this: If your service needs to be realized immediately you can do so by adding the immediate attribute set to true on the @Component annotation. For instance if you want to activate a component that does implement an interface but isn't considered a service you will need to add this attribute. Components that are not registered as services have to be immediate, as there is no other way their creation could ever get triggered. Only components registered as services can be (meaningfully) marked as immediate. This seems slightly misleading to me, but I might be nitpicking: Back in Part 1 you may remember that the GreeterService was in an Active state after it was installed. This was due to there being an active consumer of the service in the container, the GreeterComponent. Since the GreeterComponent was in an Active state, the containers SCR instance created an instance of the GreeterService and injected into our GreeterComponent. GreeterService is a mandatory dependency for GreeterComponent. Therefore GreeterComponent cannot be active until its dependency is satisfied, that is there is an active GreeterService. Since all your components are enabled, GreeterService is activated, registering the ServiceRegistration. Then GreeterComponent is satisfied, so it is activated and, being immediate (not a service) the implementation object is created. Since the dependency uses the service object rather than a service reference, the GreeterService is instantiated so it can be injected into the GreeterComponent. I hope this makes bnd generate an error for non-service components: Again, this can be overridden if you need to by adding the immediate attribute set to false on the @Component annotation. As noted above, if you could do this your component would never get activated. I don't understand what behavior you are discussing here: So what happened? Before when we only had the activate & deactivate method defined the activate & deactivate life-cycles were used to manage all updates of the component. This allowed our components to de/activate cleanly. When the component is configured with the modified life-cycle the SCR will only call the modified method which never causes the ManagedGreeterService to become UNSATISFIED. Therefore any component with a dependency on the ManagedGreeterService is never notified that there has been a change in the state of the component and they continue upon their merry way oblivious to the changes. If you delete the configuration, DS should deactivate your compnent using the configuration (it's required). If its modified, if there's a modify method that will be called, otherwise the component will be deactivated and reactivated with the new configuration. If you want a component with a reference to a service configured via config admin to be notified when the configuration changes, you can use an updatedFoo lifecycle method (this is a proprietary extension in felix 1.6 and included in the DS 1.2 spec). BTW I suggest you clarify that what you are calling managed services are NOT ManagedService instances. I think this is why the spec doesn't call them managed services. I have yet to find a use for ComonentFactories, but you leave out the extremely useful (to me :-) use of config admin to create multiple instances of a component using a factory.pid. To me the best analogy for ComponentFactory is that it's like using config admin with a factory pid, but your code takes over the role of config admin, supplying and removing the configurations. Nice work!! thanks david jencks On Sep 16, 2012, at 7:53 PM, Scott England-Sullivan wrote: > Hello All, > > Just finished and published a 4 part series on Declarative Services with > Karaf. Its is a primer on both DS and how it behaves with the new Karaf SCR > Command Components. > > Comments and questions welcome. > > Best Regards, > Scott ES > > Declarative Services with Karaf http://bit.ly/QShfyY > > -- > -- > Scott England-Sullivan > ---------------------------------- > Principal Consultant | Red Hat, Inc. > FuseSource is now part of Red Hat > Web: http://www.fusesource.com | http://www.redhat.com > Blog: http://sully6768.blogspot.com > Twitter: sully6768 >
