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:
to:org.apache.avalon.fortress.interfaces
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?
cheers,
- Leo
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.
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 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().
Container c = (Container)myContainerManager.getContainer();
// several times:
ContainerUtil.handlelifecyclemethod(c, myappdata);
c.addComponent(metadata);
c.addComponent(metadata2);
c.addComponent(metadata3);
c.addComponent(metadata4);
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?
ContainerManager <-> Container?
-------------------------------
What's the exact relationship between these two? What are their respective roles?
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.
just thinking out loud....
cheers,
- Leo
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
