Leo Simons wrote:
Berin Loritsch wrote:
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.
RIght.
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.
It's not easy to do in the general sense. Swing programs have one set
of requirements and Servlet based programs have another.
The best we can do is expose a getServiceManager() method to get the
lookup mechanism from the Container.
The list of interfaces that the user interacts with are:
you mean "end user" or "container developer"?
Container, ContainerManager, ContextManager, LifecycleExtensionManager,
InitializationException
For this set, "end user".
The interfaces that are internal to Fortress are:
ComponentHandler, RoleManager, RoleEntry, (ComponentHandlerMetaData)
And for this set, "container developer"
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.
Correct.
Also, shouldn't the Container interact with the ServiceManager rather
than the other way around?
YEs and no. The ServiceManage can be described as a "view" inside the
Container that a component has of other components. As such, it
interacts with the container on behalf of the requesting component
(AKA client). Also the ServiceManager can be considered an extension
of the container.
THere is a bi-directional dependency there.
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.
They need to get the thing started. I wanted to set it up so that
the user didn't even need to do that much, but I ran out of time
a while back. I am just starting to get back on track. THe idea
was to have a "bootstrapper". One bootstrapper would work in CLI
environments, another for Servlet based environments, etc.
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?
Developers who use ECM are aware of the RoleManager because the
design concept carried forward from ECM. The users know that if
they place entries in this file named xxx.roles then they can use
simple names in the configuration file. But you are right, we need
to document these things.
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?
It looks similar. I think this exercise will help us understand
the differences in approaches, and standardise on some common
terminology.
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?
:/
I can see that there is some stuff to write up.... Diagrams will
be key to understanding it, but ASCII sequence diagrams are not
going to be very helpful to explain it.
It is late here 12:30am EST, so let me stew on it a bit so I can
describe the concepts I was thinking of with Fortress. The concepts
that Fortress was built with have not been changed. Keep in mind
that I am also trying to enable a system with hierarchical containers.
Again, let me set up some docs and everything and post it in another
email.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
