> -----Original Message----- > From: Leo Simons [mailto:[EMAIL PROTECTED] > > Currently we have lifecycle extensions, but these are not yet supported > by > > Phoenix. > > patches welcome though!
I'll look into this. There's a set of patches I've been working on for Fortress that would allow easier configuration of lifecycle extensions too. > For those of you who do not like examples, some complex prose... > It is very difficult to predict in advance where the vector of change > for container architecture internals lies, since many modifications to > those internals are domain-specific. Hence we must strike a balance > between type safety and flexibility. Maximum flexibility is gained > through utilizing container internals that use "flexibility patterns" > like interceptors, pipelines, events, scripting and declarative assembly. My current approach has been looking at domain specific extensions, ie- lifecycle extensions, assembly extensions. The new deployment stage extensions in merlin basically allow you to get a hold of the Appliance, but even that may be exposing more than would be desirable. You're correct though in that it's difficult to strike the right balance. > > The root of the problem here is that no agreemnt exists between the > containers about how much their contexts need to provide. Like "part of > the container-component contract is that the container will provide a > 'working directory' to the component on request, and that this working > directory will be available through the context". True and I think this is exactly what is needed: a container-component contract on standard context values and a context extension API. I've been meaning to add a page in Wiki that reviews in more detail how the three containers handle contexts. Seeing everything side by side might help point out a solution. jaaron --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
