> From: news [mailto:[EMAIL PROTECTED]]On Behalf Of Leo Simons > > re-sending myself because you guys are confusing me... > > Leo Simons wrote: > > Hey peeps, > > > > some thoughts/questions/suggestions.... > > > > package refactoring > > ------------------- > > if we want to do some renaming and refactoring, now is the > time. I like > > doing the interface<->impl seperation stronly (re: the way > paul set up > > AltRMI), I think it'd be real beneficial for fortress. > > > > For example: > > > > change single line here: > > org.apache.avalon.fortress.interfaces > to: > 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? > > 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. 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) > > 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. > > 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. > > 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. 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. > > 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. Ok. (WRT? what is that?) -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
