@AfterMapping methods or content mappings may cause BeanCurrentlyInCreationException when the same model type is instantiated as part of the method invocation #375
In NEBA 5.1.0, the model and bean lifecycle where consolidated (see e.g. #358). However, the post-processor used to apply the content-to-object mapping was made to do so during the postProcessBeforeInitialization phase, based on the assumption the prototypically scoped Spring beans can be instantiated at will, even if a prototypic bean of type A instantiates another instance of Type A during its initialization.
However, Spring regards this as a programming error. Consequently, Spring models that greedily create another instance of its model type, e.g. Page->Page, will fail when all of the following is true
Spring is used
The instantiation is greedy or in an @AfterMapping method (@AfterMapping is deprecated)
This problem arises from a fundamental mismatch between the understanding of instantiation semantics within Spring vs. a persistence framework, prototype scope, in Spring, assumes that a single, non-nested instance of a particular bean definition is created as part of the getBean invocation and regards a circular dependency to the same bean definition as a cycle.
persistence frameworks, on the other hand, deal with graphs of objects in which cycles - such as referential relationships - occur naturally.
Thus, the life cycle of content-to-object mapping (where cycles occur) and bean instance creation (where cycles are prohibited) must be separated.
It is thus clear that the implementation of #358 was a mistake and needs to be reverted to the extend that
While NEBA core is unaffected by this issue, semantic consistency demands that @AfterMapping remains available for both spring and non-spring use cases.