Page tree
Skip to end of metadata
Go to start of metadata

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 ClasspathEntry objects
  • ClasspathService is a new component which is responsible for maintaining the classpath hierarchy representation 
  • ClasspathService instances (normally two per webapp) are connected with @Multibinding annotation 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
  • ClasspathResourceOrigin does not maintain any state on its own anymore  - just delegates to the ClasspathService

 

 

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

 

 

  • No labels