Creating a whiteboard pattern for IResourceChangeListener

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Creating a whiteboard pattern for IResourceChangeListener

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
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Creating a whiteboard pattern for IResourceChangeListener

Lars Vogel-2
Hi Alex,

Sounds great to me. Thanks for working on this.

Let's continue this discussion via a bug report.

Best regards

Alex Blewitt <[hidden email]> schrieb am Do., 2. Juli 2020, 17:58:
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
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev

_______________________________________________
platform-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Creating a whiteboard pattern for IResourceChangeListener

Thomas Watson
In reply to this post by Alex Blewitt
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 <[hidden email]>
Sent by: [hidden email]
To: [hidden email]
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
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
 


_______________________________________________
platform-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Creating a whiteboard pattern for IResourceChangeListener

Alex Blewitt
In reply to this post by Lars Vogel-2
Sorry, should perhaps have filed that first.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=564876

On 2 Jul 2020, at 17:21, Lars Vogel <[hidden email]> wrote:

Hi Alex,

Sounds great to me. Thanks for working on this.

Let's continue this discussion via a bug report.

Best regards

Alex Blewitt <[hidden email]> schrieb am Do., 2. Juli 2020, 17:58:
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
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
_______________________________________________
platform-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev


_______________________________________________
platform-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Creating a whiteboard pattern for IResourceChangeListener

Lars Vogel-2
No worries. Thanks for thinking outside the box.

Alex Blewitt <[hidden email]> schrieb am Do., 2. Juli 2020, 18:51:
Sorry, should perhaps have filed that first.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=564876

On 2 Jul 2020, at 17:21, Lars Vogel <[hidden email]> wrote:

Hi Alex,

Sounds great to me. Thanks for working on this.

Let's continue this discussion via a bug report.

Best regards

Alex Blewitt <[hidden email]> schrieb am Do., 2. Juli 2020, 17:58:
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
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
_______________________________________________
platform-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev

_______________________________________________
platform-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev

_______________________________________________
platform-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Creating a whiteboard pattern for IResourceChangeListener

Tom Schindl-2
In reply to this post by Alex Blewitt
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
> [hidden email]
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
>
_______________________________________________
platform-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Creating a whiteboard pattern for IResourceChangeListener

Daniel Megert
In reply to this post by Thomas Watson
Hi Tom

Please add your comments to the bug and/or Gerrit change.

Thanks,
Dani



From:        "Thomas Watson" <[hidden email]>
To:        [hidden email]
Date:        02.07.2020 18:24
Subject:        [EXTERNAL] Re: [platform-dev] Creating a whiteboard pattern for        IResourceChangeListener
Sent by:        [hidden email]




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 <[hidden email]>
Sent by: [hidden email]
To: [hidden email]
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/+/165750to 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
[hidden email]
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
 
_______________________________________________
platform-dev mailing list
[hidden email]
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev




_______________________________________________
platform-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev