Re: [osgi-dev] ServiceComponentRuntime service

2017-02-14 Thread BJ Hargrave
Well we don't want to add another whiteboard model to track changes to the whiteboard model (e.g. Http whiteboard). Who will watch the watchers? :-D
 
Since it is somewhat of a special case to be able to track changes to the DTO set, we felt a service property holding the change count would be sufficient and it would work with the existing service event model. In DS, you can have a reference to ServiceComponentRuntime service and use the updated method for the reference to get called when the service properties change.
--BJ HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788hargr...@us.ibm.com
 
 
- Original message -From: Scott Lewis Sent by: osgi-dev-boun...@mail.osgi.orgTo: osgi-dev@mail.osgi.orgCc:Subject: Re: [osgi-dev] ServiceComponentRuntime serviceDate: Tue, Feb 14, 2017 2:45 PM 
On 2/13/2017 10:07 AM, BJ Hargrave wrote:
Not in R6. Under discussion for R7 is a service property for the ServiceComponentRuntime service which would hold a change count for the DTO set. Then whenever the DTO set changes, the service properties for the ServiceComponentRuntime service would change. So you could listen for MODIFIED service events on the ServiceComponentRuntime service if you need to track changes to the DTO set.
 
We also look to use the same service property for HttpServiceRuntime and JaxRSServiceRuntime for the same reason.Thanks for the info.   Although I don't have any objection to the service property...wouldn't there be some consumer advantages (common patterns) to also having *Listener + *Event added to the ServiceComponentRuntime package...e.g. RSA?Scott 
___OSGi Developer Mail Listosgi-dev@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev
 

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] ServiceComponentRuntime service

2017-02-14 Thread Scott Lewis

On 2/13/2017 10:07 AM, BJ Hargrave wrote:
Not in R6. Under discussion for R7 is a service property for the 
ServiceComponentRuntime service which would hold a change count for 
the DTO set. Then whenever the DTO set changes, the service properties 
for the ServiceComponentRuntime service would change. So you could 
listen for MODIFIED service events on the ServiceComponentRuntime 
service if you need to track changes to the DTO set.
We also look to use the same service property for HttpServiceRuntime 
and JaxRSServiceRuntime for the same reason.


Thanks for the info.   Although I don't have any objection to the 
service property...wouldn't there be some consumer advantages (common 
patterns) to also having *Listener + *Event added to the 
ServiceComponentRuntime package...e.g. RSA?


Scott


___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] ServiceComponentRuntime service

2017-02-13 Thread BJ Hargrave
Not in R6. Under discussion for R7 is a service property for the ServiceComponentRuntime service which would hold a change count for the DTO set. Then whenever the DTO set changes, the service properties for the ServiceComponentRuntime service would change. So you could listen for MODIFIED service events on the ServiceComponentRuntime service if you need to track changes to the DTO set.
 
We also look to use the same service property for HttpServiceRuntime and JaxRSServiceRuntime for the same reason.
--BJ HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788hargr...@us.ibm.com
 
 
- Original message -From: Scott Lewis Sent by: osgi-dev-boun...@mail.osgi.orgTo: OSGi Developer Mail List Cc:Subject: [osgi-dev] ServiceComponentRuntime serviceDate: Sun, Feb 12, 2017 4:34 PM 
In R6 chap 112 there is theorg.osgi.service.component.runtime.ServiceComponentRuntime service thatexposes (e.g) getComponentDescriptionDTO,enableComponent/disableComponent, etc.  One thing that does not seem tobe present, however, is any sort of listener/event structure forresponding to component changes.An example of what I mean by such a listener/event structure exists inthe RemoteServiceAdminListener and RemoteServiceAdminEvent (and withEventAdmin for async).Is there some other pattern for (e.g.) SCR tooling to respond to suchruntime changes?Thanks,Scott___OSGi Developer Mail Listosgi-dev@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev 
 

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev