Spring Integration

[boubaker]

Rationale

The Development frameworks, standards and dependencies evolves over the time very quickly. Currently, we have a custom stack of Core features that even implements some JSRs. This stack of features is very hard to maintain and evolve. Most of implemented JSRs are outdated and even are incompatible with new Jakarta EE specifications.

Knowing that Meeds product aims to provide high level applications rather than being a framework provider, we will need to reuse a set of third party libraries to ease the production of features.

In order to make Meeds product development process smoother and community learning curve optimized, we aim by the current MIP of making Spring Framework the new core framework.

1. Functional Requirements

No functional change is needed.

2. Technical Requirements

Expected Volume & Performance

No performance regression should be observed by this MIP.

Security

No major change in the Security model has to be made, we still using deprecated PicketLink IDM library until this first step of Spring integration is made.

Extensibility

The old definition of Meeds Kernel IoC components has to remain possible in addition to the fact that Spring Beans are possible to use as well. This should help to progressively migrate Components from Kernel IoC definition to Spring Beans.

Configurability

The usage of Spring has to remain builtin and doesn't need additional JARs installation.

Upgradability

No need for data upgrades in this MIP. The data stores should remain exactly the same.

Existing Features

A first addon full upgrade has to be made to make it as an example of Spring integration.

Feature Flags

No feature flag is needed.

3. Software Architecture

Security

A Spring integration has to be made to reuse the existing JAAS login module gatein-domain. This login module with its map of roles has to be mapped with Spring Security in order to use @RolesAllowed or @Secured in Spring Rest Controller Beans.

Access

The REST endpoints of each addon has to be accessible from the WebARchive of the addon itself. We will no more need to use a single entry point for all REST endpoints (/rest). This will help to separate the addons in Microservices when need in the architecture evolution later.

Services & processing

Each addon will be able to define its own Spring application by using the following annotation:

@SpringBootApplication(
  scanBasePackages = {
      "io.meeds.XYZ",
      "io.meeds.spring.integration"
  }
)

The package io.meeds.XYZ is the specific package of the addon that will be used to scan for components.
The package io.meeds.spring.integration has to be used as well to allow retrieving the builtin beans used to make the integration between Meeds Kernel IoC and Spring Beans. The beans of this package aims to:

• Make Meeds Kernel IoC single Service instances injectable using @Autwired or similar annotations (like @Autwired)
• Inject Application Spring Beans into Meeds Kernel IoC in order to make it accessible using container.getInstanceOfType
• Disable Logback initialization in WebApp context after having initialized it already in Meeds Server globally
• Propagate JAAS principal into Spring Security Context for a given user Request on API
• Initiate ExoContainerContext.setCurrentContainer and RequestLifeCycle.begin for Transaction management for each HTTP call on Application REST endpoint.

Data and persistence

No data model change

[boubaker]

Not prioritized for now

[boubaker]

Ready for tech spec review by DAO Members (eXo : @rdenarie )

[boubaker]

All PRs Merged.