Hello all,
On Dec 17, 2007 6:25 AM, Trustin Lee <[EMAIL PROTECTED]> wrote:
> Hi Maarten,
>
> On Dec 15, 2007 3:26 AM, Maarten Bosteels <[EMAIL PROTECTED]> wrote:
> > about (4) : I thought the deadlock is caused by a bug in log4j (namely that
> > it doesn't use proper synchronization) ?
> > If that's the case I think we should not try to fix it in MINA.
>
> I think it's not really a bug of Log4J but a missing feature (i.e.
> reentrant logging). There are two workaround for the dead lock; one
> is to turn OFF logging for MINA, and the other is use a differnt
> appender (i.e. non-MINA-based one). The second solution might be most
> viable solution that causes no change in our source code. However,
> some built-in filters that logs messages might be used for the
> MINA-based appender, and the log messages logged by the filter might
> need to be transmitted via the MINA-based appender because it's not a
> critical but just informing message. So... the two workarounds I've
> mentioned are not likely to solve this problem perfectly.
>
> We can ask Log4J team to fix this issue and it will be fixed, but,
> again, considering that people wants to use the older version of Log4J
> or doesn't want to upgrade the Log4J due to some reason (e.g. custom
> patch) won't see this problem resolved in Log4J.
> And.. that's why I am suggesting a thin layer for logging.
Suppose that the log4j team fixes this issue in their next release,
then the only people who would need this thin layer
are people who
a) want to use a MINA based appender (which is not yet part of
standard log4j as far as I know)
b) AND don't want to upgrade to a newer log4j version
IMO, that is a rather weak argument for resorting to our own "thin
layer for logging".
> By doing so, a user can bypass the existing logging framework to log messages
> from MINA itself. Of course, this doesn't necessarily mean that we
> will not experience dead lock or infinite recursion. However, at
> least we have control over such a tricky situation, and cut down
> unnecessary recursion.
>
> Another merit of the thin logging layer could be that it makes a JUL
> user doesn't need to add SLF4J JARs unnecessary. I sometime don't
> understand why the number of JARs are important. However, as David
> pointed out, it's pretty critical to the frameworks that depends on
> the other frameworks. For example, in the early stage of JMX
> integration implementation, I have used Commons BeanUtils which
> depends on commons logging. This meant a MiNA user who wants to use
> JMX integration module needs to add another JAR to his or her
> classpath.
I agree, there are currently two logging facades that are widely used
by frameworks/libraries: jakarta-commons-logging (JCL) and SLF4J.
The consequence is that for any project with dependencies, there is a
reasonable chance that both logging facades need to be on the
classpath. But is that a problem ?
Our application depends on JCL (because of spring,) and on SLF4J
(because of MINA) and we let both facades point to log4j.
Works pefectly. Really, I do not see the problem.
Of course, I would prefer it if we would only need SLF4J, but that's a
problem that MINA can not solve.
I am afraid that a thin layer in MINA will just make things more complex.
Could you explain a bit how that thin layer would work ?
Maarten
logger.info("I am NOT obsessed with logging");
> If he or she is using a Maven, then it also means that he
> or she has to add many <exclusion> tags to <dependency> section, which
> is pain in the butt.
>
> These thoughts lead me to think all frameworks have to:
>
> 1) provide a thin logging layer or
> 2) not log at all.
>
> I'd prefer the solution #1.
>
> David answered other questions pretty nicely, so that's all for me.
>
>
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP Key ID: 0x0255ECA6
>
