Leo Simons wrote:
Steve, Pete, Paul,Yes - that's correct. It is intended to be a set of classes that are reusable across containers.
if you ask me, Paul is right with regard to the seperation of spec and
default impl -- putting it at the jar level is nice, and consistent with
A-F.
Also, I don't think the excalibur container package should neccessarily
be limited to only default impls of the client side; it's very name
implies it is also about the other side, doesn't it?
I disagree that putting those two particular classes there forces any convergence. The particular implementation isn't something that makes sence relative to Merlin - it only makes sence relative to Fortress.Next, I think putting the classes in the container package sort-of 'forces' more convergence between merlin and fortress as the container package is sort-of common ground. Which I like ;) And when that convergence happens, there is nothing to prevent modification of the classes in container to match the changed implementation. right?
The Fortress approach basically istantiates all extension handlers for a component and then these are passed to the extension manager collectively and applied to the component. In Merlin the application of the handler is the point where a handler is assembled (if and only if the extension meta data indicates that the handler is required).
Getting a common solution on this requires more work on the meta side - in fact that's what I'm working on today - getting the excalibur/meta updates in place so Marcus can use this in the xfc package.
Cheers, Steve.
Finally, I think regardless of all that I like the setup that will be
quickest to get fortress to release quality best, if that matters in any
direction. I'm very happy to see Pete work on fortress :)
cheers,
- Leo
--
To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
-- Stephen J. McConnell OSM SARL digital products for a global economy mailto:mcconnell@;osm.net http://www.osm.net -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
