> From: Mauro Talevi [mailto:[EMAIL PROTECTED]]
>
> Berin,
>
> Berin Loritsch wrote:
>
> >The framework part, weighing in at a mere 80k uncompressed isn't
> >very heavy. In fact it is fairly minimalistic.
> >
> >I agree with the problem of *perception*
> >
> you would also need excalibur-logger to get the logger repository
> functionality via the LoggerManager.
> actually, what are the reasons to keep framework.logger and
> excalibur.logger separate (at least the LoggerManager
> and the its implementations)?
> Could they be united in Avalon5?
You dont necessarily need that part. It was created primarily
to make configuring LogKit easier. ECM, Fortress, and (I believe)
Phoenix use Excalibur Logging--but Merlin does not. It isn't
necessary, but it is useful.
> >>>Keep in mind that COP (i.e. Avalon environment) has a different
> >>>set of constraints than traditional OOP. Basically, COP forces
> >>>you to operate within a certain subset of OOP which simplifies
> >>>a number of design decisions you have to make. It also lends
> >>>the benefit of VLC (Very Low Coupling) between implementations
> >>>of components.
> >
> >In a future version of Avalon, it is something to look at.
> >The risks of a rogue component successfully cracking a container's
> >security through logging is minimal.
> >
> what if a static access method was added to LoggerManager
> implementations to get a singleton instance?
I really don't like that notion at all. Not all containers
in a heirarchy of containers should share the same LoggerManager.
I have found that the Singleton pattern is *far* too overused,
and when it is used inappropriately it causes more problems than
solutions.
> Say, if one wanted to use Log4J via the Avalon Logger framework -
> without any autodiscovery - would would simply write
> import org.apache.avalon.framework.logger.Logger;
> import org.apache.avalon.excalibur.logger.Log4JLoggerManager;
> public class MyClass {
>
> private static Logger logger =
> Log4JLoggerManager.getInstance().getDefaultLogger();
>
> }
If you wanted your component to get a logger, all you have to
do is implement the LogEnabled interface. It's not hard at all.
You are also defeating the logger neutral stance that components
MUST have. You can develop a component with a container using
the Log4JLoggerManager, but you cannot guarantee that it will never
be run on a container using the LogKitLoggerManager.
Singletons only serve to cause problems in this manner--a component
must be logging kit neutral because the container controls which
logging toolkit is used and which isn't.
> Effectively, that would allow OOP-style development with Avalon and
> "prepare the ground" for COP if and when they decided to?
> One might introduce some mechanism to disable the singleton
> access when
> the component was deployed in a container.
It's really more work than its worth. With proper IoC, you can
get the same effect as COP, while still using OOP. You can't
do it in a way that won't cause issues with the software later.
It is very difficult to get poorly written OOP to become a decoupled
component.
> BTW, I've noticed that the framework.logger.Log4JLogger still
> used log4j
> 1.1.x.
> Since 1.2.x has deprecated Category and Priority and these
> are going to
> disappear in the next few months
> I've updated the Log4JLogger to use the non deprecated
> classes/methods.
Yes, we really need to do that.
> Being a wrapper class it should have any effect elsewhere nor
> should it
> matter for backward compatibility.
> Also I've noticed that other parts of Avalon (eg. Excalibur)
> use log4j
> 1.2 so it would better to be consistency.
> A patch is attached. And lib has to updated accordingly to use any
> log4j-1.2.x.jar
Thanks.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
