Hi Scott,
I have been away from maven for a while :-). I'm not sure what bnd the
maven-bundle-plugin is using, nor when bnd was last released. All I know is
that the bnd next branch supports stuff like
-dsannotations: *
-dsannotation-inherited: true
I'd guess bnd hasn't been released recently enough??? I'm afraid I'm losing
track of all these projects :-(
maybe you can build bnd yourself and update the maven-bundle-plugin to use it?
thanks
david jencks
On Sep 17, 2012, at 11:20 AM, Scott England-Sullivan wrote:
> Hi David,
>
> Is there an example of how to use the BND flags -dsannotations=* and
> -dsannotations-inherited=true flags with the BND annotations? Is it a
> specific version of BND or the Maven Bundle Plugin?
>
> I created a simple abstract component which contained @Reference set/unset
> methods for the Concrete @Component class. When I review the generated
> component.xml files in the bundle though there isn't a generated reference
> element.
>
> My pom.xml maven-bundle-plugin config:
>
> <plugin>
> <groupId>org.apache.felix</groupId>
> <artifactId>maven-bundle-plugin</artifactId>
> <extensions>true</extensions>
> <inherited>true</inherited>
> <configuration>
> <instructions>
> <Export-Package>
> ${project.artifactId}
> </Export-Package>
> <Import-Package>
> !${project.artifactId},
> *
> </Import-Package>
> <Private-Package>
> ${project.artifactId}.component,
> ${project.artifactId}.impl
> </Private-Package>
> <Service-Component>*</Service-Component>
> <_dsannotations>*</_dsannotations>
>
> <_dsannotations-inherited>true</_dsannotations-inherited>
> <!--
> <_dsannotations-inherit>true</_dsannotations-inherit> -->
> <!-- <_dsannotations> -->
> <!--
> org.apache.karaf.scr.examples.component.factories.component.AbstractManager,
> -->
> <!--
> org.apache.karaf.scr.examples.component.factories.component.GreeterServiceFactoryManager
> -->
> <!-- </_dsannotations> -->
> </instructions>
> </configuration>
> </plugin>
>
>
>
> On Mon, Sep 17, 2012 at 10:33 AM, David Jencks <[email protected]> wrote:
> 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
>>
>
>
>
>
> --
> --
> 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
>
