Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-dev] Creating a whiteboard pattern for IResourceChangeListener 
Hi Alex,
Maybe I'm totally wrong but I think I remember that early initialization of Resources-Plugin via by DS stuff caused problems in the past because the workspace-selection dialog did not come up any more (something you don't spot when running with an inner-eclipse).
Maybe I'm totally wrong and as it's been a looong time since I hacked the Eclipse Platform so if what say is BS just ignore it ;-) 

Tom

Am 02.07.20 um 17:58 schrieb Alex Blewitt:

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@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev

Back to the top