[
https://issues.apache.org/jira/browse/OAK-3815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15085125#comment-15085125
]
Chetan Mehrotra edited comment on OAK-3815 at 1/6/16 7:30 AM:
--------------------------------------------------------------
bq. Ok then... but wouldn't it be simpler to check whether a returned list of
services differ from a previous one and only rebuild the data structure in that
case
Can be done but then this would need to done in all places where derived data
structure is being used. Another way would be to avoid use of Tracker (as
dynamics only apply for OSGi case) and handle it in a different way. Can be
done but would involve bit of boiler plate code as we have 2 such services and
with SCR need to add all those bind/unbind methods and handle the update case
bq. With the callback based solution I'm a bit concerned re. the subtle issues
which come along with it (aka callback hell).
Yes that is possible but then this is similar to ServiceTracker itself which is
callback when services are registered.
bq. Your implementation calls it from within the register / unregister methods.
Technically registration / unregistration is not complete at this point, so
what would you expect from a call to getServices at this point?
That we can ensure in implementation and say that once callback is invoked the
{{getServices}} call would reflect the updated state. Or we can pass the
updated list as part of callback call itself. This would avoid any reverse
invocation to Tracker from within the callback implementation
was (Author: chetanm):
bq. Ok then... but wouldn't it be simpler to check whether a returned list of
services differ from a previous one and only rebuild the data structure in that
case
Can be done but then this would need to done in all places where derived data
structure is being used. Another way would be to avoid use of Tracker (as
dynamics only apply for OSGi case) and handle it in a different way. Can be
done but would involve bit of boiler plate code as we have 2 such services and
with SCR need to add all those bind/unbind methods and handle the update case
bq. With the callback based solution I'm a bit concerned re. the subtle issues
which come along with it (aka callback hell).
Yes that is possible but then this is similar to ServiceTracker itself which is
callback when services are registered.
bq. Your implementation calls it from within the register / unregister methods.
Technically registration / unregistration is not complete at this point, so
what would you expect from a call to getServices at this point?
That we can ensure in implementation and say that once callback is invoked the
{{getServices}} call would reflect the updated state.
> Add refresh callback support to Tracker
> ---------------------------------------
>
> Key: OAK-3815
> URL: https://issues.apache.org/jira/browse/OAK-3815
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
> Reporter: Chetan Mehrotra
> Assignee: Chetan Mehrotra
> Priority: Minor
> Fix For: 1.3.14
>
> Attachments: OAK-3815-v1.patch
>
>
> Currently the {{Tracker}} only has access to list of registered services but
> there is no way to know if the services have changed and one has to re obtain
> the set of services. For certain usecases its desirable to know (get
> notified) if the set of services registered against a specific type have
> changed.
> For e.g. in OAK-3576 the services are to be registered against set of
> NodeTypes and each service provides set of nodeTypes it support. Creating
> that structure (nodeType -> service) is to be avoided on the critical path.
> So far Tracker serves the purpose well. One can just open the tracker and get
> the list of services and create that nodeType -> service mapping. However in
> case of OSGi (or in other modes also) if a new service is registered there is
> no way currently to get notified. As of now one needs to have reference
> property added to some OSGi component with bind and unbind callbacks. Given
> we already make use of {{ServicetTracker}} and do get notified when services
> get updated we should easily be able to make use of that.
> For such cases I would like to propose registering a callback which should
> get notified if there is some change in set of services registered against a
> specific type. Then one can register the callback while creating the Tracker
> instance
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
