Hi Berin: Just some informal notes in-line.
Berin Loritsch wrote:
It's a Fortress question (and yes - there have also been comments re. framework on the same thing).From: news [mailto:[EMAIL PROTECTED]]On Behalf Of Leo Simons
re-sending myself because you guys are confusing me...
Leo Simons wrote:
Hey peeps,time. I like
some thoughts/questions/suggestions....
package refactoring
-------------------
if we want to do some renaming and refactoring, now is the
doing the interface<->impl seperation stronly (re: the waypaul set up
AltRMI), I think it'd be real beneficial for fortress.change single line here:
For example:
org.apache.avalon.fortress.interfacesto:
org.apache.avalon.fortress
so no-one trips over it, then please comment on the main subject of the e-mail, which sort of is "I think Fortress needs stronger contracts, do you agree? What should they be and how should we do it? Do we do it now or after a release?" rather than spent hours debating the example :D
I feel like I'm speaking chinese here...am I being so terribly unclear today?
So you are talking about Fortress, not Framework?
This is an issue I've been bumping up against with the Assembly/Merlin/Meta work.ComponentHandler (I)
Container (I)
ContainerManager (I)
ContextManager (I)
LifecycleExtensionManager (I)
RoleManager (I)
InitializationException (E)
ComponentHandlerMetaData (C)
RoleEntry (C)
org.apache.avalon.fortress.impl
.handler
<blah>ComponentHandler
<relatedclassesandhelpers>
.lookup
FortressServiceManager
FortressServiceSelector
.role
AbstractRoleManager
ConfigurableRoleManager
ExcaliburRoleManager
AbstractContainer
DefaultContainer
DefaultContainerManager
DefaultLifecycleExtensionManager
org.apache.avalon.fortress.util
ContextBuilder
FortressConfig
OverridableContext
Pros? Cons? I know there's refactoring tools that can do this seamlessly (got a trial of IDEA 3 right here which seems to do it rather nicely, only it puts real.long.class.Names all around the code), so I'm not too worried about impacting code stability.
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.
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
That means that the ComponentHandler stuff should be in a sub package because the average user doesn't need to concern himself with it. The list of interfaces that the user interacts with are: Container, ContainerManager, ContextManager, LifecycleExtensionManager, InitializationException The interfaces that are internal to Fortress are: ComponentHandler, RoleManager, RoleEntry, (ComponentHandlerMetaData)
Which means your breaking out three things: * consumer interfaces * developer interfaces * implementation
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.
stronger contracts
------------------
even if this seperation is not as rigourously made, I think it would be beneficial to at least more clearly and extensively define the Container, ContainerManager, RoleManager, ContextManager and LifecycleExtensionManager roles and contracts. In particular, the Container interface contains so little entries as to make it next to impossible to use it.
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.
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.
The first thing you'd probably do with the classes as-it is now would be:
DefaultContainer c =
(DefaultContainer)myContainerManager.getContainer();
which kinda ties you down and throws away the reuse (which is acceptable, but we should remove the "framework for building your own container" idea in that case). The way I see it, you want all Containers to at least support addComponent and removeComponent in addition to get() and has().
Not necessarily. The container has the logic necessary to load up the components it is using. <snip/>
:-)
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.
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 ?
The ContainerManager is really the "Kernel" for Fortress.ContainerManager <-> Container?
-------------------------------
What's the exact relationship between these two? What are their respective roles?
I was wanting to formalize a "Kernel" and started the process
under the "ng" src tree. The ContainerManager in its first
form made sure that the system services like LoggerManager,
PoolManager, ThreadManager, etc. were up and running.
The issue with the ContainerManager is that all that stuff
is passed in via the Context. Much of the logic has since
been refactored into the ContextManager to help make it easier
to set up the initial Context.
The ContainerManager/ContextManager combo does check to see
if the necessary kernel services are already in the Context
so that they do not need to be created again.
I.e. is the following true:
Cotext == ApplianceContext
ContainerManager == Engine
??? == Appliance
?
Big TODO
--------
One thing I think needs addressing is the exception handling. There's javadocs all over wrt whether the right decision is made about what exception to throw. RTE vs normal ones, specific vs builtin. I don't have too strong an opinion yet, but this stuff needs to be agreed upon before any release IMO.
I agree.
Ok. (WRT? what is that?)
"With Respect To" ... Cheers, Steve.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- 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]>
