inline.... On Sep 17, 2012, at 5:47 AM, Scott England-Sullivan wrote: > 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 -
gah, sorry, in bnd next anyway (I wouldn't trust the annotation support elsewhere) -dsannotations-inherit=true will give you inheritance support. You also need to specify which classes should be scanned with -dsannotations=* or list of classes > > 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 think this is a bnd extension for the moment. > > > 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. > > 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. yes. > > > 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. > > 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. the updated methods are available in felix 1.6. You just have to use the proprietary namespace http://felix.apache.org/xmlns/scr/v1.1.0-felix > > > 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". np. Thanks for taking the time to document this very useful but not well documented and often surprisingly confusing functionality! 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 >> > > > > > -- > -- > Scott England-Sullivan > ---------------------------------- > Principal Consultant | Red Hat, Inc. > FuseSource is now part of Red Hat > Web: fusesource.com | redhat.com > Blog: sully6768.blogspot.com > Twitter: sully6768 >
