Hi, I read across the blog, I like it :) now we just need to make sure we link to it from our Karaf community Page [1]
regards, Achim [1] - http://karaf.apache.org/index/community/articles.html 2012/9/17 David Jencks <[email protected]>: > 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 > > -- Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project Lead blog <http://notizblog.nierbeck.de/>
