Re: cvs commit: jakarta-avalon-excalibur/container/src/java/org/apache/excalibur/container/l ifecycle AbstractLifecycleExtensionManager.java LifecycleExtensionManager.java

[Leo Simons <le...@apache.org>]

Steve, Pete, Paul,

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?

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?

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: cvs commit: jakarta-avalon-excalibur/container/src/java/org/apache/excalibur/container/l ifecycle AbstractLifecycleExtensionManager.java LifecycleExtensionManager.java

[Stephen McConnell <mc...@apache.org>]

Leo Simons wrote:

>Steve, Pete, Paul,
>
>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?
>  
>

Yes - that's correct.  It is intended to be a set of classes that are 
reusable across containers.

>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?
>

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.  

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:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: cvs commit: jakarta-avalon-excalibur/container/src/java/org/apache/excalibur/container/l ifecycle AbstractLifecycleExtensionManager.java LifecycleExtensionManager.java

[Paul Hammant <Pa...@yahoo.com>]

Leo,

>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?
>
<pedant>
A-F stuff is not just about client/server.  Its interfaces and impls 
(hidden by proxy or not, remote or local) can be used anywhere :-)
</pedant>

- Paul



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>