Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 20684 invoked from network); 21 Nov 2001 09:21:56 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 21 Nov 2001 09:21:56 -0000 Received: (qmail 12316 invoked by uid 97); 21 Nov 2001 09:22:07 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 12300 invoked by uid 97); 21 Nov 2001 09:22:06 -0000 Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Developers List" Reply-To: "Avalon Developers List" Delivered-To: mailing list avalon-dev@jakarta.apache.org Received: (qmail 12289 invoked from network); 21 Nov 2001 09:22:06 -0000 Message-Id: <200111210922.fAL9M3D28305@mail004.syd.optusnet.com.au> Content-Type: text/plain; charset="utf-8" From: Peter Donald To: "Richard Sitze" Subject: Re: Common Logging Interface Date: Wed, 21 Nov 2001 20:19:08 +1100 X-Mailer: KMail [version 1.3.1] Cc: Avalon Development References: In-Reply-To: X-Wisdom-Cookie: . MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Hi, 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 thumb. 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 Avalon/Framework. -- Cheers, Pete ----------------------------------------------- "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." -Albert Einstein ----------------------------------------------- -- To unsubscribe, e-mail: For additional commands, e-mail: