Extract DI to separate module #711
Conversation
…module # Conflicts: # services/src/main/java/io/scalecube/services/Microservices.java
eutkin
changed the title
…e MicroservicesContext from ServiceFactory#getServiceDefinitions
services/src/main/java/io/scalecube/services/Microservices.java
Outdated
Show resolved
Hide resolved
| @FunctionalInterface | ||
| @Deprecated |
There was a problem hiding this comment.
@eutkin @eutkin
Coming back to this question.
Again, why those methods were deprecated:
services(Object... services)
services(ServiceInfo... services)
services(ServiceProvider serviceProvider)
Can't u keep them and use ScalecubeServiceFactory which will be defined internally?
services(Object... services)
services(ServiceInfo... services)
services(ServiceProvider serviceProvider)
services(ServiceFactory serviceFactory)
I.e first three works with internal ScalecubeServiceFactory (client will not know even) + last one allows to specifiy explicitly serviceFactory. This way u would not need to deprecate you would just expose internal toolset called ServiceFactory.
services-api/src/main/java/io/scalecube/services/MicroservicesContext.java
Outdated
Show resolved
Hide resolved
services-api/src/main/java/io/scalecube/services/MicroservicesContext.java
Outdated
Show resolved
Hide resolved
services-api/src/main/java/io/scalecube/services/MicroservicesContext.java
Show resolved
Hide resolved
services-api/src/main/java/io/scalecube/services/MicroservicesContext.java
Show resolved
Hide resolved
| ServiceInfo serviceInfoB = ServiceInfo.fromServiceInstance(serviceB).build(); | ||
| return Mono.just(Collections.singletonList(serviceInfoB)); | ||
| } | ||
| }; |
There was a problem hiding this comment.
Just realized how ServiceFactory api can shoot in the foot. In this example with service-a service-b in method getServiceDefinitions were returned two services, in method initializeServices was returned one service. That's ok that service-b injects service-a, but i imagine scenario with N services and now client has to maintain correlation bewtween what's returned from getServiceDefinitions and initializeServices.
Don't have solution for this, but to me it looks like a big problem.
There was a problem hiding this comment.
There are only two ways.
- We create instances of services from ServiceDefinition
It is assumed that ServiceFactory will delegate its task to the DI framework and there will be no troubles. But they are possible. I will think about it.
…module # Conflicts: # services/src/main/java/io/scalecube/services/Microservices.java # services/src/test/java/io/scalecube/services/sut/AnnotationServiceImpl.java # services/src/test/java/io/scalecube/services/transport/rsocket/RSocketNettyColocatedEventLoopGroupTest.java
|
up |
…module # Conflicts: # services-examples-parent/services-examples/src/main/java/io/scalecube/services/examples/discovery/CompositeDiscoveryExample.java # services/src/main/java/io/scalecube/services/Microservices.java
|
What other important problems remain unresolved? It's becoming more and more difficult to merge this PR with the develop branch. |
|
@ronenhamias @artem-v @segabriel When I was writing the documentation, I found a semantic mistake. I suggest changing Why? Because otherwise it seems as if we are managing the life cycle of only those services that will be placed on the Scalecube node. In fact, ServiceFactory is needed to manage the lifecycle of all user components. But unlike DI frameworks |
I guess we need to postpone this PR for a week probably two weeks, due to we need to have a stable version of scalecube-services for this time slot. And have the ability to fast solve some shortcomings that stop us. |
I've made life cycle management of scalecube services a separate subsystem: ServicesProvider.
Pro:
ServicesProvider - interface for IoC container that performs several functions:
Scale Cube for DI proprietary mechanisms are collected in one class, in ServicesProvider implementation (see ScaleCubeServicesProvider).
The Spring IoC implementation is also given for the example.