Details
-
Type:
Improvement
-
Status:
Closed
-
Priority:
Critical
-
Resolution: Fixed
-
Affects Version/s: 2.0.0-M1
-
Fix Version/s: 2.0.0-RC1
-
Component/s: Core: Configuration
-
Labels:None
-
User impact:High
-
Similar Issues:None
Description
This is a bit vague because I don't understand all the issues.
However, it appears that the model initialisation process has changed in 2.0. It seems to be performed during Spring assembly which means that it occurs in a bottom-up manner: Spring generates a tree of objects and starts with the leaf nodes, creating and initialising them first, then creating parent nodes into which the children are injected.
I am not sure how things worked before, but the current approach causes problems because some information has to pass down through the object tree before components can be initialised. In particular, the endpoint type seems to be defined by the router in which it is embedded. So the endpoint does not "know" its own type until injected in a router, yet objects lower down the object tree require this information to initialise correctly themselves.
This has led to two problems, I believe. First, security filters need to know the endpoint type. To handle this I have changed the initialisation to be "lazy" - it is done the first time the filter is used. Second, I think the problems I had with transformers may be related to the late setting of type. By default the endpoint type is "send and receive". This is the value my tests cases were using – I suspect that they should in fact have been using send or receive, but that the transformers were chosen before this value was set (I have not verified this).
There is also a general impression, when rewriting tests, that "initialise" calls are somewhat random (IIRC endpoints now don't need them, while components do?).
I feel we are drifting towards an ever more ad-hoc initialisation process. My initial suggestion is to make intialisation a recursive process, performed after assembly, in which parents call intialise on their own children. This allows information to be both pushed down and pulled up the object tree.
At the same time there has been discussion on lifecycle issues which may be related. I have no idea how lifecycle is controlled - it's not something I have worked on yet. So this issue maybe addressed or involved in that work (whatever it is).
Spring-specific solution might be to use "afterPropertiesSet" (from comment in acegi delegate).