Thanks for taking the time Achim. I appreciate it. On Mon, Sep 17, 2012 at 10:57 AM, Achim Nierbeck <[email protected]>wrote:
> 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/> > -- -- 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
