You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Scott England-Sullivan <su...@gmail.com> on 2012/09/17 04:53:35 UTC
New Blog Article: Declarative Services with Karaf
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
Re: New Blog Article: Declarative Services with Karaf
Posted by Scott England-Sullivan <su...@gmail.com>.
Thanks for taking the time Achim. I appreciate it.
On Mon, Sep 17, 2012 at 10:57 AM, Achim Nierbeck <bc...@googlemail.com>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 <da...@yahoo.com>:
> > 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 <da...@yahoo.com>
> > 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
Re: New Blog Article: Declarative Services with Karaf
Posted by Achim Nierbeck <bc...@googlemail.com>.
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 <da...@yahoo.com>:
> 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 <da...@yahoo.com>
> 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/>
Re: New Blog Article: Declarative Services with Karaf
Posted by David Jencks <da...@yahoo.com>.
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 <da...@yahoo.com> 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 <da...@yahoo.com> 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
>
Re: New Blog Article: Declarative Services with Karaf
Posted by Scott England-Sullivan <su...@gmail.com>.
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 <da...@yahoo.com>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 <da...@yahoo.com>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
Re: New Blog Article: Declarative Services with Karaf
Posted by David Jencks <da...@yahoo.com>.
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 <da...@yahoo.com> 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
>
Re: New Blog Article: Declarative Services with Karaf
Posted by Scott England-Sullivan <su...@gmail.com>.
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 <da...@yahoo.com>wrote:
> minor quibles...
>
> you can enable inheritance processing the osgi annotations with bnd with
> the -
>
??? regarding -
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'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.
>
> 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.
>
> 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".
>
> 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
Re: New Blog Article: Declarative Services with Karaf
Posted by David Jencks <da...@yahoo.com>.
minor quibles...
you can enable inheritance processing the osgi annotations with bnd with the -
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.
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.
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.
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).
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.
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.
Nice work!!
thanks
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
>
Re: scr activate/deactivate in karaf web console?
Posted by Scott England-Sullivan <su...@gmail.com>.
The source code is available here:
https://github.com/sully6768/karaf-scr-2.2.x/tree/karaf-scr-2.2.9
Or you can follow the steps for installing the command binaries in Part 1
of the Declarative Services in Karaf
article<http://sully6768.blogspot.com/2012/09/scr-components-with-karaf-part-1.html>under
the section Installing Karaf SCR.
On Tue, Sep 25, 2012 at 10:41 AM, Andrei Pozolotin <
andrei.pozolotin@gmail.com> wrote:
> Scott: can you please share github links? Andrei.
>
> -------- Original Message --------
> Subject: Re: scr activate/deactivate in karaf web console?
> From: Scott England-Sullivan <su...@gmail.com> <su...@gmail.com>
> To: user@karaf.apache.org
> Date: Fri 21 Sep 2012 03:37:37 PM CDT
>
> Yeah, I had started looking into this a while back but had to focus on
> getting the Karaf SCR Components ready for Karaf 2.3. That will be the
> first release that will have SCR integrated into the Karaf stack. I would
> start with 2.3 when it releases (which I understand is very soon) or use
> Karaf 2.2.9 with the command components that I have available out on github.
>
> Sorry I don't have more right now. I will respond if I come up with
> something in the short term.
>
> Best Regards,
> Scott ES
>
> On Fri, Sep 21, 2012 at 11:21 AM, Scott England-Sullivan <
> sully6768@gmail.com> wrote:
>
>> Hi Andrei,
>>
>> I will take a look at see what is going on and get back with you.
>>
>>
>> On Fri, Sep 21, 2012 at 9:18 AM, Andrei Pozolotin <
>> andrei.pozolotin@gmail.com> wrote:
>>
>>> current 3.0.0-SNAPSHOT, can not find it :-)
>>>
>>>
>>> -------- Original Message --------
>>> Subject: Re: scr activate/deactivate in karaf web console?
>>> From: Scott England-Sullivan <su...@gmail.com> <su...@gmail.com>
>>> To: user@karaf.apache.org
>>> Date: Thu 20 Sep 2012 05:51:52 PM CDT
>>>
>>> Hi Andrei,
>>>
>>> It did at one time. What version are you using?
>>>
>>> On Thu, Sep 20, 2012 at 4:37 PM, Andrei Pozolotin <
>>> andrei.pozolotin@gmail.com> wrote:
>>>
>>>> Hi
>>>>
>>>> karaf console has nice commands for scr:activate / deactivate
>>>>
>>>> I am curious if there is module that provides similar features for scr
>>>> in web console?
>>>>
>>>> Thank you,
>>>>
>>>> Andrei
>>>>
>>>>
>>>
>>>
>>> --
>>> --
>>> Scott England-Sullivan
>>> Apache Camel Committer
>>> Principal Consultant / Sr. Architect | 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
>> Apache Camel Committer
>> Principal Consultant / Sr. Architect | 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
> Apache Camel Committer
> Principal Consultant / Sr. Architect | 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
Apache Camel Committer
Principal Consultant / Sr. Architect | 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
Re: scr activate/deactivate in karaf web console?
Posted by Andrei Pozolotin <an...@gmail.com>.
Scott: can you please share github links? Andrei.
-------- Original Message --------
Subject: Re: scr activate/deactivate in karaf web console?
From: Scott England-Sullivan <su...@gmail.com>
To: user@karaf.apache.org
Date: Fri 21 Sep 2012 03:37:37 PM CDT
> Yeah, I had started looking into this a while back but had to focus on
> getting the Karaf SCR Components ready for Karaf 2.3. That will be
> the first release that will have SCR integrated into the Karaf stack.
> I would start with 2.3 when it releases (which I understand is very
> soon) or use Karaf 2.2.9 with the command components that I have
> available out on github.
>
> Sorry I don't have more right now. I will respond if I come up with
> something in the short term.
>
> Best Regards,
> Scott ES
>
> On Fri, Sep 21, 2012 at 11:21 AM, Scott England-Sullivan
> <sully6768@gmail.com <ma...@gmail.com>> wrote:
>
> Hi Andrei,
>
> I will take a look at see what is going on and get back with you.
>
>
> On Fri, Sep 21, 2012 at 9:18 AM, Andrei Pozolotin
> <andrei.pozolotin@gmail.com <ma...@gmail.com>>
> wrote:
>
> current 3.0.0-SNAPSHOT, can not find it :-)
>
>
> -------- Original Message --------
> Subject: Re: scr activate/deactivate in karaf web console?
> From: Scott England-Sullivan <su...@gmail.com>
> <ma...@gmail.com>
> To: user@karaf.apache.org <ma...@karaf.apache.org>
> Date: Thu 20 Sep 2012 05:51:52 PM CDT
>> Hi Andrei,
>>
>> It did at one time. What version are you using?
>>
>> On Thu, Sep 20, 2012 at 4:37 PM, Andrei Pozolotin
>> <andrei.pozolotin@gmail.com
>> <ma...@gmail.com>> wrote:
>>
>> Hi
>>
>> karaf console has nice commands for scr:activate /
>> deactivate
>>
>> I am curious if there is module that provides similar
>> features for scr in web console?
>>
>> Thank you,
>>
>> Andrei
>>
>>
>>
>>
>> --
>> --
>> Scott England-Sullivan
>> Apache Camel Committer
>> Principal Consultant / Sr. Architect | 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 <http://sully6768.blogspot.com>
>> Twitter: sully6768
>>
>
>
>
>
> --
> --
> Scott England-Sullivan
> Apache Camel Committer
> Principal Consultant / Sr. Architect | 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 <http://sully6768.blogspot.com>
> Twitter: sully6768
>
>
>
>
> --
> --
> Scott England-Sullivan
> Apache Camel Committer
> Principal Consultant / Sr. Architect | 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 <http://sully6768.blogspot.com>
> Twitter: sully6768
>
Re: scr activate/deactivate in karaf web console?
Posted by Scott England-Sullivan <su...@gmail.com>.
Yeah, I had started looking into this a while back but had to focus on
getting the Karaf SCR Components ready for Karaf 2.3. That will be the
first release that will have SCR integrated into the Karaf stack. I would
start with 2.3 when it releases (which I understand is very soon) or use
Karaf 2.2.9 with the command components that I have available out on github.
Sorry I don't have more right now. I will respond if I come up with
something in the short term.
Best Regards,
Scott ES
On Fri, Sep 21, 2012 at 11:21 AM, Scott England-Sullivan <
sully6768@gmail.com> wrote:
> Hi Andrei,
>
> I will take a look at see what is going on and get back with you.
>
>
> On Fri, Sep 21, 2012 at 9:18 AM, Andrei Pozolotin <
> andrei.pozolotin@gmail.com> wrote:
>
>> current 3.0.0-SNAPSHOT, can not find it :-)
>>
>>
>> -------- Original Message --------
>> Subject: Re: scr activate/deactivate in karaf web console?
>> From: Scott England-Sullivan <su...@gmail.com> <su...@gmail.com>
>> To: user@karaf.apache.org
>> Date: Thu 20 Sep 2012 05:51:52 PM CDT
>>
>> Hi Andrei,
>>
>> It did at one time. What version are you using?
>>
>> On Thu, Sep 20, 2012 at 4:37 PM, Andrei Pozolotin <
>> andrei.pozolotin@gmail.com> wrote:
>>
>>> Hi
>>>
>>> karaf console has nice commands for scr:activate / deactivate
>>>
>>> I am curious if there is module that provides similar features for scr
>>> in web console?
>>>
>>> Thank you,
>>>
>>> Andrei
>>>
>>>
>>
>>
>> --
>> --
>> Scott England-Sullivan
>> Apache Camel Committer
>> Principal Consultant / Sr. Architect | 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
> Apache Camel Committer
> Principal Consultant / Sr. Architect | 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
Apache Camel Committer
Principal Consultant / Sr. Architect | 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
Re: scr activate/deactivate in karaf web console?
Posted by Scott England-Sullivan <su...@gmail.com>.
Hi Andrei,
I will take a look at see what is going on and get back with you.
On Fri, Sep 21, 2012 at 9:18 AM, Andrei Pozolotin <
andrei.pozolotin@gmail.com> wrote:
> current 3.0.0-SNAPSHOT, can not find it :-)
>
>
> -------- Original Message --------
> Subject: Re: scr activate/deactivate in karaf web console?
> From: Scott England-Sullivan <su...@gmail.com> <su...@gmail.com>
> To: user@karaf.apache.org
> Date: Thu 20 Sep 2012 05:51:52 PM CDT
>
> Hi Andrei,
>
> It did at one time. What version are you using?
>
> On Thu, Sep 20, 2012 at 4:37 PM, Andrei Pozolotin <
> andrei.pozolotin@gmail.com> wrote:
>
>> Hi
>>
>> karaf console has nice commands for scr:activate / deactivate
>>
>> I am curious if there is module that provides similar features for scr in
>> web console?
>>
>> Thank you,
>>
>> Andrei
>>
>>
>
>
> --
> --
> Scott England-Sullivan
> Apache Camel Committer
> Principal Consultant / Sr. Architect | 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
Apache Camel Committer
Principal Consultant / Sr. Architect | 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
Re: scr activate/deactivate in karaf web console?
Posted by Andrei Pozolotin <an...@gmail.com>.
current 3.0.0-SNAPSHOT, can not find it :-)
-------- Original Message --------
Subject: Re: scr activate/deactivate in karaf web console?
From: Scott England-Sullivan <su...@gmail.com>
To: user@karaf.apache.org
Date: Thu 20 Sep 2012 05:51:52 PM CDT
> Hi Andrei,
>
> It did at one time. What version are you using?
>
> On Thu, Sep 20, 2012 at 4:37 PM, Andrei Pozolotin
> <andrei.pozolotin@gmail.com <ma...@gmail.com>> wrote:
>
> Hi
>
> karaf console has nice commands for scr:activate / deactivate
>
> I am curious if there is module that provides similar features
> for scr in web console?
>
> Thank you,
>
> Andrei
>
>
>
>
> --
> --
> Scott England-Sullivan
> Apache Camel Committer
> Principal Consultant / Sr. Architect | 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 <http://sully6768.blogspot.com>
> Twitter: sully6768
>
Re: scr activate/deactivate in karaf web console?
Posted by Scott England-Sullivan <su...@gmail.com>.
Hi Andrei,
It did at one time. What version are you using?
On Thu, Sep 20, 2012 at 4:37 PM, Andrei Pozolotin <
andrei.pozolotin@gmail.com> wrote:
> Hi
>
> karaf console has nice commands for scr:activate / deactivate
>
> I am curious if there is module that provides similar features for scr in
> web console?
>
> Thank you,
>
> Andrei
>
>
--
--
Scott England-Sullivan
Apache Camel Committer
Principal Consultant / Sr. Architect | 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
scr activate/deactivate in karaf web console?
Posted by Andrei Pozolotin <an...@gmail.com>.
Hi
karaf console has nice commands for scr:activate / deactivate
I am curious if there is module that provides similar features for
scr in web console?
Thank you,
Andrei
Re: New Blog Article: Declarative Services with Karaf
Posted by Andrei Pozolotin <an...@gmail.com>.
Scott:
great; if you feel like, please also add your voice here:
https://www.osgi.org/bugzilla/show_bug.cgi?id=151
Andrei
-------- Original Message --------
Subject: Re: New Blog Article: Declarative Services with Karaf
From: Scott England-Sullivan <su...@gmail.com>
To: user@karaf.apache.org
Date: Thu 20 Sep 2012 10:55:36 AM CDT
> Thanks Andrei. Will do.
>
> On Thu, Sep 20, 2012 at 10:27 AM, Andrei Pozolotin
> <andrei.pozolotin@gmail.com <ma...@gmail.com>> wrote:
>
> Scott:
>
> you may want to link it here as resource:
> http://wiki.osgi.org/wiki/Declarative_Services
>
> Andrei
>
>
> -------- Original Message --------
> Subject: New Blog Article: Declarative Services with Karaf
> From: Scott England-Sullivan <su...@gmail.com>
> <ma...@gmail.com>
> To: user@karaf.apache.org <ma...@karaf.apache.org>
> Date: Sun 16 Sep 2012 09:53:35 PM CDT
>> 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 <http://sully6768.blogspot.com>
> Twitter: sully6768
>
Re: New Blog Article: Declarative Services with Karaf
Posted by Scott England-Sullivan <su...@gmail.com>.
Thanks Andrei. Will do.
On Thu, Sep 20, 2012 at 10:27 AM, Andrei Pozolotin <
andrei.pozolotin@gmail.com> wrote:
> Scott:
>
> you may want to link it here as resource:
> http://wiki.osgi.org/wiki/Declarative_Services
>
> Andrei
>
>
> -------- Original Message --------
> Subject: New Blog Article: Declarative Services with Karaf
> From: Scott England-Sullivan <su...@gmail.com> <su...@gmail.com>
> To: user@karaf.apache.org
> Date: Sun 16 Sep 2012 09:53:35 PM CDT
>
> 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
Re: New Blog Article: Declarative Services with Karaf
Posted by Andrei Pozolotin <an...@gmail.com>.
Scott:
you may want to link it here as resource:
http://wiki.osgi.org/wiki/Declarative_Services
Andrei
-------- Original Message --------
Subject: New Blog Article: Declarative Services with Karaf
From: Scott England-Sullivan <su...@gmail.com>
To: user@karaf.apache.org
Date: Sun 16 Sep 2012 09:53:35 PM CDT
> 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
>
Re: New Blog Article: Declarative Services with Karaf
Posted by Scott England-Sullivan <su...@gmail.com>.
Thanks for taking the time to go through it Andreas. I appreciate it.
On Sun, Sep 16, 2012 at 11:10 PM, Andreas Pieber <an...@gmail.com> wrote:
> Wow... quite an extensive blog series, Scott! Great work and congrats!
>
> Kind regards,
> Andreas
>
> On Mon, Sep 17, 2012 at 4:53 AM, Scott England-Sullivan
> <su...@gmail.com> 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
Re: New Blog Article: Declarative Services with Karaf
Posted by Andreas Pieber <an...@gmail.com>.
Wow... quite an extensive blog series, Scott! Great work and congrats!
Kind regards,
Andreas
On Mon, Sep 17, 2012 at 4:53 AM, Scott England-Sullivan
<su...@gmail.com> 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
>