and what this discussion is leading to, I am very sorry about. I have exactly the same need as Steve here (complete portability of components between a) phoenix, b) cocoon/tomcat, c) custom in-house container (for which we might just start using merlin if it gets a release and I figure out exactly what it does and doesn't do), d) potentially the turbine container Jason's working on).
I haven't got the cycles to participate in these discussions recently; I had the idea that y'all were on the right track. Though I don't fully understand the implications of going the getContext() road (so I have some reservations), I have yet to think of another way to achieve "complete portability" of context, other than putting the burden for doing so back on the assembler's shoulders. Which I like even less. If there really are personal/technical problems here, I suggest putting the context-specific part of containerkit Steve proposed (the stuff Pete has problems with) into the merlin directory, yet in the containerkit namespace. If it does take off and people like using it, that'll solve the argument and it'll be easy to move back. We're still talking unreleased alpha software here; it is okay to not agree on everything yet. Of course, (especially since I haven't contributed any code here yet), feel free to ignore my sentiment and go your separate ways. We'll just live with Avalon Framework v4 as the only common ground. best regards, - Leo Simons > >> NO NO NO &%#####**!�$%^& > >> > >> I would like to see different containers using containerkit. I would > >> prefer that the center of interoperability is based on containerkit. > >> I've provided several examples of why containerkit breaks this for > >> existing components and goes against the general component model as > >> documeted. I've provided info on how an implementation can address > >> this in response to your claims that it is impossible. I've put up > >> with being accused of of having an IQ in the single digit range, > >> accused of strange and amazing anti-component practices, I'm now > >> accused of attempting to force a solution! Please keep in mind that > >> your objection to the original proposal of a accessor to context was > >> on the grounds that (a) it was exclusively a container concern, > >> following which you raised the assertion was made that it was > >> impossible anyway (leading to a lot of explanitory emails explaining > >> how it is possible). > > > > > > Containerkit is about consolidating practices in containerkit. What > > you propose is not common through containers, and can be implemented > > fine in any particular container. You notice there is also no > > ConfigurationSchema/ParametersSchema or LoggerMetaData or anything > > like that. > > > Come on - try a little harder. Configuration and Parameters don't have > an explicit ContextDescriptor that declares constraints. Please - if > you going to be difficult then at least put the time and effort into > addressing the issue. You are sating that as far a potable container is > concerned - context is out of bounds. and yet you include a context > constraint criteria. You then argue that the context constraint > criteria is great (because you are the author) - and then you object to > any possibility of a container neutral approach to a mechanisms to meet > that criteria. > > You justify this bizarre idea on the grounds of personal attacks, > technical impossibilities, false assertions of forced conditions on > implementation, and now it gets even worse - your proposing that > containerkit is reflecting a recommended practice of neglecting existing > implementations and users and ignoring what exists in the framework > today. I really don't want bother with it any more - you have decided > that this is not an issue and it does not matter when anyone says. You > will not even bother to even try to understand the issue -- all it means > is that containerkit is NOT a portability platform - its Pete's > architectural masturbation which at the end of the day may be the > abstract foundation to something else that delivers the real solution. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
