Gang, 1. Should Initializable.initalize() be invoked on prototypeFor()?
At the moment, when prototypeFor() (and prototype() I guess) is called on TransientBuilder (probably ValueBuilder as well), the mixin's initialize() will be called. That means that the Composite is not really available (predictably) to the Mixin at this point. 2. Do we have a solid object lifecycle story at all?? While writing this mail, I start to think that the object lifecycle model is severely flawed, and possibly not easily fixed here and there. I think we need to dig through the requirements from the ground up. I think that the Fragments and the Composite need to be separated. I also wonder if we can indeed utilize finalize(), to get pre/post semantics uniformly across all composite meta types... Does anyone have a very strong understanding of how finalize() works, and why it is said to be "bad" to use it in programs?? What I would like to see is pairs of annotations with strong semantics, something like (maybe better names) @OnEntityCreation // called on EntityBuilder.newInstance() @OnEntityDeletion // called on UnitOfWork.remove() @OnCompositeConstruction // called when in-memory instance created @OnCompositeDestruction // called via finalize() or UnitOfWork teardown. @OnMixinCreation // Called after Mixin constructor call. @OnMixinDestruction // called via @OnCompositeDestruction I am not sure if we need to separate the prototype/prototypeFor creation from the instantiation of 'final' Mixin instance that goes into the Composite. And in the process "fix" the ServiceComposite story as well, i.e. @OnServiceActivation @OnServicePassivation And in the process get rid of the all the related interfaces; Initializable Lifecycle Activatable ServiceActivator and so on. Any thoughts? Cheers -- Niclas Hedhman, Software Developer http://zest.apache.org - New Energy for Java
