NEBA 5.1.3 contains a critical fix for an issue introduced in NEBA 5.1.0. In NEBA 5.1.0, the resource-to-model mapping lifecycle phase was integrated into the Spring bean creation lifecycle such that @PostConstruct would be applied after dependency injection and content-to-model mapping where executed. However, this created a semantic mismatch. Content-to-object mapping is usually applied to an object graph. Object graphs naturally contain cycles or multiple nested instances of the same model type. For instance, a model for Comment might posses a list of comments as a member representing replies, and may eagerly initialize those.
Nested model instances could thus mean that the same prototypic bean could be obtained multiple times during bean instantiation (Comment.init -> factory.get("comment")). Spring, however, assumes a programming error in such a case and reports a cycle. Thus, the content-to-model mapping phase cannot be integrated into the Bean lifecycle, but must be applied after a bean has been retrieved from the application context. This means that @PostConstruct will always be invoked prior to content-to-model mapping.
Consequently, users of Spring beans as resource models must use @AfterMapping when an initialization method requires mapped content or initiates content-to-model mapping.
NEBA 5.1.3 also contains an improvement of the request-scoped resource model cache that can lead to a better cache/miss ratio.
Usages of @PostConstruct in @ResourceModel beans must be reviewed and must be changed to @AfterMapping whenever content-to-object mapping is required for the initialization, e.g. when the initialization relies on mapped members or performs adaptation from resources to spring-based resource models.