avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject [a4:fortress] refactoring, contracts, exceptions
Date Wed, 15 Jan 2003 19:08:38 GMT
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:

org.apache.avalon.fortress.interfaces
		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:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message