feat: improve DependencyGraph and error reporting #4628
Conversation
paullatzelsperger
requested review from
jimmarino and
ndr-brt
as code owners
paullatzelsperger
force-pushed
the
feat/improve_dependency_graph
branch
from
edf9d8b
to
8759869
Compare
paullatzelsperger
force-pushed
the
feat/improve_dependency_graph
branch
2 times, most recently
from
e4a588e
to
e771686
Compare
paullatzelsperger
force-pushed
the
feat/improve_dependency_graph
branch
from
adbd767
to
d5b7758
Compare
paullatzelsperger
force-pushed
the
feat/improve_dependency_graph
branch
from
d5b7758
to
88bcfec
Compare
| * @param serviceClass The extension class | ||
| * @return A (potentially empty) list of injection points. | ||
| */ | ||
| public List<InjectionPoint<ServiceExtension>> getDependenciesOf(Class<? extends ServiceExtension> serviceClass) { |
There was a problem hiding this comment.
this method is only used by tests
There was a problem hiding this comment.
yes, the idea was to make the DG into more like a graph, with methods to match. It would make the DG more usable, esp. in runtimes other than the BaseRuntime
There was a problem hiding this comment.
I'm not in favor of that, this dependency graph is really something related to the BaseRuntime implementation, if someone wants for any reason to customize it, they would need to provide their own logic, otherwise we'll be responsible to maintain logic that we don't really need.
There was a problem hiding this comment.
I had a version where the DependencyGraph is an interface, and one implementation is using EDC-internal dependency injection. Other implementations could use other DI frameworks like Guice, which would make the DI independent from the runtime. I ultimately abandoned that, because it would have meant pulling the InjectionContainer and InjectionPoint classes into an SPI module, which seemed too much work and we don't really have a need for that now.
That said, these methods aren't needed by us at the moment, but since the BaseRuntime is extensible, and the DependencyGraph is exposed in protected methods, overriders may benefit from them.
| * @param dependencyType The type of the injection point, for example the type of service that is injected. | ||
| * @return a list of extension classes that declare a dependency onto the given injection point | ||
| */ | ||
| public List<Class<? extends ServiceExtension>> getDependentExtensions(Class<?> dependencyType) { |
| * @param dependencyType The type of the injection point, for example the type of service that is injected. | ||
| * @return a list of {@link InjectionPoint} instances that represent the concrete dependency | ||
| */ | ||
| public List<InjectionPoint<ServiceExtension>> getDependenciesFor(Class<?> dependencyType) { |
| var message = String.format("The following @Require'd features were not provided: [%s]", String.join(", ", unsatisfiedRequirements)); | ||
| throw new EdcException(message); | ||
| } | ||
| return new DependencyGraph(injectionContainers, unsatisfiedInjectionPoints, unsatisfiedRequirements); |
There was a problem hiding this comment.
at this point the DependencyGraph looks like some sort of Result, with List<InjectionContainer> as content type and a Failure that contains the unsatisfied injection points and requirement.
What this PR changes/adds
This PR improves the public API of the
DependencyGraphobject and makes it a bit more usable. In addition, error reporting of dependency injectionerrors is externalized and moved into the
BaseRuntimeclass.After dependency resolution, all problems are collected and a single
EdcInjectionExceptionis thrown by theBaseRuntime, for example:Why it does that
Dependency injection errors (services, config values and config objects) wasn't very elegant and needed improvement.
Linked Issue(s)
Contributes to #4610
Please be sure to take a look at the contributing guidelines and our etiquette for pull requests.