On 4/3/02 1:33 PM, "Andrew C. Oliver" <[EMAIL PROTECTED]> wrote:
> I find myself in agreement. Secondly, I conceptualize interface > implementation as a form of inheritance (interface inheritance). It's not. In this case, it's a contract. > Therefore, you must ask: Is this an appropriate situation for > inheritance or containment. Most object technology "experts" profess > you should favor containment versus inheritance. This is a sign of good > encapsulation. > > Avalon's logging solution might be appropriate for one conceptualization > of logging which is "component level" logging. Did you read the thread? That's what I'm talking about. (and in commons, thatıs what it should be right?) > In truth logging is used > to refer to multiple types of logging (tracing, error reporting, etc), > and most of the differentiation of this is the message importance or > type. Its where or when you want the message to be viewable and in some > cases created. > > As for configuration, is the logging a service or a class assignable > property? Generally I think its a service used by your application or > API. Avalon's logic is that your "component" need to be "configured" > with this "aspect". I see the logic but I'm not sure I agree with it. > > Security is a consideration with calling a static wrapper (the general > approach to logging that most folks use) but I would question the > supposition that security cannot be a service called by or implemented > by the logging service/static wrapper in such a situation where its > required. Sorry? There is no security issue here whatesoever as this is IOC - the container/app/framework/woogie calls the setCommonsLog() if it *wants* to - the component can do nothing to 'grab' it. The contract is that the component has to be defensive - it can't assume it has a logger, and that if it doesn't get a logger, it has to deal... > > Lastly, its just a pain in the butt to do it the way Avalon does it. I > think its the case of working around a mismatch between Java and the > "Aspect Oriented Programming" that they seem to be going after. This changes *nothing* at all *anywhere* but simply adds to the logger package a new interface, implemented by components, that means "I can use a configured Commons logger if you want me to". > There are many things about Avalon that are increadibly likeable and > there are situations where I would use this kind of logging. Just, I > don't see it as a "hammer" and am not sure that the same thing can't be > accomplished through containment. > > And that's all I have to say about that. I suspect that you don't quite grasp what I am asking for... I'll be happy to explain if I haven't been clear... > -Andy > > Jon Scott Stevens wrote: > >> on 4/3/02 10:09 AM, "Jon Scott Stevens" <[EMAIL PROTECTED]> wrote: >> >>> Now, if the parent instantiates MyComponent and forgets to call >>> enableLogging() *before* myMethod() is called, an NPE will be thrown and it >>> will not be clear as to why that NPE was thrown unless you go and look at >>> the source code. There is no open coding contract that says that >>> enableLogging() needs to be called first. >>> >> >> I should also add that I don't like the fact that a parent is required. >> >> If a parent is required, then it requires a framework to support the >> children (ie: that is what a parent really is). >> >> Sure, sometimes frameworks are appropriate, but I don't think they are >> necessary for Velocity tools which are just objects stuck in the context... >> >> -jon >> >> >> -- >> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> >> >> > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- 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]>
