Reconsider client and client session listener mechanism #141
Comments
tortmayr
added a commit
to eclipse-glsp/glsp-server
that referenced
this issue
Sep 4, 2021
#150 Rework DI architecture No longer use one global injector per application connection. Instead use a global server injector and dedicated child injectors for each client session. This removes a couple of flaws/downsides we had with the current approach. To achieve this the `GLSPModule` has been split into two separate modules. The `ServerModule` provides the bindings for base infrastructure & networking (used for creating the server injector) while `DiagramModules` provide language & session specific bindings (used for creating the session specific child injectors). The main benefits are the following: - Each session now uses its own `ActionDispatcher` this means action messages intended for different client sessions can now be handled in parallel. Previously they were processed one after the other essentially creating a bottleneck. - One `GLSPServer` can now handler multiple different diagram implementations. The diagram language specific bindings are provided with a `DiagramModule`. When creating a new client session injector the corresponding `DiagramModule` is identified via the given diagram type. This can for instance be used in UML-GLSP to provide all different diagram types (class,package,state machine etc.) with one server. - Apart from the initial "process" method it is no longer necessary to keep track of the diagramid/client session id. Each session has its own instances of action handlers, operation handlers, model state, diagram configuration etc. and the clientId no longer needs to be passed as method argument. In addition, provider classes with the purpose of mapping a class instance to the correct digramId like `ModelStateProvider` or the `DiagramConfigurationRegistry` are now obsolete and have been removed. - It is now possible to create stateful action/operation handlers. Previously handlers had to be stateless because they were reused for all client sessions. Now each session has its own set own set of handlers . Note that this PR only provides the DI architecture rework. Existing API whose functionality does not break after the rework as not been touched yet even tough there a various aspects of the existing API that can now be simplified/improved. For instance, with the new approach the Action/Operation Handler API can be simplified. It is no longer necessary to pass the model state argument as part of the interface methods (see also #120). I have identified some major aspects of the API that can be improved (corresponding issues will be created after this PR is merged). #141 Refactor `ClientSessionListener` API - Extract listener methods for server connection from `ClientSessionListener` interface into own `ServerConnectionListener` interface. Server connection listeners are handled directly by the `GLSPServer`. - It is now possible to define a set of clientIds for which a listener should be registered when adding a new `ClientSessionListener` to the 'ClientSessionManager`. - The `DefaultGLSPClientSessionManager` now autodisposes all `ClientSessionListeners` for the corresponding clientSessionId when a session is disposed. - Improved null-checks: The client session manager now checks for disposed listeners (i.e. null values in the map) and removes them before notifying (i.e invoking a listener method) them. Miscellaneous - Reduce public API exposure. Interface implementations that typically are not expected to be customized by implementing projects haven been moved to the `internal` API. - Improve documentation. Add javadoc for all newly added interfaces and relevant public classes. Also improve documentation of some existing components. - Merge `GLSPServerStatusAction` and `ServerStatusAction` - Introduce `ModuleUtil` class with provides the functionality to mixin modules similar to how it is done in Xtext. - Remove uncessary `.gitkeep` file. - Rename `DefaultGLSPServerLauncher` to `SocketGLSPServerLauncher` - Rename `ClientOptions` to `ClientOptionsUtil` to conform to the standard naming scheme for util classes Fixes eclipse-glsp/glsp/issues/150 Fixes eclipse-glsp/glsp/issues/141
tortmayr
added a commit
to eclipse-glsp/glsp-server
that referenced
this issue
Sep 5, 2021
#150 Rework DI architecture No longer use one global injector per application connection. Instead use a global server injector and dedicated child injectors for each client session. This removes a couple of flaws/downsides we had with the current approach. To achieve this the `GLSPModule` has been split into two separate modules. The `ServerModule` provides the bindings for base infrastructure & networking (used for creating the server injector) while `DiagramModules` provide language & session specific bindings (used for creating the session specific child injectors). The main benefits are the following: - Each session now uses its own `ActionDispatcher` this means action messages intended for different client sessions can now be handled in parallel. Previously they were processed one after the other essentially creating a bottleneck. - One `GLSPServer` can now handler multiple different diagram implementations. The diagram language specific bindings are provided with a `DiagramModule`. When creating a new client session injector the corresponding `DiagramModule` is identified via the given diagram type. This can for instance be used in UML-GLSP to provide all different diagram types (class,package,state machine etc.) with one server. - Apart from the initial "process" method it is no longer necessary to keep track of the diagramid/client session id. Each session has its own instances of action handlers, operation handlers, model state, diagram configuration etc. and the clientId no longer needs to be passed as method argument. In addition, provider classes with the purpose of mapping a class instance to the correct digramId like `ModelStateProvider` or the `DiagramConfigurationRegistry` are now obsolete and have been removed. - It is now possible to create stateful action/operation handlers. Previously handlers had to be stateless because they were reused for all client sessions. Now each session has its own set own set of handlers . Note that this PR only provides the DI architecture rework. Existing API whose functionality does not break after the rework as not been touched yet even tough there a various aspects of the existing API that can now be simplified/improved. For instance, with the new approach the Action/Operation Handler API can be simplified. It is no longer necessary to pass the model state argument as part of the interface methods (see also #120). I have identified some major aspects of the API that can be improved (corresponding issues will be created after this PR is merged). #141 Refactor `ClientSessionListener` API - Extract listener methods for server connection from `ClientSessionListener` interface into own `ServerConnectionListener` interface. Server connection listeners are handled directly by the `GLSPServer`. - It is now possible to define a set of clientIds for which a listener should be registered when adding a new `ClientSessionListener` to the 'ClientSessionManager`. - The `DefaultGLSPClientSessionManager` now autodisposes all `ClientSessionListeners` for the corresponding clientSessionId when a session is disposed. - Improved null-checks: The client session manager now checks for disposed listeners (i.e. null values in the map) and removes them before notifying (i.e invoking a listener method) them. Miscellaneous - Reduce public API exposure. Interface implementations that typically are not expected to be customized by implementing projects haven been moved to the `internal` API. - Improve documentation. Add javadoc for all newly added interfaces and relevant public classes. Also improve documentation of some existing components. - Merge `GLSPServerStatusAction` and `ServerStatusAction` - Introduce `ModuleUtil` class with provides the functionality to mixin modules similar to how it is done in Xtext. - Remove uncessary `.gitkeep` file. - Rename `DefaultGLSPServerLauncher` to `SocketGLSPServerLauncher` - Rename `ClientOptions` to `ClientOptionsUtil` to conform to the standard naming scheme for util classes Fixes eclipse-glsp/glsp/issues/150 Fixes eclipse-glsp/glsp/issues/141
tortmayr
added a commit
to eclipse-glsp/glsp-server
that referenced
this issue
Sep 8, 2021
#150 Rework DI architecture No longer use one global injector per application connection. Instead use a global server injector and dedicated child injectors for each client session. This removes a couple of flaws/downsides we had with the current approach. To achieve this the `GLSPModule` has been split into two separate modules. The `ServerModule` provides the bindings for base infrastructure & networking (used for creating the server injector) while `DiagramModules` provide language & session specific bindings (used for creating the session specific child injectors). The main benefits are the following: - Each session now uses its own `ActionDispatcher` this means action messages intended for different client sessions can now be handled in parallel. Previously they were processed one after the other essentially creating a bottleneck. - One `GLSPServer` can now handler multiple different diagram implementations. The diagram language specific bindings are provided with a `DiagramModule`. When creating a new client session injector the corresponding `DiagramModule` is identified via the given diagram type. This can for instance be used in UML-GLSP to provide all different diagram types (class,package,state machine etc.) with one server. - Apart from the initial "process" method it is no longer necessary to keep track of the diagramid/client session id. Each session has its own instances of action handlers, operation handlers, model state, diagram configuration etc. and the clientId no longer needs to be passed as method argument. In addition, provider classes with the purpose of mapping a class instance to the correct digramId like `ModelStateProvider` or the `DiagramConfigurationRegistry` are now obsolete and have been removed. - It is now possible to create stateful action/operation handlers. Previously handlers had to be stateless because they were reused for all client sessions. Now each session has its own set own set of handlers . - Use the new approach of injecting optionals (provided by Guice 5) instead of binding NullImpls. Note that this PR only provides the DI architecture rework. Existing API whose functionality does not break after the rework as not been touched yet even tough there a various aspects of the existing API that can now be simplified/improved. For instance, with the new approach the Action/Operation Handler API can be simplified. It is no longer necessary to pass the model state argument as part of the interface methods (see also #120). I have identified some major aspects of the API that can be improved (corresponding issues will be created after this PR is merged). #141 Refactor `ClientSessionListener` API - Extract listener methods for server connection from `ClientSessionListener` interface into own `ServerConnectionListener` interface. Server connection listeners are handled directly by the `GLSPServer`. - It is now possible to define a set of clientIds for which a listener should be registered when adding a new `ClientSessionListener` to the 'ClientSessionManager`. - The `DefaultGLSPClientSessionManager` now autodisposes all `ClientSessionListeners` for the corresponding clientSessionId when a session is disposed. - Improved null-checks: The client session manager now checks for disposed listeners (i.e. null values in the map) and removes them before notifying (i.e invoking a listener method) them. Miscellaneous - Reduce public API exposure. Interface implementations that typically are not expected to be customized by implementing projects haven been moved to the `internal` API. - Improve documentation. Add javadoc for all newly added interfaces and relevant public classes. Also improve documentation of some existing components. - Merge `GLSPServerStatusAction` and `ServerStatusAction` - Introduce `ModuleUtil` class with provides the functionality to mixin modules similar to how it is done in Xtext. - Remove uncessary `.gitkeep` file. - Rename `DefaultGLSPServerLauncher` to `SocketGLSPServerLauncher` - Rename `ClientOptions` to `ClientOptionsUtil` to conform to the standard naming scheme for util classes - Follow Guice best practices and document all public bindings of a module Fixes eclipse-glsp/glsp/issues/150 Fixes eclipse-glsp/glsp/issues/141
tortmayr
added a commit
to eclipse-glsp/glsp-server
that referenced
this issue
Sep 8, 2021
#150 Rework DI architecture No longer use one global injector per application connection. Instead use a global server injector and dedicated child injectors for each client session. This removes a couple of flaws/downsides we had with the current approach. To achieve this the `GLSPModule` has been split into two separate modules. The `ServerModule` provides the bindings for base infrastructure & networking (used for creating the server injector) while `DiagramModules` provide language & session specific bindings (used for creating the session specific child injectors). The main benefits are the following: - Each session now uses its own `ActionDispatcher` this means action messages intended for different client sessions can now be handled in parallel. Previously they were processed one after the other essentially creating a bottleneck. - One `GLSPServer` can now handler multiple different diagram implementations. The diagram language specific bindings are provided with a `DiagramModule`. When creating a new client session injector the corresponding `DiagramModule` is identified via the given diagram type. This can for instance be used in UML-GLSP to provide all different diagram types (class,package,state machine etc.) with one server. - Apart from the initial "process" method it is no longer necessary to keep track of the diagramid/client session id. Each session has its own instances of action handlers, operation handlers, model state, diagram configuration etc. and the clientId no longer needs to be passed as method argument. In addition, provider classes with the purpose of mapping a class instance to the correct digramId like `ModelStateProvider` or the `DiagramConfigurationRegistry` are now obsolete and have been removed. - It is now possible to create stateful action/operation handlers. Previously handlers had to be stateless because they were reused for all client sessions. Now each session has its own set own set of handlers . - Use the new approach of injecting optionals (provided by Guice 5) instead of binding NullImpls. Note that this PR only provides the DI architecture rework. Existing API whose functionality does not break after the rework as not been touched yet even tough there a various aspects of the existing API that can now be simplified/improved. For instance, with the new approach the Action/Operation Handler API can be simplified. It is no longer necessary to pass the model state argument as part of the interface methods (see also #120). I have identified some major aspects of the API that can be improved (corresponding issues will be created after this PR is merged). #141 Refactor `ClientSessionListener` API - Extract listener methods for server connection from `ClientSessionListener` interface into own `ServerConnectionListener` interface. Server connection listeners are handled directly by the `GLSPServer`. - It is now possible to define a set of clientIds for which a listener should be registered when adding a new `ClientSessionListener` to the 'ClientSessionManager`. - The `DefaultGLSPClientSessionManager` now autodisposes all `ClientSessionListeners` for the corresponding clientSessionId when a session is disposed. - Improved null-checks: The client session manager now checks for disposed listeners (i.e. null values in the map) and removes them before notifying (i.e invoking a listener method) them. Miscellaneous - Reduce public API exposure. Interface implementations that typically are not expected to be customized by implementing projects haven been moved to the `internal` API. - Improve documentation. Add javadoc for all newly added interfaces and relevant public classes. Also improve documentation of some existing components. - Merge `GLSPServerStatusAction` and `ServerStatusAction` - Introduce `ModuleUtil` class with provides the functionality to mixin modules similar to how it is done in Xtext. - Remove uncessary `.gitkeep` file. - Rename `DefaultGLSPServerLauncher` to `SocketGLSPServerLauncher` - Rename `ClientOptions` to `ClientOptionsUtil` to conform to the standard naming scheme for util classes - Follow Guice best practices and document all public bindings of a module Fixes eclipse-glsp/glsp/issues/150 Fixes eclipse-glsp/glsp/issues/141
tortmayr
added a commit
to eclipse-glsp/glsp-server
that referenced
this issue
Sep 8, 2021
#150 Rework DI architecture No longer use one global injector per application connection. Instead use a global server injector and dedicated child injectors for each client session. This removes a couple of flaws/downsides we had with the current approach. To achieve this the `GLSPModule` has been split into two separate modules. The `ServerModule` provides the bindings for base infrastructure & networking (used for creating the server injector) while `DiagramModules` provide language & session specific bindings (used for creating the session specific child injectors). The main benefits are the following: - Each session now uses its own `ActionDispatcher` this means action messages intended for different client sessions can now be handled in parallel. Previously they were processed one after the other essentially creating a bottleneck. - One `GLSPServer` can now handler multiple different diagram implementations. The diagram language specific bindings are provided with a `DiagramModule`. When creating a new client session injector the corresponding `DiagramModule` is identified via the given diagram type. This can for instance be used in UML-GLSP to provide all different diagram types (class,package,state machine etc.) with one server. - Apart from the initial "process" method it is no longer necessary to keep track of the diagramid/client session id. Each session has its own instances of action handlers, operation handlers, model state, diagram configuration etc. and the clientId no longer needs to be passed as method argument. In addition, provider classes with the purpose of mapping a class instance to the correct digramId like `ModelStateProvider` or the `DiagramConfigurationRegistry` are now obsolete and have been removed. - It is now possible to create stateful action/operation handlers. Previously handlers had to be stateless because they were reused for all client sessions. Now each session has its own set own set of handlers . - Use the new approach of injecting optionals (provided by Guice 5) instead of binding NullImpls. Note that this PR only provides the DI architecture rework. Existing API whose functionality does not break after the rework as not been touched yet even tough there a various aspects of the existing API that can now be simplified/improved. For instance, with the new approach the Action/Operation Handler API can be simplified. It is no longer necessary to pass the model state argument as part of the interface methods (see also #120). I have identified some major aspects of the API that can be improved (corresponding issues will be created after this PR is merged). #141 Refactor `ClientSessionListener` API - Extract listener methods for server connection from `ClientSessionListener` interface into own `ServerConnectionListener` interface. Server connection listeners are handled directly by the `GLSPServer`. - It is now possible to define a set of clientIds for which a listener should be registered when adding a new `ClientSessionListener` to the 'ClientSessionManager`. - The `DefaultGLSPClientSessionManager` now autodisposes all `ClientSessionListeners` for the corresponding clientSessionId when a session is disposed. - Improved null-checks: The client session manager now checks for disposed listeners (i.e. null values in the map) and removes them before notifying (i.e invoking a listener method) them. Miscellaneous - Reduce public API exposure. Interface implementations that typically are not expected to be customized by implementing projects haven been moved to the `internal` API. - Improve documentation. Add javadoc for all newly added interfaces and relevant public classes. Also improve documentation of some existing components. - Merge `GLSPServerStatusAction` and `ServerStatusAction` - Introduce `ModuleUtil` class with provides the functionality to mixin modules similar to how it is done in Xtext. - Remove uncessary `.gitkeep` file. - Rename `DefaultGLSPServerLauncher` to `SocketGLSPServerLauncher` - Rename `ClientOptions` to `ClientOptionsUtil` to conform to the standard naming scheme for util classes - Follow Guice best practices and document all public bindings of a module Fixes eclipse-glsp/glsp/issues/150 Fixes eclipse-glsp/glsp/issues/141
tortmayr
added a commit
to eclipse-glsp/glsp-server
that referenced
this issue
Sep 16, 2021
#150 Rework DI architecture No longer use one global injector per application connection. Instead use a global server injector and dedicated child injectors for each client session. This removes a couple of flaws/downsides we had with the current approach. To achieve this the `GLSPModule` has been split into two separate modules. The `ServerModule` provides the bindings for base infrastructure & networking (used for creating the server injector) while `DiagramModules` provide language & session specific bindings (used for creating the session specific child injectors). The main benefits are the following: - Each session now uses its own `ActionDispatcher` this means action messages intended for different client sessions can now be handled in parallel. Previously they were processed one after the other essentially creating a bottleneck. - One `GLSPServer` can now handler multiple different diagram implementations. The diagram language specific bindings are provided with a `DiagramModule`. When creating a new client session injector the corresponding `DiagramModule` is identified via the given diagram type. This can for instance be used in UML-GLSP to provide all different diagram types (class,package,state machine etc.) with one server. - Apart from the initial "process" method it is no longer necessary to keep track of the diagramid/client session id. Each session has its own instances of action handlers, operation handlers, model state, diagram configuration etc. and the clientId no longer needs to be passed as method argument. In addition, provider classes with the purpose of mapping a class instance to the correct digramId like `ModelStateProvider` or the `DiagramConfigurationRegistry` are now obsolete and have been removed. - It is now possible to create stateful action/operation handlers. Previously handlers had to be stateless because they were reused for all client sessions. Now each session has its own set own set of handlers . - Use the new approach of injecting optionals (provided by Guice 5) instead of binding NullImpls. Note that this PR only provides the DI architecture rework. Existing API whose functionality does not break after the rework as not been touched yet even tough there a various aspects of the existing API that can now be simplified/improved. For instance, with the new approach the Action/Operation Handler API can be simplified. It is no longer necessary to pass the model state argument as part of the interface methods (see also #120). I have identified some major aspects of the API that can be improved (corresponding issues will be created after this PR is merged). #141 Refactor `ClientSessionListener` API - Extract listener methods for server connection from `ClientSessionListener` interface into own `ServerConnectionListener` interface. Server connection listeners are handled directly by the `GLSPServer`. - It is now possible to define a set of clientIds for which a listener should be registered when adding a new `ClientSessionListener` to the 'ClientSessionManager`. - The `DefaultGLSPClientSessionManager` now autodisposes all `ClientSessionListeners` for the corresponding clientSessionId when a session is disposed. - Improved null-checks: The client session manager now checks for disposed listeners (i.e. null values in the map) and removes them before notifying (i.e invoking a listener method) them. Miscellaneous - Reduce public API exposure. Interface implementations that typically are not expected to be customized by implementing projects haven been moved to the `internal` API. - Improve documentation. Add javadoc for all newly added interfaces and relevant public classes. Also improve documentation of some existing components. - Merge `GLSPServerStatusAction` and `ServerStatusAction` - Introduce `ModuleUtil` class with provides the functionality to mixin modules similar to how it is done in Xtext. - Remove uncessary `.gitkeep` file. - Rename `DefaultGLSPServerLauncher` to `SocketGLSPServerLauncher` - Rename `ClientOptions` to `ClientOptionsUtil` to conform to the standard naming scheme for util classes - Follow Guice best practices and document all public bindings of a module Fixes eclipse-glsp/glsp/issues/150 Fixes eclipse-glsp/glsp/issues/141
tortmayr
added a commit
to eclipse-glsp/glsp-server
that referenced
this issue
Oct 5, 2021
* [WIP] #150 #141 Rework dependency injection architecture #150 Rework DI architecture No longer use one global injector per application connection. Instead use a global server injector and dedicated child injectors for each client session. This removes a couple of flaws/downsides we had with the current approach. To achieve this the `GLSPModule` has been split into two separate modules. The `ServerModule` provides the bindings for base infrastructure & networking (used for creating the server injector) while `DiagramModules` provide language & session specific bindings (used for creating the session specific child injectors). The main benefits are the following: - Each session now uses its own `ActionDispatcher` this means action messages intended for different client sessions can now be handled in parallel. Previously they were processed one after the other essentially creating a bottleneck. - One `GLSPServer` can now handler multiple different diagram implementations. The diagram language specific bindings are provided with a `DiagramModule`. When creating a new client session injector the corresponding `DiagramModule` is identified via the given diagram type. This can for instance be used in UML-GLSP to provide all different diagram types (class,package,state machine etc.) with one server. - Apart from the initial "process" method it is no longer necessary to keep track of the diagramid/client session id. Each session has its own instances of action handlers, operation handlers, model state, diagram configuration etc. and the clientId no longer needs to be passed as method argument. In addition, provider classes with the purpose of mapping a class instance to the correct digramId like `ModelStateProvider` or the `DiagramConfigurationRegistry` are now obsolete and have been removed. - It is now possible to create stateful action/operation handlers. Previously handlers had to be stateless because they were reused for all client sessions. Now each session has its own set own set of handlers . - Use the new approach of injecting optionals (provided by Guice 5) instead of binding NullImpls. Note that this PR only provides the DI architecture rework. Existing API whose functionality does not break after the rework as not been touched yet even tough there a various aspects of the existing API that can now be simplified/improved. For instance, with the new approach the Action/Operation Handler API can be simplified. It is no longer necessary to pass the model state argument as part of the interface methods (see also #120). I have identified some major aspects of the API that can be improved (corresponding issues will be created after this PR is merged). #141 Refactor `ClientSessionListener` API - Extract listener methods for server connection from `ClientSessionListener` interface into own `ServerConnectionListener` interface. Server connection listeners are handled directly by the `GLSPServer`. - It is now possible to define a set of clientIds for which a listener should be registered when adding a new `ClientSessionListener` to the 'ClientSessionManager`. - The `DefaultGLSPClientSessionManager` now autodisposes all `ClientSessionListeners` for the corresponding clientSessionId when a session is disposed. - Improved null-checks: The client session manager now checks for disposed listeners (i.e. null values in the map) and removes them before notifying (i.e invoking a listener method) them. Miscellaneous - Reduce public API exposure. Interface implementations that typically are not expected to be customized by implementing projects haven been moved to the `internal` API. - Improve documentation. Add javadoc for all newly added interfaces and relevant public classes. Also improve documentation of some existing components. - Merge `GLSPServerStatusAction` and `ServerStatusAction` - Introduce `ModuleUtil` class with provides the functionality to mixin modules similar to how it is done in Xtext. - Remove uncessary `.gitkeep` file. - Rename `DefaultGLSPServerLauncher` to `SocketGLSPServerLauncher` - Rename `ClientOptions` to `ClientOptionsUtil` to conform to the standard naming scheme for util classes - Follow Guice best practices and document all public bindings of a module Fixes eclipse-glsp/glsp/issues/150 Fixes eclipse-glsp/glsp/issues/141 * Remove clientId argument where obsolete * Address review feedback Co-authored-by: Philip Langer <planger@eclipsesource.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently the client session manager serves as a singleton that handles both client-connections (client connected, client disconnected) and client-specific sessions (session created, session closed). This is also reflected in the client session listener interface.
I propose to split the interface in client management and session management so that implementations can only listen to the parts they are interested in. Furthermore, this would allow us to register session listeners only for a particular client which the client manager can then auto-dispose (at the moment all session listener also listen to the disposal of their client).
Furthermore I suggest to extend the session listener with an event 'sessionUpdated' with the updated session options that are sent with the RequestModelAction. The options contain the source URI and other data session listeners such as the file watcher may be interested in.
The text was updated successfully, but these errors were encountered: