commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject RE: [logging] Need interface...
Date Wed, 03 Apr 2002 20:01:34 GMT
> -----Original Message-----
> From: costinm@covalent.net [mailto:costinm@covalent.net] 
> 
> On Wed, 3 Apr 2002, Berin Loritsch wrote:
> 
> > Components (in the formal sense) will always be tied to their 
> > container.
> 
> I don't know what is the 'formal sense' you are talking about, 
> but one of the goals of commons is to create components that 
> are _not_ 
> tied to a container.

Again, Commons doesn't have 'formal' components.  Formal components
include CORBA, EJB, Avalon, Servlets, etc.


> > The container provides everything to the component.  
> everything.  That 
> > means not just the logger.  That means that the component 
> is tied to 
> > the framework anyway.
> 
> And people have a choice to not use this kind of container - the 
> components we write will work in most containers, if a container have 
> a problem with pull model ( Log.getLog() ) - too bad for it.

Then it's not a component.


> > Commons, Sun, and several other people use the term component in an 
> > informal sense.  A component has a *role* (or work 
> interface) separate 
> > from the implementation.  It is tied to a container, which 
> manages it.  
> > Commons has a modular API, and each API group has been given the 
> > informal name of component, which confuses people who see commons' 
> > docs and avalon's docs.
> 
> I certainly hope avalon doesn't have a trademark on 
> 'component' or claims ownership or 'the Right Definition' of the term.

Who do you think I am?  Of course not.

Now I have to dig up my definitions on the net..... :/

> 
> > Lastly, trying to mix IoC and static access based systems is like 
> > trying to mix procedural and object oriented programming.  
> It can be 
> > done, but it is messy, confusing, and not maintainable.  Each model 
> > has its  advantages
> 
> I don't know about IoC, but push and pull models are mixed in most 
> programs and that's a good and desirable thing.
> 
> If IoC doesn't 'mix', then it shouldn't be used.


IoC is used for container managed systems.  If you have a hierarchical
container system, the parent container controls the direct child
containers
which in turn control their children.

The reason it *shouldn't* mix is because of security reasons.  If a sub-
container's security were breached, the damage that can be done is
limited
to that smaller container.  There are more reasons, but that is the most
important.  Therefore it is usually relagated to server systems.

It forces you to think differently, and is a useful tool in that
respect.


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message