Re: [a4:fortress] refactoring, contracts, exceptions

[Leo Simons]

Berin Loritsch wrote:

So you are talking about Fortress, not Framework?

yes.

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.

We need to seperate:
* container user
* container developer
* container framework

point being, the container user will actually use a container implementation developed by the container developer, which is built on top of the container framework.

We can simplify and merge container framework and container implementation, but we need to make a choice, not do it half-and-half.

I think that fortress should define the interface the container user will use to interact with the container implementation to the maximum extend possible.

The list of interfaces that the user interacts with are:

you mean "end user" or "container developer"?

Container, ContainerManager, ContextManager, LifecycleExtensionManager,
InitializationException

The interfaces that are internal to Fortress are:

ComponentHandler, RoleManager, RoleEntry, (ComponentHandlerMetaData)

stronger contracts
------------------

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.

This sounds like the Container interface is something that the FortressServiceManager interacts with. Which means it is not/should not be what the end user interacts with.

Also, shouldn't the Container interact with the ServiceManager rather than the other way around?

The first thing you'd probably do with the classes as-it is

now would be:

DefaultContainer c =
   (DefaultContainer)myContainerManager.getContainer();

Not necessarily.  The container has the logic necessary to load
up the components it is using.

So if the container does everything itself, why does the end user need an interface to interact with? I Just Don't Get It I Guess.

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.

Not by me :D Exactly the point: those contracts need to be explicit, so everyone can understand to complete extend.

I don't get your RoleManager comment. If it is internal to fortress, why/how is the user aware of any contract with the RoleManager?

ContainerManager <-> Container?
-------------------------------
What's the exact relationship between these two? What are their respective roles?

The ContainerManager is really the "Kernel" for Fortress.
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.

note: merlin and phoenix have different names for this than you're using here. In particular, in phoenix, the Embeddor provides the neccessary system services to get a Kernel running, and the Kernel then sets up an Application. It sounds a lot like

Fortress Phoenix
------------------------------------------------------
<user code> Bootstrapping/Loading code
Kernel/ContainerManager Embeddor
<not clearly seperated out> Kernel
Container ServerApplication

am I on track here?

The issue with the ContainerManager is that [those system services]
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 am getting more and more confused...maybe a diagram helps....is it (globally speaking) correct?

--------------------------------------------------------------------
userspace code * ContainerManager * ContextManager * Container
| | | |
|-getcontainer()->| | |
| (optionally, | | |
| with an | | |
| initial | | |
| context) | | |
| |-getservices()->| |
| |<------context--| |
| | | |
| |-createinstance()-------------->|
| |<-------------------newinstance-|
| |-setservices()----------------->|
| |-setcontext()------------------>|
|<----newinstance-| | |
| | | |
|--what does the user do here? Why is there an---->|
| interface here? |
| | | |

I can see where the lifecycle extension manager goes (the user can put it in the initial context, or configure it through some other mechanism for a specific container implementation). Where's the RoleManager? Is it internal to Container? How is the Container populated? Is that completely implementation-specific?

g'night!

- Leo



--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>