BTW I think we need something different from JarJar (http://code.google.com/p/jarjar/). We need a simple skeleton code from which a thin logging layer code is generated into the specified package (org.apache.mina.common in MINA's case). It could be reused among many frameworks including MINA.
Trustin On Dec 17, 2007 2:25 PM, 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. 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. 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 > -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
