Paul Hammant wrote:
when asked for that key. And nothing *prevents* a component from directly casting, except that the component is then <i>tightly tied to Phoenix</i> because this is <i>not defined in the Framework</i> contracts.Sorry to be pedantic. No that component is tied to BlockContext which is part of Phoenix, but ships in a client api jar. There has been discussion before about how trivial to implement for a container this is. We even voted it should be the case for Merlin. Nobody made the change though. Too much respoect for Stephen, his resistance to that resultion, and not enogh sub-project karma.
LOL
Go back and take a look at the vote in question - you could hardly call the vote itself as somethig clear and unambigouse - it basic was a statement saying that it is recommended that if a container wants to be compatible with Phoenix it should maintain a copy of phoenix-client.jar in its distribution and in addition - and an attempt to explain how people should develop things.
I didn't register a vote on that particular vote because Merlin itself does not need to be Phoenix compatible because it has framework within which clients can add compatibility solutions - i.e. the client's deployment may be compatible with Phoenix and a context implementation supplied to Merlin may be Phoneix compatible.
End result was that the vote itself was academic. There was no impact on any other container either way.
It made zero contribute to addressing the real issue.
I.e. the vote and the result the vote have nothing to do with "respect", "resistance" or "karma".
Cheers, Steve.
Other containers might want to provide a BlockContext, without having to tie their *implementation* of Context to the interface, and implement the BlockContext in a better way than IS-A. (Reusing the Phoenix implementation fo BlockContext, but having their own Context implementation, for example. ).They can do that, but must have a comp that IS-A, that may delegate to whatever they want.
So, in framework, we include in the contract definition: "You should *never* cast the context to another interface, unless you want to tie yourself to a single container.You are so not tying yourself to a single container.
1) A container may emulate as many other containers as it wishes. The impl it returns for Context can implement any number of interfaces, many or all of which the component itself may not use. People may disagree this is right, but I will *not* shift on possibility.
2) We have talked over constituent Context interfaces to arrive in A-F. ShutdownRequestable { void requestShutdown(); }. If al the methods offered by BlockContext were seperately available in A-F (and BlockContext extended those interfaces) a container could be Phoenix compatible without importing a single Phoenix jar. Leo Sutic posted code that deomostrated this. This advanced Java surprised ad pleased me.
If a context interface is available by casting, it will *always* also be available through a named key, defined and documented by the container."
breaks back compat.This way, Phoenix clients continue to work, but we don't have to use it as a model for the way context should work.you mean continues to work if the use Context differently.
-ph
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- Stephen J. McConnell OSM SARL digital products for a global economy mailto:[EMAIL PROTECTED] http://www.osm.net -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
