Nicola Ken Barozzi wrote:
Berin Loritsch wrote:Leo Simons wrote:Hi peeps,
I just committed lots of new files to fortress. I've moved fortress to a new package, org.apache.avalon.fortress, and also moved around lots of other things, basically like proposed and discussed before. Could y'all please check it out and tell me if you're okay with it?
If so, I'll update the examples and remove the old materials.
thanks!
cheers,
Now how would that affect the fact that we are trying to do Avalon Container with codenames? The first release being codename Fortress? As we switch codenames, we should not have our users change the package that they use.
I was thinking the same thing ;-)
But looking at current implementations, I don't think they will be able to use Merlin2 as a drop-in replacement to Fortress... or will they?
I think you need to seperate two things here. One view is the semantics exposed by artifacts provided by a Fortress system to the compoents it is managing - and the other view is the view seen by a developer of an application using Fortress interfaces and classes.
Fortress (following in the tradition of ECM) handles dynamic component resolution. This contrasts with the Merlin approach of preemptive assembly. However client interaction with things like component and service managers get redirected to a containment system. Both Merlin and Fortress are containment systems. The integration point of Fortress within Merlin comes done to either (a) Fortress as an Appliance implementation, or (b) Fortress as a container implementation.
The above distinction is important. If Fortress is an appliance implementation, then we have the potential for a Merlin container to simultaneously handle Phoenix style components, Merlin native compoents, and Fortress/ECM with the same container. This is the fine grain integration (although even finer grain is possible if we dig into plug-in lifecycle strategy management). This strategy (Foresss and an Appliance implementation) means that we are focussing integration of Fortress as a package implementing the appliance interfaces (Appliance, ApplianceContext, ApplianceFactory) - i.e. this is all independent of the Merlin package and concerns synchronization at the level of the Assembly package.
An alternative approach is Fortress as a container. In this context we would be looking at Fortress implementing the Merlin Block interfaces. This is similar to the above (because Block is an Appliance). The difference between Block and Appliance is that a Block manages a set of contained appliances.
This brings us to the crunch. Client interacting with framework interfaces can be managed without pain (at least no pain for the component authors). Developers that have extended ECM or developers that extend Fortress classes will need restructure when transitioning from ECM/Fortress to Merlin and Fortress/Merlin. Some of this pain should be reduced by tools - but my guess is this will impact the component author much more that container authors. For example, it will be possible to migrate role configuration files to a XML or serialized meta descriptors - but this will be of limited help to the container author. The benefits for the container author are much more related to "containment" functionality that is provided over and above their current solutions.
Are Fortress' APIs gonna become our standard container APIs?
The real kicker here is focus - a Merlin/Fortress combination is about combining people and developing gravity and all that stuff. I'm confident that interfaces I've talked about above will evolve as we move forward - but at the same time I know a lot of these reflect and leverage from similar concepts in Berin's work in Excalibur projects. I.e. there are problems we will have to deal with - but its going be fun dealing with them.
I guess all of the boils down to the following - developers should not need to extend containers APIs - if they are it means that our container isn't providing what they need and we need to know about that. Is this a feasible conclusion? I think so. I don't see big differences between the Cocoon block needs compared with a James Mailet container - what is important is how component requirements are expressed to a container, and the ability/functionality of a container implementation to support these requirements. In the respect Cocoon is an interesting scenario because there appear to be genuine cases for block extension. The key things there will be to enable this intelligently such that container development can proceed with minimal impact on dependent authors.
Cheers, Steve.
--
Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
