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 Fri, 17 Jan 2003 19:36:28 GMT
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?

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


Mime
View raw message