Classpath resource origin has been suffering from several complicated problems (see
Getting issue details...
for more details). The possibilities to solve those issues were limited by the current implementation details: too minimalistic data structures which represent classpath hierarchy, unclear relations and responsibilities of
ClasspathResoucreOrigin itself as well as the classpath scanning services.
When finally it has been realised that the current implementation is not capable of becoming stable enough to support classpath resource reloading in development mode, it was decided to make an overhaul.
The following diagram features the new approach to
ClasspathResourceOrigin implementation on the higher level.
- Classpath hierarchy is now represented by
ClasspathServiceis a new component which is responsible for maintaining the classpath hierarchy representation
ClasspathServiceinstances (normally two per webapp) are connected with
@Multibindingannotation and are started and stopped together
- The correct version of the main
ClasspathService (the other one is responsible for legacy resources
)is provided based on magnolia.develop property state
ClasspathResourceOrigindoes not maintain any state on its own anymore - just delegates to the
Optional reloading mechanics
In order to make a distinction between development and production mode
ClasspathServices (the former should support classpath monitoring and the latter - shouldn't) a special interface has been introduced:
Default ClasspathService implementation architecture