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.
>> 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.
>
>
> yes.
>
>
>
>>
>> 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.
>
>
> 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 <http://www.fusesource.com/> |
> redhat.com<http://www.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 <http://www.fusesource.com> |
redhat.com<http://www.redhat.com>
Blog: sully6768.blogspot.com
Twitter: sully6768
