Trace server does not use trace selection signals

[arfio]

The server does not broadcast any trace selected signal as you can have multiple opened traces at the same time and it should be possible to request data of an already opened experiment.
The selected trace signal is only used in the core projects to register the parameter providers. This registration also happens when the trace is opened, however the order in which the trace opened signals are handled is random, and because there is only one parameter provider instance, the analysis which is registered is random.
A couple of solutions are possible:

• Selecting the trace before providing a parameter (can maybe cause some race conditions)
• Having one parameter provider per trace, and then filtering in the handler with the correct trace.
• Creating a different mechanism to provide parameters for the few analyses that uses them.

[bhufmann]

In Eclipse Trace Compass the TmfTraceSelectedSignal is broadcasted when a user opens or selects a trace from multiple open traces. The receiver of the signal are in most case the view components which is used to update the views. I wasn't aware that is also used for the parameter provider. Looking at the the parameter providers implementations in Eclipse Trace Compass, most are implemented in the UI components as well. To use these parameter providers, the code has to be refactored and brought into the core components without UI. This doesn't solve the fact that that signal is not broadcasted when using the trace server.

I wonder if it could be send right after the place where the TmfTraceOpendedSignal is sent?

Having said that, I would suggest to use one use case (I think you're looking into the critical path parameter provider) to come-up how it can be implemented using the parameter providers.

I hope, the code can be done in such way that it can be used in Eclipse and Trace Server without re-implementing it.

Please keep us in the loop and let us know if you have any questions.