> From: Leo Simons [mailto:[EMAIL PROTECTED]] > > Could someone please fill me in where this little analysis goes awry?
Nowhere, really, if you can pull it off. But I agree with Peter Donald's arguments against lifecycle extensions. Nice in theory and all, but how are you actually going to *do* it? I have taken a look at Merlin (these classes: http://cvs.apache.org/viewcvs.cgi/jakarta-avalon-excalibur/assembly/src/ java/org/apache/excalibur/container/lifecycle/ ) and as far as I can see, the pluggable pipeline stages (or phases, or whatever), are limited to act on (1) the component/object and (2) the Context. So... not only will the component have a type specifier that explains what context entries it requires and what special lifecycle handlers it requires - those handlers will also have a context requirement. So if you have a SpiffyLifeCycleStage that makes components all spiffy as they come through it, how is that SpiffyLifeCycleStage going to do it without support from the container to put a Spifficator (the means to make a component spiffy) in the context? If you have a PersistentLifeCycleStage, how are you going to obtain the persistence mechanism if the container doesn't give it to you via the context? The problem with populating the context with any non-constant entries (such as a Spifficator) has already been discussed and found to have no solution short of mind-reading the programmer and sprouting new code on startup/linking. If I am missing something, and there are solutions to the problems I outlined above, please fill me in. At the moment, the lifecycle extensions appear to be shiny new features that while nice in theory are useless in practice. I'm afraid that any container trying to implement them in a useful way will (1) never be completed and (2) implode under its own weight. It's just too much "do everything", too much genericism, in it. Miscellaneous issues: + Will the lifecycle handler need a component/service manager? How will a DB-persistence handler work? Will it use the Excalibur Datasource component? How will it access it? + If the handler requires another component, has a context and surely will need a configuration, what is the difference between it and a component? + Go back to the final proposal for A5. Doesn't it solve everything by allowing/requiring you to specify handlers/factories for components? /LS -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
