-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
#150 #141 Rework dependency injection architecture #127
Conversation
78401d1
to
119d57f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excellent job! Code looks great and clean, everything still works as expected.
I'm looking forward to how we can now make the handlers more flexible in terms of API!
plugins/org.eclipse.glsp.server/src/org/eclipse/glsp/server/di/DiagramModule.java
Outdated
Show resolved
Hide resolved
plugins/org.eclipse.glsp.server/src/org/eclipse/glsp/server/di/ServerModule.java
Outdated
Show resolved
Hide resolved
plugins/org.eclipse.glsp.server/src/org/eclipse/glsp/server/di/ServerModule.java
Outdated
Show resolved
Hide resolved
plugins/org.eclipse.glsp.server/src/org/eclipse/glsp/server/di/ServerModule.java
Outdated
Show resolved
Hide resolved
plugins/org.eclipse.glsp.server/src/org/eclipse/glsp/server/di/scope/DiagramGlobal.java
Outdated
Show resolved
Hide resolved
plugins/org.eclipse.glsp.server/src/org/eclipse/glsp/server/utils/ModuleUtil.java
Outdated
Show resolved
Hide resolved
plugins/org.eclipse.glsp.server/src/org/eclipse/glsp/server/utils/ModuleUtil.java
Outdated
Show resolved
Hide resolved
@Target({ TYPE, METHOD }) | ||
@Retention(RUNTIME) | ||
@ScopeAnnotation | ||
public @interface DiagramGlobal {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we rename that to DiagramGlobalSingleton
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or maybe DiagramTypedSingleton
? To make it more clear that these scope provides Singletons in the context of the diagram type
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes sure, I'd prefer DiagramTypeSingleton
a bit over DiagramTypedSingleton
or DiagramGlobalSingleton
.
...clipse.glsp.server/src/org/eclipse/glsp/server/internal/actions/DefaultActionDispatcher.java
Show resolved
Hide resolved
plugins/org.eclipse.glsp.server/src/org/eclipse/glsp/server/model/DefaultGModelState.java
Outdated
Show resolved
Hide resolved
1cf2bee
to
2d1993d
Compare
#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
2d1993d
to
edaf8a7
Compare
edaf8a7
to
d935ed3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, looks great!
With the DI rework #127 its no longer necessary to pass the model state object as part of the execute method. instead action/operation handlers can simply directly inject the model state if the want to use it. Since action & operation handlers are now client session scoped an arbitary state object can be injected and used for execution. (Fixes eclipse-glsp/glsp/issues/120) - Remove the modelstate argument from the execute() method of `ActionHandler` and `OperationHandler` - Remove `Handler` super interface because it doesn't provide any additional value - Add documentation for affected API. - Introduce new `DefaultActionHandler` & `DefaultOperationHandler` that serve as replacement for the now deprecated `BasicActionHandler` & `BasicOperationHandler` - Deprecate `BasicOperationHandler` & `BasicActionHandler`
With the DI rework #127 its no longer necessary to pass the model state object as part of the execute method. instead action/operation handlers can simply directly inject the model state if the want to use it. Since action & operation handlers are now client session scoped an arbitary state object can be injected and used for execution. (Part of eclipse-glsp/glsp/issues/120) - Remove the modelstate argument from the execute() method of `ActionHandler` and `OperationHandler` - Remove `Handler` super interface because it doesn't provide any additional value - Add documentation for affected API. - Introduce new `DefaultActionHandler` & `DefaultOperationHandler` that serve as replacement for the now deprecated `BasicActionHandler` & `BasicOperationHandler` - Deprecate `BasicOperationHandler` & `BasicActionHandler` & `BasicCreateOperationHandler` - Replace usage of `BasicActionHandler` with `DefaultActionHandler` - Replace usage of `BasicOperationHandler' with `DefaultActionHandler` - Replace usage of `BasicCreateOperationhandler' with `DefaultOperationHandler` & `DefaultCreateOperationHandler` Fixes eclipse-glsp/glsp/issues/425
With the DI rework #127 its no longer necessary to pass the model state object as part of the execute method. instead action/operation handlers can simply directly inject the model state if the want to use it. Since action & operation handlers are now client session scoped an arbitary state object can be injected and used for execution. (Part of eclipse-glsp/glsp/issues/120) - Remove the modelstate argument from the execute() method of `ActionHandler` and `OperationHandler` - Remove `Handler` super interface because it doesn't provide any additional value - Add documentation for affected API. - Introduce new `DefaultActionHandler` & `DefaultOperationHandler` that serve as replacement for the now deprecated `BasicActionHandler` & `BasicOperationHandler` - Deprecate `BasicOperationHandler` & `BasicActionHandler` & `BasicCreateOperationHandler` - Replace usage of `BasicActionHandler` with `DefaultActionHandler` - Replace usage of `BasicOperationHandler' with `DefaultActionHandler` - Replace usage of `BasicCreateOperationhandler' with `DefaultOperationHandler` & `DefaultCreateOperationHandler` Fixes eclipse-glsp/glsp/issues/425
* #425#120 Rework Actionhandler/Operationhandler API With the DI rework #127 its no longer necessary to pass the model state object as part of the execute method. instead action/operation handlers can simply directly inject the model state if the want to use it. Since action & operation handlers are now client session scoped an arbitary state object can be injected and used for execution. (Part of eclipse-glsp/glsp/issues/120) - Remove the modelstate argument from the execute() method of `ActionHandler` and `OperationHandler` - Remove `Handler` super interface because it doesn't provide any additional value - Add documentation for affected API. - Introduce new `DefaultActionHandler` & `DefaultOperationHandler` that serve as replacement for the now deprecated `BasicActionHandler` & `BasicOperationHandler` - Deprecate `BasicOperationHandler` & `BasicActionHandler` & `BasicCreateOperationHandler` - Replace usage of `BasicActionHandler` with `DefaultActionHandler` - Replace usage of `BasicOperationHandler' with `DefaultActionHandler` - Replace usage of `BasicCreateOperationhandler' with `DefaultOperationHandler` & `DefaultCreateOperationHandler` Fixes eclipse-glsp/glsp/issues/425 * Remove GModelState from interfaces as it should now be injected instead This simplifies the use of custom model state classes because implementations can now inject their concrete custom class instead of the generic GModelState that they'd have to cast again. Also several implementations often don't need the model state making the method parameter superfluous. Fixes eclipse-glsp/glsp/issues/120 Co-authored-by: Philip Langer <[email protected]>
#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. TheServerModule
provides the bindings for base infrastructure & networking (used for creating the server injector) whileDiagramModules
provide language & session specific bindings (used for creating the session specific child injectors).The main benefits are the following:
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.GLSPServer
can now handler multiple different diagram implementations. The diagram language specific bindings are provided with aDiagramModule
. When creating a new client session injector the correspondingDiagramModule
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.ModelStateProvider
or theDiagramConfigurationRegistry
are now obsolete and have been removed.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
APIClientSessionListener
interface into ownServerConnectionListener
interface. Server connection listeners are handled directly by theGLSPServer
.ClientSessionListener
to the 'ClientSessionManager`.DefaultGLSPClientSessionManager
now autodisposes allClientSessionListeners
for the corresponding clientSessionId when a session is disposed.Miscellaneous
internal
API.GLSPServerStatusAction
andServerStatusAction
ModuleUtil
class with provides the functionality to mixin modules similar to how it is done in Xtext..gitkeep
file.DefaultGLSPServerLauncher
toSocketGLSPServerLauncher
ClientOptions
toClientOptionsUtil
to conform to the standard naming scheme for util classesFixes eclipse-glsp/glsp/issues/150
Fixes eclipse-glsp/glsp/issues/141