I find myself in agreement. Secondly, I conceptualize interface implementation as a form of inheritance (interface inheritance). 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. 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. 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. 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. -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]>
