avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: Common Logging Interface
Date Wed, 21 Nov 2001 09:19:08 GMT

Heres my take on it all. In no way shape or form will Avalon/Framework 
provide something that encourages violation of IOC. Not going to happen. That 
doesn't mean that we aren't willing to implement and support other different 
strategies for using parts of Framework... as long as they still are designed 
with IOC in mind.

Just a few points. Websphere - at least to an outside like myself - looks to 
be very much designed with IOC in mind. It does not offer as fine grained SOC 
as Avalon but it does offer IOC - just via a different method.

The best way to think of IOC is by thinking of the following general rule of 

Lets say we have a host environment/container H, a component C and a resource 
R. C needs R to operate. If the way in which C aquires R is interceptable by 
H in an easy and reliable mechanism then it is probably following IOC to some 
degree or another. (And bytecode processing tricks, classloader hacks, thread 
local hacks and so forth are not what I consider simple or reliable).

In this particular case our R is the Logger. So if the container (ie 
websphere) can intercept creation of Logger and customize the Logger returned 
(or replace it) then I think the Avalon group would be happy ;)

I don't think it would annoy the developers if the name of the logger was the 
name of the class using it. The important part is interceptability by the 
container. Thus static access ala LogKit.getLoggerFor(), 
Category.getCategory() or whatever is pretty much out of the question.

Berin was correct in that the proposal I made was designed around a similar 
pattern to JNDI. It was a direct rip ;) JNDI is the way in which many apps 
achieve a different style of IOC. In JNDI the container is responsible for 
placing objects in the JNDI context. The container is responsible for 
extracting the resources from JNDI.

The JNDI way differs from Avalon/Framework in that the component is still 
"active" (ie it retrieves objects from context) where in Avalon they are 
completely passive (ie pushed from container). I would not have a problem 
adding an javax.naming.spi.ObjectFactory instance that created different 
loggers or whatever if thats acceptable to you. 

However we can't really accept static access in any shape or form in 



"Only two things are infinite, the universe and 
human stupidity, and I'm not sure about the 
former." -Albert Einstein 

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

View raw message