Skip to content

Improve the way play-cms initialized

Anton Sudak requested to merge improve-cms-initialization into master

This change intended to decouple CMSApi and CMSApiLifecycle. The reason is that lifecycle class could have a lot of injected dependencies which could and probably would cause circular dependencies since CMSApi is one of the core components of play-cms. Decoupling was made by introducing new class CMSInitializer which has constructor only where CMSApiLifecycle#onStart and CMSApiLifecycle#onStop methods are executed. Additionaly this change fixes memory leak on app restart (e.g. in tests). CMSInitializer has been registered as an eager singleton so we can be sure that it would be initialized as soon as it possible.

There are few reasons why I implemented decoupling in this way:

  • Guice doesn't support @PostConstruct/@PreDestroy annotation and there no easy way to execute method after bean was initialized.
  • onStart() cannot be run in constructor since CMSApiLifecycleImpl high-likely would be overridden and would cause NPE when it try to access properties introduced in inherited class since they wouldn't be initialized when super() is called.
  • this approach doesn't require large changes in existing code

Please note that this change will break compatibility since it changes signatures of CMSApiLifecycle methods, introduces new constructor argument for the CMSApiLifecycleImpl and removes parameters from CMSApiImpl constructor.

Merge request reports