> From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
> >
> >Things that the *user* of Fortress needs to concern himself
> >with should be in the root **.fortress package. Things that
> >are necessary for the internals of Fortress should be in a sub
> >package.
> >
>
> This is an issue I've been bumping up against with the
> Assembly/Merlin/Meta work.
>
> There are different clients
>
> * the client that needs to interoperate with the
> container-componenet artifacts (traditionally the framework
> stuff - but also included the client interfaces of extensions
> and possibly other _artifact_ interfaces that a container
> provides.
>
> * interface used by _clients_ that are extending or using a
> container in some fashion (e.g. in the Assembly environment -
> things like Engine, Appliance, and ApplianceContext - or in the
> case of Merlin - Block, Container, etc.)
>
> Perhaps good terms for distinguishing these two are:
>
> * consumer interfaces
> * developer interfaces
Right. here is the breakdown of terminology that I try to use:
Container -- provides management and resolution of component requests
to components. Includes both runtime and assembly time
management.
Component -- I think we are clear on that
Client -- *code* that uses a component or container.
The problem is when we apply these terms to humans.... I think that
consumer and developer is a good way to distinguish.
Consumer -- human that uses code (component, container, library, etc.)
Developer -- human that maintains and alters code.
>
> Which means your breaking out three things:
>
> * consumer interfaces
> * developer interfaces
> * implementation
Correct.
> >The Container interface is supposed to supply the methods that
> >are necessary for the FortressServiceManager/Selector to find
> >the actual components being managed by the container. It isn't
> >necessary at all if the container does not use those classes.
> >
>
> Just a note based on the above comment - what your describing
> above is
> what is referred to in the Assembly package as the Engine - its the
> thing that provides the component. Merlin defines a container as the
> thing that handles the _runtime_ management of the state of a set of
> coponents (startup, shutdown, etc.). My hunch is that the resources
> that are exchaged across the Fortress container interface
> corrrespond to
> the Assembly package notions of Appliance, ApplianceContext
> and Engine
> (as the manager). I need to do some more digging into this -
> but if I'm
> right its a key to understanding where convergence points are
> relative
> to Fortress and Assembly.
If I recall, you are providing a finer breakdown of things
in the Merlin infrastructure. My notion of a container is
a larger context. I.e. an EJB Container and a Servlet
Container can be managed by the same Kernel.
The specific containers setup, manage, map, and controll all
of its components. That means that there is both runtime
management and the assembly time management of components.
In my mind there is no distinction.
> I'm hesitating on commenting here because I think that the
> usage of the
> word "container" is different to my understanding of the work
> (which is
> heavily influenced by the Assembly and Merlin seperation of assembly
> versus runtime concerns). My hesitation is based on the fact
> that a lot
> of what your saying seems to correlate with a lot of the Assembly
> package notions - but the assembly package has almost zero runtime
> behaviour management - its all about deployment - and Fortress is a
> rutime containmet solution - i.e. I'm getting myself a little
> confussed
> at this point! But don;t be too worried - I need to do more
> homework on
> Fortress.
Right. In Fortress there is no distinction. Also keep in mind
that when there is no distinction, it also means that "reassembly"
can occur at runtime. If I want to change the default implementation
of a Component at runtime I can do that without having to stop and
restart. The next time the component is requested, it will be
the new component.
> >>>of course, you can put the metadata in the initial context
> >>>and define a specific contract there, which is okay with me as
> >>>well, but I think the contract must be there. IOW, how you tell
> >>>a Container (Container in the fortress world) which components it
> >>>should manage and have available should be part of its contract.
> >>>Right?
> >
> >Fortress is not currently using Meta data. Right now it is
> >aimed at being a replacement for ECM which means it uses the
> >RoleManager. The contracts are understood (to some extent)
> >by ECM users.
>
> But for all practical purposes - RoleManager is a vehicle for
> manipulating
> what is effectively meta data.
Right. The distinction being that Forterss is not using the
formal Meta Data as defined by Merlin or Phoenix.
> Berin - can you take a look at the
> org.apache.avalon.assembly.appliance.ApplianceContext interface - is
> this basically the same sort of thing that your providing to a
> ContainerManager ?
>
> I.e. is the following true:
>
> Cotext == ApplianceContext
> ContainerManager == Engine
> ??? == Appliance
I believe that is true.
The Appliance contracts that you have separated are merged into
Container in Fortress as well.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
