[WPS 4.0] RepositoryManager VS ContentInjection

[ridoo]

Currently, the RepositoryManager creates instances of IAlgorithmRepository via reflection ignoring all instances getting instantiated from the IoC Container, for example classes marked as @Components.

That is, we have two instances available after startup

1. the one created by the RepositoryManager without having @Autowired fields set or @PostConstruct methods being called
2. the injected beans which were initiated fully via IoC container.

For 52n-wps-r in particular this results in empty algorithms collections when using RepositoryManager's LocalRAlgoritmRepository instance.

[ridoo]

This seems to become cumbersome: At a first glimpse lettingRepositoryManager implement ApplicationContextAware to be able to create beans by their name (which come from configuration) would solve the problem.

However, the RepositoryManager is implemented as a Singleton which is being used by lots of other classes not being managed by the IoC container. This leads to a string of other refactorings.

Will have a look at if there's a way avoiding this right now.

[bpross-52n]

So, the R repository is the only one annotated with Component, right? Could the annotation maybe be removed and the injected stuff be requested from the config module?

[ridoo]

So making a loosely coupled design (not perfect though) hard wired again so that it integrates better in the old fashioned design? I am a bit hesitant about that.

Actually we are talking about WPS 4.0 right? Don't know about resources available for discussing current and future architecture and how to wire components and (probably more important) for implementing whole stuff.

Do we have a refactor strategy available, at least listing all core components which will have to be refactored? Is Iceland the only next step? Seems to be a bit fuzzy (at least for me) what consequences this will have too.

[ridoo]

I think we could at least pull in an intermediate tier:

Refactor RepositoryManager to be IoC managable and wrap this with a temporary Singleton. This will allow us to move one core component to IoC principles w/o breaking the other classes

[bpross-52n]

Fine with me, if this is the way to make WPS4R work again.

[nuest]

I found the code for the wrapper repository that I once implemented but that was somehow lost in the merge process, maybe that helps:

https://github.com/nuest/WPS/tree/feature/spring-new-wps4R/52n-wps-r/src/main/java/org/n52/wps/server/spring