> *** Vote *** > As such, can we vote on the recommendation : > > (*) The Avalon team recommends that Phoenix compatile container include > phoenix-client.jar in their distribution and make it visible to hosted > components at runtime. The Avalon team recommends that Phoenix > compatible containers hide their implementations of BlockContext in the > kernel's classloader and further hide the impl via use of a > Refelection's dynamic proxy.
considering that - phoenix is in beta - its API should remain stable - I want a release sooner than later - it should not be tremendously difficult to support phoenix-client at some level in a new container, though it might be suboptimal I am +1 I'd like to add explicitly though that the recommended way to write components is not to depend on phoenix-client or any of the additional constraints/features phoenix offers. However, for components specifically targetted at phoenix, the proposed path is the best way to ensure the above goals (ie get a phoenix release). I agree with Stephen that he is right wrt to architectural discussion (there should be a GenericBlockContext rather than a MerlinBlockContextProxy), optimal implementation, etc. Thing is, avalon is not as perfect as we'd like it to be and this is a sort-of workable workaround. Finally, I like the phrase "recommends". We do not want to require this strategy for all containers in avalon CVS, as there are some definite disadvantages to it. that's the best I can make of it. cheers, Leo -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
