Classpath resource origin has been suffering from several complicated problems (see
MAGNOLIA-6523
-
Getting issue details...
STATUS
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.
High-level principle
The following diagram features the new approach to ClasspathResourceOrigin implementation on the higher level.
- Classpath hierarchy is now represented by
ClasspathEntryobjects ClasspathServiceis a new component which is responsible for maintaining the classpath hierarchy representationClasspathServiceinstances (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 theClasspathService
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


