Add a socket event forwarder to allow external agent to watch state

[laeubi]

Currently there is no way to watch the bundle state from the outside of the framework, but for agents starting a framework it would be useful to have a way to watch the bundle state. For example in PDE we launch frameworks for different purpose in either run or debug mode but in the UI there is only a limited visualization.
That means users are forced to either install special code (e.g. a console) or are quite blindly needing to guess what's going on, both are quite inconvenient as its need special interaction or can even change the system state.

This now adds a new (internal) EventForwarder that allows to forward events to the agent, for this purpose the framework must be started with the property org.eclipse.osgi.internal.framework.forwarder and Equinox will open a (local) socket connection forwarding events. This is intentionally made internal and simple as it is not meant as a high level debugging or management facility.

This is how currently a launch of PDE looks like in the debug view:

This is how it looks like by PDE using this functionality (of course only a first draft):

Expanding the "Threads":

[github-actions]

Test Results

   78 files  ±0     78 suites  ±0   38m 42s ⏱️ + 1m 40s
2 170 tests ±0  2 125 ✅ ±0   45 💤 ±0  0 ❌ ±0 
6 642 runs  ±0  6 505 ✅ ±0  137 💤 ±0  0 ❌ ±0 

Results for commit f0b82cd. ± Comparison against base commit 49be75d.

♻️ This comment has been updated with latest results.

[laeubi]

@tjwatson I'd like to merge this if you are OK with that so we can start using it in in PDE.

[tjwatson]

I don't think this should be in the framework. It makes it specific to equinox for no reason. Why not make it a system bundle fragment that you configure into the framework at launch so it is not specific to equinox.

This only gives info about bundle states. I fear there will be feature creep as I would expect you to soon want to display information about other events, like ServiceEvents. This advanced tooling function belongs on top of the framework.

[laeubi]

They main reason is because I don't want a full blown general purpose management agent and that is "invisible" to the user. A Framework fragment would need special considerations, e.g. colocated to the launcher, we need some way to install it alongside with the usual bundles and users will see it if they list the bundles in the framework.

[tjwatson]

They main reason is because I don't want a full blown general purpose management agent and that is "invisible" to the user. A Framework fragment would need special considerations, e.g. colocated to the launcher, we need some way to install it alongside with the usual bundles and users will see it if they list the bundles in the framework.

All these sound acceptable to me instead of baking it directly into the framework.

colocated to the launcher.

There is a difference between being a system bundle fragment from the specification: https://docs.osgi.org/specification/osgi.core/8.0.0/framework.module.html#framework.module.extensionbundles and something that needs to hook into the framework implementation with a org.eclipse.osgi.internal.hookregistry.HookConfigurator

It is true that org.eclipse.osgi.internal.hookregistry.HookConfigurator implementations need to be co-located with org.eclipse.osgi on disk. But system bundle fragments (or extension bundles as the spec calls them) have no such requirement. These can even be installed as usual by p2.

[laeubi]

But system bundle fragments (or extension bundles as the spec calls them) have no such requirement. These can even be installed as usual by p2.

I'll check this but the problem remains that then this can only be used if we get from "somewhere" a special jar and provision it together with the framework bundle. Even if that is solved it now will become visible e.g. if one list all bundles in the system. This is especially annoying if I want to remote debug a framework as usually require it to be modified is often not desired, while adding a (temporary) system property is much easier.

[tjwatson]

This is especially annoying if I want to remote debug a framework as usually require it to be modified is often not desired, while adding a (temporary) system property is much easier.

I prefer this inconvenience to baking such things into the framework.

[laeubi]

This is especially annoying if I want to remote debug a framework as usually require it to be modified is often not desired, while adding a (temporary) system property is much easier.

I prefer this inconvenience to baking such things into the framework.

I see, do you think Equinox project seems a good host for a dedicated bundle then or would you prefer it to be part of PDE (or even a dedicated project) then?

[tjwatson]

I see, do you think Equinox project seems a good host for a dedicated bundle then or would you prefer it to be part of PDE (or even a dedicated project) then?

This is up to you. Equinox is OK, but then you have an added burden of making it API with respect to input/output of the data. If you make it part of PDE it can remain an external for only PDE to use. Over time, once it is stable, then PDE could decide to make it API, at which point we can discuss having it in Equinox.