On 4/3/02 2:29 PM, "Berin Loritsch" <[EMAIL PROTECTED]> wrote:
>> -----Original Message----- >> From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] >> >> I want to try to explain this one more time because I think >> my earlier explanation wasn't good : >> >> 1) I am interested in adding an interface to the o.a.c.l >> package which looks like (modulo some naming concerns...) : >> >> public interface LogUser >> { >> void setCommonsLogger(Log log); >> } > > Ok. Similar to Avalon's LogEnabled class with the enableLogging() > method. I can't say I saw Avalon's to do this, but this is clearly inspired by the same pattern. > > >> 2) This interface is not required to be implemented by >> anyone, nor is it required to be looked for by anyone. > > In that case there is limited use for it. See below. > > >> 3) Repeat - there are no requirements as to the use of this interface. > > I repeat, see below. > >> 4) The purpose is to let tools and components that want to >> log have a 'marker' interface that they can implement that >> says to the world, whatever world they are living in, >> independent of race, creed, framework, container or application : >> >> "I want to log if I can. I know what a o.a.c.l.Log interface is and >> can use it. At any time, you can give one to me if you want to >> and know how. Otherwise, I'm ok." > > We are mixing metaphors, and I don't like it. The interface breeds > confusion. You can't mix IoC based apps and static accessor based > apps. There are reasons why. > > First off, you have to choose where you are using the component. If it > is in an application like JMeter where everything is accessed > statically, > all your components should behave the same. If you are basing your > application on something like Avalon where IoC rules, you should not > have > *any* static accessors of any sort. > > IoC is a tool used for Container/Component infrastructures, and is not > appropriate in all situations. Ok - with you so far. > > Components (in the formal sense) will always be tied to their container. > 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. I wasn't working in the formal sense, because the hope was to write bean-like classes that can be used in more than one framework/app/etc. > > 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. Avalon has docs? ;-> > > 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 > and disadvantages, but you should decide which model your component > operates in from the outset. Yep - I didn't realize that the o.a.c.l forced the static accessor model for getting the Logger. If that is the case, then I think it's true I have no choice but to go back and reinvent wheel and fire in Velocity-tools-land because while I am willing to use the Commons logging interface to normalize things, I am not willing, right now, to force people to use the commons logging framework. -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Age and treachery will always triumph over youth and talent -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
