David, Thanks for all the notes! I really appreciate your taking the time to go over it all so thoroughly.
I have questions, comments and clarifications inline. Thanks again, Scott On Mon, Sep 17, 2012 at 1:13 AM, David Jencks <[email protected]>wrote: > minor quibles... > > you can enable inheritance processing the osgi annotations with bnd with > the - > ??? regarding - When did BND start supporting inheritance of the annotated components? Also, I thought that it was still be discussed over at the OSGi Alliance. > > 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. F**or > 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. > I think I need to rewrite this. I am discussing a "delayed component" (a component that implements an interface) and that it can be forced to be an immediate component. Components that implement an interface, using the BND annotations, defaults to delayed. > > This seems slightly misleading to me, but I might be nitpicking: > Back in Part > 1<http://sully6768.blogspot.com/2012/09/scr-components-with-karaf-part-1.html>you > may remember that the GreeterService was in an > *Active<http://sully6768.blogspot.com/2012/09/scr-components-with-karaf-part-1.html#active_components> > * 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.* > It doesn't but I see your point on this one. I will rewrite/remove within the context. > 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. > > Basically what you said below but you said it better. :) I just wanted to call attention to the difference in behaviors especially for users that are new to DS. I will take a look at clarifying the text though. > 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). > I didn't introduce anything that wasn't in the 4.2 spec since that is all that is what is supported today. Once Felix 1.8 is available I am going to update the Karaf 2.3 code base and will reflect the changes at that time. > > 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. > > Excellent point. Will edit to clarify the difference. > 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. > That is what I was hinting at with my final comments. There are so many great use cases but I just needed to get this published as I have been staring at it for a week now. :) I think that my next series which covers using Camel with DS & Karaf I will be able to illustrate a more robust set of use cases. > > Nice work!! > thanks > david jencks > > Thanks again for the taking the time to play "editor". > > 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 > > > -- -- Scott England-Sullivan ---------------------------------- Principal Consultant | Red Hat, Inc. FuseSource is now part of Red Hat Web: fusesource.com <http://www.fusesource.com> | redhat.com<http://www.redhat.com> Blog: sully6768.blogspot.com Twitter: sully6768
