Hi Tom Please add your comments to the bug and/or Gerrit change.
Thanks, Dani From: "Thomas Watson" <tjwat...@us.ibm.com> To: platform-dev@eclipse.org Date: 02.07.2020 18:24 Subject: [EXTERNAL] Re: [platform-dev] Creating a whiteboard pattern for IResourceChangeListener Sent by: platform-dev-boun...@eclipse.org Makes sense to me. I do recall discussions to use event admin for some more events in the platform. I don't recall if it was for resource change listeners. Anyway, some of the complications with that were around scaling across all the other topics that may have events flying through the event admin pipeline. At the moment the Equinox event admin async event "bus" (post vs send) is a single thread that services all topics. This can quickly lead to a bottleneck if we have multiple topics that have large amounts of events being posted. Tom ----- Original message ----- From: Alex Blewitt <alex.blew...@gmail.com> Sent by: platform-dev-boun...@eclipse.org To: platform-dev@eclipse.org Cc: Subject: [EXTERNAL] [platform-dev] Creating a whiteboard pattern for IResourceChangeListener Date: Thu, Jul 2, 2020 10:58 AM Hi everyone, I’ve proposed a change at https://git.eclipse.org/r/c/platform/eclipse.platform.resources/+/165750 to provide a way of registering IResourceChangeListener instances via an OSGi service rather than an explicit call to IWorkspace. There’s lots of calls in projects that look something like: ResourcesPlugin.getWorkspace().addResourceChangeListener (resourceChangeListener); This has an ordering dependency that the workspace needs to be running before this registration occurs. Of course, if the workspace doesn’t exist at this point we aren’t going to be receiving any events but we’d like to be able to start them in either order. If we use the OSGi whiteboard pattern, we can turn it on its head and do: context.registerService(resourceChangeListener, IResourceChangeListener.class); (We do something similar in many places for DebugOptions.) Now we have decoupled the start order dependency, and with the change above we’ll now pick up the binding when the resources plugin is available, and will automatically deregister when either service goes away. We can also use this to register the listeners via DS: <?xml version="1.0" encoding="UTF-8"?> <scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.4.0"; immediate="true" name="ExampleResourceListener"> <implementation class="org.example.ExampleResourceListener"/> <service> <provide interface="org.eclipse.core.resources.IResourceChangeListener"/> </service> <!-- 1 == IResourceChangeEvent.POST_CHANGE --> <property name="event.mask" type="Integer" value="1"/> </scr:component> The additional properties on the service will allow a subset of the event types to be passed in (in this case, 1 == POST_BUILD). There is a minor disadvantage in that this is an integer rather than a compile-time constant reference, though if the registration in code is used you can have a Dictionary including IResourceChangeEvent.POST_BUILD as the key in the dictionary. This approach of having a whiteboard pattern (either DS or ServiceTracker) for listeners could be replayed on other listener types as well; but from what I can tell, the IResourceChangeListener is the most popular in hooking together the world. Arguably it might be more ‘OSGi’ to attempt migrating the IResourceChangeEvent to an OSGi EventAdmin topic, but that would require more invasive dependency and code changes than exists at the moment. Having everything in DS means that we can start the components lazily and avoid the use of Activators, which will certainly help with the start-up times. Thoughts? Alex _______________________________________________ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev _______________________________________________ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
_______________________________________________ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
