avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject Re: [a4:fortress] refactoring, contracts, exceptions
Date Sat, 18 Jan 2003 01:30:49 GMT
Berin Loritsch wrote:
> So you are talking about Fortress, not Framework?


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


- Leo

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message