Spring in Portofino

Portofino 5 includes the Spring dependency injection framework and, from version to version, has integrated Spring progressively more tightly.

Here we document the integration of Spring into Portofino.

Architecture

The following is extracted from PortofinoContextLoaderListener's documentation.

[In Portofino, the Spring application context] is made of 3 layers:

• Parent context - defines Portofino's own beans and modules. It's created once at application startup and destroyed once at shutdown.
• User context - defines beans according to the user-provided SpringConfiguration class, if any. Otherwise it's an empty context. This context is reloaded automatically whenever the source code of class annotated with Component, org.springframework.context.annotation.Configuration, @Repository or @Service changes, and it can also be refreshed programmatically, via the refresh() method. Note that such capability is meant to aid development, and NOT as a kind of hotswap for production. Requests will fail during a context reload. In fact, in production it can be deactivated by setting the init parameter reloadContextWhenSourcesChange to false in the deployment descriptor (web.xml).
• Bridge context - a singleton application context meant to be exposed to outside consumers. It has the user context as a parent and it's created and destroyed only once.

From the above, we learn that:

• Portofino defines some platform beans in its own context;
• we, as users, can define additional beans in a user context;
• both contexts are combined and exposed to the application.

In particular, the "user context" is an optional class (Java or Groovy) named SpringConfiguration in the default package. When written in Groovy, it supports hot reload during development.

Modules

TODO

Injection

TODO actions and modules

Using XML Instead

TODO

Spring Boot

TODO

Working With Archetypes

TODO war and service