You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "David M. Lloyd" <da...@redhat.com> on 2007/12/11 20:05:55 UTC
Revisiting logging in MINA 2.0
Hello fellow MINA users. I come before you today to hopefully change
your collective minds on an issue that is causing me trouble, and is
preventing two other big projects that I know of from adopting MINA for
I/O.
The issue is, of course, logging. The problem is simple: anyone who
wants to use MINA must also have slf4j in their classpath to support
logging. This is not optional.
The reason that this becomes a difficulty is that MINA is a framework
that is very attractive not only to your average end-developer, but
also to other framework authors. As a framework author myself, I plan
to use MINA for high-throughput network I/O - it's well-written, clean,
and proven to be quite efficient. However, my framework, MINA, and
another dependency of my project each use a different logging API,
resulting in the need for the user to have two different logging JARs
in the classpath in order to use my framework.
It is my firm believe that ALL framework libraries that require logging
should use JDK logging. The reason is simple: the user does not then
have any external JAR requirement for logging, unless they CHOOSE to
use a different framework.
You may be thinking that by using JDK logging, you are somehow taking
away the user's choice of logging frameworks. But this is not an
accurate view of the situation. Even if the user doesn't want to use
or configure JDK logging, there is nothing preventing the container or
the user's log framework of choice from registering its own
LogManager. Indeed just about every major container out there does
this, and with good reason - many existing frameworks already use JDK
logging. And why wouldn't they? It's a logging API that does the job,
and it's been built in to every JDK since 1.4.0.
In fact, by using JDK logging you INCREASE the user's ability to choose
logging frameworks, by not requiring them to include a logging meta-jar
of any sort.
Even if you (MINA developers) will ONLY use slf4j, PLEASE make it
optional somehow. Give the user the choice of not using slf4j rather
than imposing it on them (and us, the developers who want to leverage
MINA for our own frameworks).
Please take some time to consider what I've said. If the slf4j
dependency is made optional or removed, I know for a fact that several
more projects will be using MINA for I/O that otherwise considered the
logging framework issue a show-stopper.
Thanks!
- DML
Re: Revisiting logging in MINA 2.0
Posted by Luc Willems <wi...@pandora.be>.
On Thursday 13 December 2007 18:26:38 Trustin Lee wrote:
> On Dec 14, 2007 2:05 AM, Luc Willems <wi...@pandora.be> wrote:
> > On Thursday 13 December 2007 03:50:14 Trustin Lee wrote:
> > > This issue is becoming a real headache even a bottle of tylenol can't
> > > fix, along with the reentrant logging issue: http://xrl.us/bctaa
> > >
> > > I think these two issues should be considered together to resolve the
> > > issues related with logging. Let me summarize current situation:
> > >
> > > 1) There are people (A) who don't want to use SLF4J but
> > > java.util.logging. 2) There are people (B) who like to use SLF4J and
> > > they say SLF4J supports java.util.logging along with log4j.
> > > 3) People A say java.util.logging can also do the same by employing a
> > > proper LogManager implementation.
> > > 4) There is a logger reentrance problem in MINA, which means it is
> > > difficult to write a MINA-based appender for the most logging
> > > frameworks that doesn't allow reentrance. This problem can be worked
> > > around by turning off logging in MINA, but this is not reasonable.
> >
> > to make the picture a bit "complexer" . there is also a dependancy
> > to apache commons-logging if you use the JMX classes.
> >
> > IoServiceBean depends on beanutils which uses commons-logging.
> > i don't know how "hard" this dependancy is to beanutils. if we could
> > remove this dependancy , it would reduce the dependancy list.
> >
> > It would be great that we had 1 logging framework to setup (which could
> > be used with JDK java.util.loggig or log4j)
>
> I thought I got rid of that dependency recently, no?
>
> Thanks for the feed back anyway,
> Trustin
the HttptestCase java that if created uses the JMX classes to monitor
the traffic. i use bean-utils 1.8.beta (latest release)
Re: Revisiting logging in MINA 2.0
Posted by Trustin Lee <tr...@gmail.com>.
On Dec 14, 2007 2:05 AM, Luc Willems <wi...@pandora.be> wrote:
> On Thursday 13 December 2007 03:50:14 Trustin Lee wrote:
> > This issue is becoming a real headache even a bottle of tylenol can't
> > fix, along with the reentrant logging issue: http://xrl.us/bctaa
> >
> > I think these two issues should be considered together to resolve the
> > issues related with logging. Let me summarize current situation:
> >
> > 1) There are people (A) who don't want to use SLF4J but java.util.logging.
> > 2) There are people (B) who like to use SLF4J and they say SLF4J
> > supports java.util.logging along with log4j.
> > 3) People A say java.util.logging can also do the same by employing a
> > proper LogManager implementation.
> > 4) There is a logger reentrance problem in MINA, which means it is
> > difficult to write a MINA-based appender for the most logging
> > frameworks that doesn't allow reentrance. This problem can be worked
> > around by turning off logging in MINA, but this is not reasonable.
>
> to make the picture a bit "complexer" . there is also a dependancy
> to apache commons-logging if you use the JMX classes.
>
> IoServiceBean depends on beanutils which uses commons-logging.
> i don't know how "hard" this dependancy is to beanutils. if we could remove
> this dependancy , it would reduce the dependancy list.
>
> It would be great that we had 1 logging framework to setup (which could be
> used with JDK java.util.loggig or log4j)
I thought I got rid of that dependency recently, no?
Thanks for the feed back anyway,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: Revisiting logging in MINA 2.0
Posted by Luc Willems <wi...@pandora.be>.
On Thursday 13 December 2007 03:50:14 Trustin Lee wrote:
> This issue is becoming a real headache even a bottle of tylenol can't
> fix, along with the reentrant logging issue: http://xrl.us/bctaa
>
> I think these two issues should be considered together to resolve the
> issues related with logging. Let me summarize current situation:
>
> 1) There are people (A) who don't want to use SLF4J but java.util.logging.
> 2) There are people (B) who like to use SLF4J and they say SLF4J
> supports java.util.logging along with log4j.
> 3) People A say java.util.logging can also do the same by employing a
> proper LogManager implementation.
> 4) There is a logger reentrance problem in MINA, which means it is
> difficult to write a MINA-based appender for the most logging
> frameworks that doesn't allow reentrance. This problem can be worked
> around by turning off logging in MINA, but this is not reasonable.
to make the picture a bit "complexer" . there is also a dependancy
to apache commons-logging if you use the JMX classes.
IoServiceBean depends on beanutils which uses commons-logging.
i don't know how "hard" this dependancy is to beanutils. if we could remove
this dependancy , it would reduce the dependancy list.
It would be great that we had 1 logging framework to setup (which could be
used with JDK java.util.loggig or log4j)
luc
luc
Re: Revisiting logging in MINA 2.0
Posted by "David M. Lloyd" <da...@redhat.com>.
On Mon, 17 Dec 2007 14:29:10 +0900
"Trustin Lee" <tr...@gmail.com> wrote:
> 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.
Yes, I agree - I've often wished that slf4j would have taken this route
instead. If such a thing existed, I'd definitely use it for my
projects.
- DML
Re: Revisiting logging in MINA 2.0
Posted by Trustin Lee <tr...@gmail.com>.
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 <tr...@gmail.com> wrote:
> Hi Maarten,
>
> On Dec 15, 2007 3:26 AM, Maarten Bosteels <mb...@gmail.com> 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
Re: Revisiting logging in MINA 2.0
Posted by Emmanuel Lecharny <el...@gmail.com>.
David M. Lloyd wrote:
> My point is, as a framework, MINA should work to avoid imposing this
> preference upon the consumer of the framework. That's just "friendly"
> programming practice: make as few assumptions as possible about the
> user's environment, and impose as few constraints as possible.
>
What about completly remove logs from MINA? Anyway, logs are for dummies
: real programmer not only don't eat quiches, but also don't need logs
because their code is bulletproof.
As Marteen perfectly said : live with it. I assure you that it worth the
try. I think almost all of the Apache projects are using more than one
framework and more than one logger, without any kind of problem for
their users (thanks to the committers who do their best to make this
work for users)
>> So, you would be better off trying to convince the teams of these
>> non-ASF projects to switch their logging framework ?
>>
>
> To SLF4J? I'm not as optimistic about my chances to get a non-ASF
> project to use an ASF logging framework, as I am that I can convince an
> ASF project to make their logging optional.
>
I think that the vast majority of the projects is using log4j right now,
then common-logging might be second, and at the end of the feed chain,
you have slf4j and JCL. I personnaly have worked on a couple of projects
those last 10 years, none of them were using JCL. And I find slf4j a
convenient way to solve a lot of class-loader issues. We are using it in
ADS, and we are quite pleased with it.
Bringing peace in the middle-east is probably easier than convincing
someone to switch from his favorite logger to another one...
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Revisiting logging in MINA 2.0
Posted by "David M. Lloyd" <da...@redhat.com>.
On Mon, 17 Dec 2007 20:11:20 +0100
"Maarten Bosteels" <mb...@gmail.com> wrote:
> Hi David,
>
> > Some people have feelings stronger than preference about it. Also keep
> > in mind: you've got an application. You are not developing a framework.
> >
> > How would you feel about things if MINA required slf4j AND jcl AND
> > log4j? That would seem excessive, would it not? It might even affect
> > one's willingness to use the framework.
>
> Suppose I am developing framework X that depends on projectA, projectB
> and projectC
> and suppose also that
> * projectA requires SLF4J
> * projectB requires JCL
> * projectC requires log4j
>
> Then I would take these steps to try to improve the situation:
> (1) try (hard) to convince the projectC team to switch to SLF4J
> (2) when (1) fails: search an alternative for projectC
> (3) try (probably less hard) to convince the projectB team to use
> SLF4J instead of JCL
> (4) if (3) fails, explain to the users of X why they need both jcl and
> SLF4J on their classpath
> (5) live with it.
My point is, as a framework, MINA should work to avoid imposing this
preference upon the consumer of the framework. That's just "friendly"
programming practice: make as few assumptions as possible about the
user's environment, and impose as few constraints as possible.
> So, you would be better off trying to convince the teams of these
> non-ASF projects to switch their logging framework ?
To SLF4J? I'm not as optimistic about my chances to get a non-ASF
project to use an ASF logging framework, as I am that I can convince an
ASF project to make their logging optional.
> > Therefore I am making an effort to convince the author(s) of these
> > frameworks upon which my project relies, to consider making logging
> > either configurable with no dependencies, or optional altogether.
> > Using JDK logging seems like a reasonable compromise.
>
> IMO, SLF4J makes logging configurable AND optional (using slf4j-nop.jar).
So you need two jars in order to... do nothing. Since logging is
already mostly centralized in MINA, why not just have a simple switch
of some sort? Even a static method that says "turn off logging" would
be better than the current situation. Though e.g. a setter on
IoAcceptor and IoConnector (for example) would be ideal (as this also
might address the reentrancy problem that Trustin brought up).
- DML
Re: Revisiting logging in MINA 2.0
Posted by Maarten Bosteels <mb...@gmail.com>.
Hi David,
On Dec 17, 2007 5:46 PM, David M. Lloyd <da...@redhat.com> wrote:
> On Mon, 17 Dec 2007 17:29:24 +0100 "Maarten Bosteels"
> <mb...@gmail.com> wrote:
>
> > 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.
>
> Some people have feelings stronger than preference about it. Also keep
> in mind: you've got an application. You are not developing a framework.
>
> How would you feel about things if MINA required slf4j AND jcl AND
> log4j? That would seem excessive, would it not? It might even affect
> one's willingness to use the framework.
Suppose I am developing framework X that depends on projectA, projectB
and projectC
and suppose also that
* projectA requires SLF4J
* projectB requires JCL
* projectC requires log4j
Then I would take these steps to try to improve the situation:
(1) try (hard) to convince the projectC team to switch to SLF4J
(2) when (1) fails: search an alternative for projectC
(3) try (probably less hard) to convince the projectB team to use
SLF4J instead of JCL
(4) if (3) fails, explain to the users of X why they need both jcl and
SLF4J on their classpath
(5) live with it.
> This is the situation that I (and others with whom I work) face
> currently. As a framework developer, I would not care if there was
> only one logging dependency - but the other libraries that my project
> depends on all use different logging frameworks. This especially
> becomes an issue if you consider the wider world of software (beyond
> ASF projects). Though most ASF projects use slf4j or jcl, this is not
> true in general terms.
So, you would be better off trying to convince the teams of these
non-ASF projects to switch their logging framework ?
>
> Therefore I am making an effort to convince the author(s) of these
> frameworks upon which my project relies, to consider making logging
> either configurable with no dependencies, or optional altogether.
> Using JDK logging seems like a reasonable compromise.
IMO, SLF4J makes logging configurable AND optional (using slf4j-nop.jar).
regards,
Maarten
Re: Revisiting logging in MINA 2.0
Posted by Raman Gupta <ro...@fastmail.fm>.
David M. Lloyd wrote:
> How would you feel about things if MINA required slf4j AND jcl AND
> log4j? That would seem excessive, would it not? It might even affect
> one's willingness to use the framework.
>
> This is the situation that I (and others with whom I work) face
> currently. As a framework developer, I would not care if there was
> only one logging dependency - but the other libraries that my project
> depends on all use different logging frameworks. This especially
> becomes an issue if you consider the wider world of software (beyond
> ASF projects). Though most ASF projects use slf4j or jcl, this is not
> true in general terms.
>
> Therefore I am making an effort to convince the author(s) of these
> frameworks upon which my project relies, to consider making logging
> either configurable with no dependencies, or optional altogether.
> Using JDK logging seems like a reasonable compromise.
Many (most) of us don't want to introduce JDK logging into our
projects. We are very happy with logging to our framework of choice
via slf4j. I believe you've said before that JDK logging can easily be
redirected to slf4j (just like it is redirect jcl to slf4j). If that
really is the case, then I think it would make sense to switch Mina to
JDK logging, since everyone can then log from Mina to wherever they
want, without any complexity within Mina, or external dependencies.
However, I haven't seen any code anywhere to actually do this --
perhaps you'd like to reference something that does this, or explain
to the list how this could be done, or code it yourself if its not
currently available? That would go a long way to "convincing"
frameworks to switch to a logging system that few people actually use.
Keep in mind this "solution" should take into account esoteric
classloader situations (such as within application servers or OSGi
runtimes). If it can be done, I think it would actually be a very
useful and widely used component -- I know there are some other
libraries I use that use JDK logging that I would love to redirect to
log4j so I can manage all my logging from one place.
Cheers,
Raman Gupta
Re: Revisiting logging in MINA 2.0
Posted by peter royal <pr...@apache.org>.
On Dec 17, 2007, at 8:46 AM, David M. Lloyd wrote:
> Therefore I am making an effort to convince the author(s) of these
> frameworks upon which my project relies, to consider making logging
> either configurable with no dependencies, or optional altogether.
> Using JDK logging seems like a reasonable compromise.
David,
How about http://code.google.com/p/jarjar/ ?
You can build your own version of MINA that embeds SLF4J and the JDK14
SLF4J logger to give you a MINA jar that has no external dependencies.
Will that work for you?
-pete
--
proyal@apache.org - http://fotap.org/~osi
Re: Revisiting logging in MINA 2.0
Posted by "David M. Lloyd" <da...@redhat.com>.
On Mon, 17 Dec 2007 17:29:24 +0100 "Maarten Bosteels"
<mb...@gmail.com> wrote:
> 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.
Some people have feelings stronger than preference about it. Also keep
in mind: you've got an application. You are not developing a framework.
How would you feel about things if MINA required slf4j AND jcl AND
log4j? That would seem excessive, would it not? It might even affect
one's willingness to use the framework.
This is the situation that I (and others with whom I work) face
currently. As a framework developer, I would not care if there was
only one logging dependency - but the other libraries that my project
depends on all use different logging frameworks. This especially
becomes an issue if you consider the wider world of software (beyond
ASF projects). Though most ASF projects use slf4j or jcl, this is not
true in general terms.
Therefore I am making an effort to convince the author(s) of these
frameworks upon which my project relies, to consider making logging
either configurable with no dependencies, or optional altogether.
Using JDK logging seems like a reasonable compromise.
- DML
Re: Revisiting logging in MINA 2.0
Posted by Ceki Gulcu <ce...@qos.ch>.
Hi Alex,
In reference to the MINA-based appender re-entrance problem as described in
http://xrl.us/bctaa , I would suggest that logging from the I/O processor
thread be disabled.
As for JBoss, did you know that Hibernate 3.0, the next version of Hibernate,
relies on SLF4J for its logging?
Moreover, Spring-OSGI which presumably lays the foundations of the next
generation of Spring also relies on SLF4J?
I am not sure if this helps, but that's the best I can do in a few minutes. :-)
Alex Karasulu wrote:
> Sorry forgot to CC Ceki after mentioning it. Ceki could you take a
> minute to help us resolve these issues which are pushing towards the
> emergence of yet another logging framework now inside MINA. I think
> much of this is a result of the JBoss push to do away with SLF4J
> dependencies.
>
> Alex
>
> On Dec 17, 2007 1:40 PM, Alex Karasulu <akarasulu@apache.org
> <ma...@apache.org>> wrote:
>
> On Dec 17, 2007 11:29 AM, Maarten Bosteels <mbosteels.dns@gmail.com
> <ma...@gmail.com>> wrote:
>
>
> On Dec 17, 2007 6:25 AM, Trustin Lee <trustin@gmail.com
> <ma...@gmail.com>> wrote:
>
>
> ...
>
> > 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".
>
>
> Yes I agree completely. It's unnecessary to add yet another logging
> layer.
>
> I know several JBoss people are resentful with having to use SLF4J
> while now using MINA but there is no reason why we should push
> forward with that.
>
> Why not just work with Ceki or see if you can get karma on that
> project to fix these problems and/or facilitate the advance of a
> release with the fix? Ceki, I am sure would appreciate that. Plus
> the work you do there can benefit other projects using this
> framework. I have CC'd Ceki to get his attention so we can do
> something sane about this.
>
> ...
>
>
> 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.
>
>
> There are many people in this situation. Adding yet another
> framework whether mini or not is going to add to the confusion.
>
>
>
> 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.
>
>
> Absolutely!
>
> Alex
>
>
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
Re: Revisiting logging in MINA 2.0
Posted by Alex Karasulu <ak...@apache.org>.
Sorry forgot to CC Ceki after mentioning it. Ceki could you take a minute
to help us resolve these issues which are pushing towards the emergence of
yet another logging framework now inside MINA. I think much of this is a
result of the JBoss push to do away with SLF4J dependencies.
Alex
On Dec 17, 2007 1:40 PM, Alex Karasulu <ak...@apache.org> wrote:
> On Dec 17, 2007 11:29 AM, Maarten Bosteels <mb...@gmail.com>
> wrote:
>
> >
> > On Dec 17, 2007 6:25 AM, Trustin Lee <tr...@gmail.com> wrote:
> >
>
> ...
>
> > 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".
> >
>
> Yes I agree completely. It's unnecessary to add yet another logging
> layer.
>
> I know several JBoss people are resentful with having to use SLF4J while
> now using MINA but there is no reason why we should push forward with that.
>
> Why not just work with Ceki or see if you can get karma on that project to
> fix these problems and/or facilitate the advance of a release with the fix?
> Ceki, I am sure would appreciate that. Plus the work you do there can
> benefit other projects using this framework. I have CC'd Ceki to get his
> attention so we can do something sane about this.
>
> ...
>
>
> > 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.
> >
>
> There are many people in this situation. Adding yet another framework
> whether mini or not is going to add to the confusion.
>
>
> >
> > 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.
> >
>
> Absolutely!
>
> Alex
>
>
Re: Revisiting logging in MINA 2.0
Posted by Alex Karasulu <ak...@apache.org>.
Trustin,
If MINA uses it's own logging, and logs critical related messages on a
separate channel, then an application written with MINA yet using another
framework will channel log messages to potentially different targets.
Sometimes you just don't get the best of both worlds. There are trade
offs. This is clearly one of those. Here we just have to pick one logging
framework and stick to it. Several people have objected to this repeatedly
and you keep bringing it up in short intervals. Let's just give it a year
and come back to consider it again. Sometimes it's about timing right?
Alex
On Dec 17, 2007 11:13 PM, Trustin Lee <tr...@gmail.com> wrote:
> On Dec 18, 2007 3:40 AM, Alex Karasulu <ak...@apache.org> wrote:
> > On Dec 17, 2007 11:29 AM, Maarten Bosteels <mb...@gmail.com>
> wrote:
> > > On Dec 17, 2007 6:25 AM, Trustin Lee <tr...@gmail.com> wrote:
> > ...
> > > 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".
> >
> > Yes I agree completely. It's unnecessary to add yet another logging
> layer.
> >
> > I know several JBoss people are resentful with having to use SLF4J while
> now
> > using MINA but there is no reason why we should push forward with that.
>
> You understood plain wrong. It's not about JBoss people but about any
> possible users who want to build their own framework on top of MINA.
> Do you think I am pushing this because I am working for JBoss? Never.
> I got this kind of request more than 10 times in my previous company.
> What does that mean? There are much more people than you expect who
> care about the number of JARs and complication related with using many
> logging frameworks at the same time.
>
> > Why not just work with Ceki or see if you can get karma on that project
> to
> > fix these problems and/or facilitate the advance of a release with the
> fix?
> > Ceki, I am sure would appreciate that. Plus the work you do there can
> > benefit other projects using this framework. I have CC'd Ceki to get
> his
> > attention so we can do something sane about this.
>
> SLF4J cannot help this problem because SLF4J itself doesn't have any
> 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.
> >
> > There are many people in this situation. Adding yet another framework
> > whether mini or not is going to add to the confusion.
>
> It's also often true that people get confused with configuring SLF4J.
> Yeah, it's brain-dead easy once understood, but it adds a lot of
> confusion to novice. Anyways, we have the dedicated page for logging
> configuration so 'the confusion' you are referring to is not a problem
> at all. As you already know, it's just adding one line of code to
> switch the preferred logging framework from users' point of view and I
> don't think that's really a big burden comparing to adding two JARs in
> the classpath.
>
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP Key ID: 0x0255ECA6
>
Re: Revisiting logging in MINA 2.0
Posted by Trustin Lee <tr...@gmail.com>.
On Dec 18, 2007 5:53 PM, Maarten Bosteels <mb...@gmail.com> wrote:
> On Dec 18, 2007 9:28 AM, Trustin Lee <tr...@gmail.com> wrote:
> > You made many good points but I need to correct some.
> >
> > On Dec 18, 2007 3:51 PM, Alex Karasulu <ak...@apache.org> wrote:
> >
> > <snip/>
> >
> > > (4) I won't go into detail to keep some things private but I know you wanted
> > > to find this thread [1] because it was one which you suspected was a veto
> > > against you. You explicitly searched for and found this thread after some
> > > recent events.
> >
> > I have never searched for that thread. What I searched for was a vote
> > about inviting someone into the PMC. Moreover, what's up with the
> > veto from the community? If the community doesn't like my idea, then
> > that's OK.
> >
> > People can veto my idea, but I also have my right to keep persuading
> > my idea as long as I think it's really right and it is the
> > responsibility of the community to pursuade me that my point is wrong
> > or it's just a matter of trade-off. Additionally, we didn't have
> > issues related with framework on top of framework (or library) and
> > logger reentrancy at that time, and that's why I think we need to
> > reconsider the previous decision.
> >
> > I don't feel offended by the decision of the community. What really
> > dismays me is this kind of personal offense. Saying 'I won't go into
> > detail to keep some things private' just makes me laugh; what would
> > people imagine about me? Is this intentional to spread out some
> > conspiracy theory?
> >
> > > However, regarding this thread coming back to life, it occurred right after
> > > you explicitly searched for it. You wanted to bring it up again, primarily
> > > because it was an outstanding issue that you felt was legitimate. Most
> > > importantly, it did not unfold in the manner you wanted it to be addressed.
> >
> > Again, I did never searched for it both implicitly and explicitly, and
> > please note we got two new issues related with the current logging in
> > MINA which were discovered very recently. You are saying that I will
> > do the best for MINA and I want to control this project at the same
> > time by saying 'Most importantly, it did not unfold in the manner you
> > wanted it to be addressed.' It sounds like I am driving this project
> > for my personal benefit and you are upsetting me seriously.
> >
> > > This is all fine, but I'm wondering why David kicked it off and joined in.
> > > I'm not suggesting we have a "follow the leader" situation but the
> > > possibility is starting to occur regularly in my head. This is happening
> > > because I fear having the merits of my points undermined by back channel
> > > coordination. Again I am not accusing you of it. I am stating it as a
> > > concern and something that my reasoning points to as a possibility.
> >
> > You don't need to worry about that at all. I found David and I have
> > similar idea about logging and he is also the author of a framework
> > that suffers with many logging framework JARs. He has his concern and
> > I have to resolve his concern as a committer of MINA project not as a
> > colleague of him. Of course, our employer provides a private IRC
> > channel, but please note that our communication about MINA almost
> > always occurred in #mina channel at freenode.net or this mailing list.
> >
> > > Thankfully, the majority, of individuals on thread [0], naturally opposed
> > > the emergence of yet another logging API. If they did not, then my voice or
> > > any other opposing voice, would be drowned out. As a well respected and
> > > empowered member of this community, you should try to prevent your over
> > > whelming stature from drowning out fainter voices of reason.
> >
> > It sounds like that I have ever tried to bury someone's voice. Did I
> > get something wrong?
> >
> > > Sometimes
> > > there is no absolute right or wrong decision and it's a trade off. So, when
> > > you possess so much influence, the responsible thing to do is to look out
> > > for those that have less influence but are trying to make a point for the
> > > benefit of the project.
> >
> > Who have less influence and who have more? Do I have more influence
> > over this issue? Or... is that you? I might have more influence in
> > overall decision, but this thread is not the case as you already know.
> >
> > And.. explain me why it is a matter of trade-off. To me, it's a
> > critical issue that hinders the adoption of MINA in many library
> > projects. Anyone can create his or her own protocol implementation
> > and provide it as a new library wrapped with more protocol-specific
> > API, and then now we are forcing them to use SLF4J just because we
> > believe it's good no matter how he or she thinks about SLF4J. I think
> > it's even against the spirit of the open source activity; it's rather
> > the violence over potential users.
> >
> > > The majority has expressed it's disinterest with this idea and sometimes you
> > > need to yield to the community over your own beliefs of what is the best
> > > route. Let the community find out for itself if it is wrong. Besides, they
> > > got your message. They already have the information for your approach
> > > imprinted twice now in the archives. If the rest of us is wrong we can
> > > revisit the topic. It's fair to say, the majority is still not interested
> > > in pursuing yet another logging API to be maintained by MINA. So can we
> > > drop this, please?
> >
> > To finish this discussion, Maarten or any other community members will
> > have to provide a better alternative to my idea. Why are you and they
> > ignoring those minorities who have *less influence* really by saying
> > 'just live with it'? There are people out there who just can't live
> > with it. Shoule we let people drop MINA from their dependency like I
> > did for Commons BeanUtils just because of logging? That is a real
> > nonsense.
>
> Trustin, maybe there are people wo just can't live with it.
> But that's a weak argument, I could easily turn it around and say "I
> can't live with a thin logging layer within MINA."
> Of course, I am not gonna say this, since I don't know anything about
> this thin layer.
> A few mails higher in this thread I asked how this thin layer would work.
> Perhaps it would be easier to convince people by just showing the code ?
Thanks for focusing on the main topic first of all. I fully
understood why my argument is weak now. You made a really great
point. I apologize for exercising some kind of potential violence on
you. ;)
Let me try to come up with the non-intrusive effort I've mentioned a
few minutes ago in the separate message first and then try the thin
layer approach to show if it is really thin. I think it's right now
to close this thread really. I'll zip my mouth from now one in this
thread.
Cheers,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: Revisiting logging in MINA 2.0
Posted by Maarten Bosteels <mb...@gmail.com>.
On Dec 18, 2007 9:28 AM, Trustin Lee <tr...@gmail.com> wrote:
> You made many good points but I need to correct some.
>
> On Dec 18, 2007 3:51 PM, Alex Karasulu <ak...@apache.org> wrote:
>
> <snip/>
>
> > (4) I won't go into detail to keep some things private but I know you wanted
> > to find this thread [1] because it was one which you suspected was a veto
> > against you. You explicitly searched for and found this thread after some
> > recent events.
>
> I have never searched for that thread. What I searched for was a vote
> about inviting someone into the PMC. Moreover, what's up with the
> veto from the community? If the community doesn't like my idea, then
> that's OK.
>
> People can veto my idea, but I also have my right to keep persuading
> my idea as long as I think it's really right and it is the
> responsibility of the community to pursuade me that my point is wrong
> or it's just a matter of trade-off. Additionally, we didn't have
> issues related with framework on top of framework (or library) and
> logger reentrancy at that time, and that's why I think we need to
> reconsider the previous decision.
>
> I don't feel offended by the decision of the community. What really
> dismays me is this kind of personal offense. Saying 'I won't go into
> detail to keep some things private' just makes me laugh; what would
> people imagine about me? Is this intentional to spread out some
> conspiracy theory?
>
> > However, regarding this thread coming back to life, it occurred right after
> > you explicitly searched for it. You wanted to bring it up again, primarily
> > because it was an outstanding issue that you felt was legitimate. Most
> > importantly, it did not unfold in the manner you wanted it to be addressed.
>
> Again, I did never searched for it both implicitly and explicitly, and
> please note we got two new issues related with the current logging in
> MINA which were discovered very recently. You are saying that I will
> do the best for MINA and I want to control this project at the same
> time by saying 'Most importantly, it did not unfold in the manner you
> wanted it to be addressed.' It sounds like I am driving this project
> for my personal benefit and you are upsetting me seriously.
>
> > This is all fine, but I'm wondering why David kicked it off and joined in.
> > I'm not suggesting we have a "follow the leader" situation but the
> > possibility is starting to occur regularly in my head. This is happening
> > because I fear having the merits of my points undermined by back channel
> > coordination. Again I am not accusing you of it. I am stating it as a
> > concern and something that my reasoning points to as a possibility.
>
> You don't need to worry about that at all. I found David and I have
> similar idea about logging and he is also the author of a framework
> that suffers with many logging framework JARs. He has his concern and
> I have to resolve his concern as a committer of MINA project not as a
> colleague of him. Of course, our employer provides a private IRC
> channel, but please note that our communication about MINA almost
> always occurred in #mina channel at freenode.net or this mailing list.
>
> > Thankfully, the majority, of individuals on thread [0], naturally opposed
> > the emergence of yet another logging API. If they did not, then my voice or
> > any other opposing voice, would be drowned out. As a well respected and
> > empowered member of this community, you should try to prevent your over
> > whelming stature from drowning out fainter voices of reason.
>
> It sounds like that I have ever tried to bury someone's voice. Did I
> get something wrong?
>
> > Sometimes
> > there is no absolute right or wrong decision and it's a trade off. So, when
> > you possess so much influence, the responsible thing to do is to look out
> > for those that have less influence but are trying to make a point for the
> > benefit of the project.
>
> Who have less influence and who have more? Do I have more influence
> over this issue? Or... is that you? I might have more influence in
> overall decision, but this thread is not the case as you already know.
>
> And.. explain me why it is a matter of trade-off. To me, it's a
> critical issue that hinders the adoption of MINA in many library
> projects. Anyone can create his or her own protocol implementation
> and provide it as a new library wrapped with more protocol-specific
> API, and then now we are forcing them to use SLF4J just because we
> believe it's good no matter how he or she thinks about SLF4J. I think
> it's even against the spirit of the open source activity; it's rather
> the violence over potential users.
>
> > The majority has expressed it's disinterest with this idea and sometimes you
> > need to yield to the community over your own beliefs of what is the best
> > route. Let the community find out for itself if it is wrong. Besides, they
> > got your message. They already have the information for your approach
> > imprinted twice now in the archives. If the rest of us is wrong we can
> > revisit the topic. It's fair to say, the majority is still not interested
> > in pursuing yet another logging API to be maintained by MINA. So can we
> > drop this, please?
>
> To finish this discussion, Maarten or any other community members will
> have to provide a better alternative to my idea. Why are you and they
> ignoring those minorities who have *less influence* really by saying
> 'just live with it'? There are people out there who just can't live
> with it. Shoule we let people drop MINA from their dependency like I
> did for Commons BeanUtils just because of logging? That is a real
> nonsense.
Trustin, maybe there are people wo just can't live with it.
But that's a weak argument, I could easily turn it around and say "I
can't live with a thin logging layer within MINA."
Of course, I am not gonna say this, since I don't know anything about
this thin layer.
A few mails higher in this thread I asked how this thin layer would work.
Perhaps it would be easier to convince people by just showing the code ?
Maarten
>
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP Key ID: 0x0255ECA6
>
Re: Revisiting logging in MINA 2.0
Posted by Alex Karasulu <ak...@apache.org>.
On Dec 18, 2007 3:28 AM, Trustin Lee <tr...@gmail.com> wrote:
> You made many good points but I need to correct some.
>
> On Dec 18, 2007 3:51 PM, Alex Karasulu <ak...@apache.org> wrote:
>
> <snip/>
>
> > (4) I won't go into detail to keep some things private but I know you
> wanted
> > to find this thread [1] because it was one which you suspected was a
> veto
> > against you. You explicitly searched for and found this thread after
> some
> > recent events.
>
> I have never searched for that thread. What I searched for was a vote
> about inviting someone into the PMC. Moreover, what's up with the
> veto from the community? If the community doesn't like my idea, then
> that's OK.
>
> People can veto my idea, but I also have my right to keep persuading
> my idea as long as I think it's really right and it is the
> responsibility of the community to pursuade me that my point is wrong
> or it's just a matter of trade-off. Additionally, we didn't have
> issues related with framework on top of framework (or library) and
> logger reentrancy at that time, and that's why I think we need to
> reconsider the previous decision.
>
> I don't feel offended by the decision of the community. What really
> dismays me is this kind of personal offense. Saying 'I won't go into
> detail to keep some things private' just makes me laugh; what would
> people imagine about me? Is this intentional to spread out some
> conspiracy theory?
>
Again you're misunderstanding. You and I privately discussed a couple
things surrounding point (4) in a discussion. I just considered some of the
thing you said to me as private. I did not want to reiterate them here
without asking you first.
This is why I made that comment, "I won't go into detail to keep some things
private". I'm trying to respect your privacy. You're presuming incorrectly
again.
>
> > However, regarding this thread coming back to life, it occurred right
> after
> > you explicitly searched for it. You wanted to bring it up again,
> primarily
> > because it was an outstanding issue that you felt was legitimate. Most
> > importantly, it did not unfold in the manner you wanted it to be
> addressed.
>
> Again, I did never searched for it both implicitly and explicitly, and
> please note we got two new issues related with the current logging in
> MINA which were discovered very recently. You are saying that I will
> do the best for MINA and I want to control this project at the same
> time by saying 'Most importantly, it did not unfold in the manner you
> wanted it to be addressed.' It sounds like I am driving this project
> for my personal benefit and you are upsetting me seriously.
>
There is nothing negative about this 'it did not unfold in the manner you
wanted it to be addressed' statement.
This is a simple fact. It's a point you made before and the outcome was not
the way you wanted. There are several outcomes I wanted that never occurred
either in various communities here. The community just disagreed months
ago.
This is just a statement. If you feel threatened by that then you need to
grow a thinker skin.
> > This is all fine, but I'm wondering why David kicked it off and joined
> in.
> > I'm not suggesting we have a "follow the leader" situation but the
> > possibility is starting to occur regularly in my head. This is
> happening
> > because I fear having the merits of my points undermined by back channel
> > coordination. Again I am not accusing you of it. I am stating it as a
> > concern and something that my reasoning points to as a possibility.
>
> You don't need to worry about that at all. I found David and I have
> similar idea about logging and he is also the author of a framework
> that suffers with many logging framework JARs. He has his concern and
> I have to resolve his concern as a committer of MINA project not as a
> colleague of him. Of course, our employer provides a private IRC
> channel, but please note that our communication about MINA almost
> always occurred in #mina channel at freenode.net or this mailing list.
>
> > Thankfully, the majority, of individuals on thread [0], naturally
> opposed
> > the emergence of yet another logging API. If they did not, then my
> voice or
> > any other opposing voice, would be drowned out. As a well respected and
> > empowered member of this community, you should try to prevent your over
> > whelming stature from drowning out fainter voices of reason.
>
> It sounds like that I have ever tried to bury someone's voice. Did I
> get something wrong?
>
No but I think you can do it unknowingly. You wield a lot of public opinion
here which is dangerous. Sometimes, myself included, people tend to just go
along with what you say or what you vote on without complete analysis.
>
> > Sometimes
> > there is no absolute right or wrong decision and it's a trade off. So,
> when
> > you possess so much influence, the responsible thing to do is to look
> out
> > for those that have less influence but are trying to make a point for
> the
> > benefit of the project.
>
> Who have less influence and who have more? Do I have more influence
> over this issue? Or... is that you? I might have more influence in
> overall decision, but this thread is not the case as you already know.
>
I don't have much influence since I'm one voice in many who thinks pursuing
this logging thing is too much.
> I think
> it's even against the spirit of the open source activity; it's rather
> the violence over potential users.
"violence against users" - you probably meant something else. I'll just
ignore this ridiculously sounding phase as a mistaken choice of words.
>
>
> > The majority has expressed it's disinterest with this idea and sometimes
> you
> > need to yield to the community over your own beliefs of what is the best
> > route. Let the community find out for itself if it is wrong. Besides,
> they
> > got your message. They already have the information for your approach
> > imprinted twice now in the archives. If the rest of us is wrong we can
> > revisit the topic. It's fair to say, the majority is still not
> interested
> > in pursuing yet another logging API to be maintained by MINA. So can we
> > drop this, please?
>
> To finish this discussion, Maarten or any other community members will
> have to provide a better alternative to my idea.
No this is where you are mistaken. You're not in a position to just say
Maarten's position is not good enough. The majority is there with Maarten.
So this is over until we get more data. When we disagree like this it's
better to shelve the discussion for a later date when we have more data then
to keep forcing it and hurting relationships which are more important.
> Why are you and they
> ignoring those minorities who have *less influence* really by saying
> 'just live with it'?
Look I am one of those minorities too on projects other than Directory. I
use MINA with other applications that are based on commons logging. It's
just not enough of a big deal having an extra dependency.
It's much more of a PITA with the approach you and David are suggesting.
> There are people out there who just can't live
> with it.
I live with it. I bet others here who opposed this idea do also in
different areas. We have many occasions where projects use other logging
frameworks.
> Shoule we let people drop MINA from their dependency like I
> did for Commons BeanUtils just because of logging?
No but you cannot do everything for everybody.
> That is a real
> nonsense.
>
It's not nonsense when people disagree. Don't pull a tantrum. As a member
of the PMC I'm going to ask you to just cut this out and discuss this topic
again after 12 months or so. If you need a veto which you seem to be
searching for you'll get it. Binding -1. So let's move on.
I have no idea what is happening to you. I have known you for a long time.
You're acting way out of character recently and I don't want to analyze why
that is much less publicly.
Alex
Re: Revisiting logging in MINA 2.0
Posted by Alex Karasulu <ak...@apache.org>.
On Dec 18, 2007 4:58 AM, Maarten Bosteels <mb...@gmail.com> wrote:
> On Dec 18, 2007 10:47 AM, Julien Vermillard <jv...@archean.fr>
> wrote:
> > On Tue, 18 Dec 2007 10:32:41 +0100
> > Emmanuel Lecharny <el...@gmail.com> wrote:
> >
> Question remains if the MINA team should try to solve this, since we
> all agree that there is no problem with SLF4J ?
> I hope we're not sending out the wrong message about SLF4J by creating
> such a tool ?
>
Interesting point.
>
> I think a lot of people (including me) would really like to see a
> massive adoption of SLF4J by other projects (instead of JCL)
> so that the entire java community can stop wasting time discussing
> logging frameworks :-p
Amen!
>
> Of course, it's not MINA's task to promote SLF4J but at least we
> should give it the credit it deserves.
>
Agreed.
> > Or perhaps a very fine wrapper if Trustin come with something really
> light, and non intrusive.
> >
> > Julien
>
Again Maarten is right this would send the wrong message.
I think we should just move on here. Take it as official I'm vetoing this
and other logging suggestions with a binding vote.
-1
It's done. Let's move on. You can revisit it next year if you like.
Alex
Re: Revisiting logging in MINA 2.0
Posted by Julien Vermillard <jv...@archean.fr>.
On Tue, 18 Dec 2007 09:08:15 -0500
"Alex Karasulu" <ak...@apache.org> wrote:
> On Dec 18, 2007 4:47 AM, Julien Vermillard <jv...@archean.fr>
> wrote:
>
> > On Tue, 18 Dec 2007 10:32:41 +0100
> > Emmanuel Lecharny <el...@gmail.com> wrote:
> >
> > > Hi Trustin,
> > >
> > > I think that everybody should keep calm and peaceful. What are we
> > > discussing about ? A logging framework and nothing else.
> > >
> > > As you said, you have added a page explaining how to use SLF4J
> > > with MINA and another project. It works, it is simple, and you
> > > have added the full howto. So what is the problem? Does someone
> > > will trade off against MINA just because he has 'problem' with
> > > slf4j when we _know_ that slf4j is not a problem at all? come
> > > on ... Adding 2 jars in a classpath is a good price to pay for
> > > benefit from MINA.
> > >
> >
> > Hi Emmanuel,
> > I think everybody understood your point. I think everybody agree
> > here for say slf4j is really not a problem. The idea is to give some
> > solution for the people who can't live with another dependency that
> > will look 'ugly' in their classpath (I know you think it's
> > stupid :D).
> >
>
> Can't live with another dependency that will look 'ugly'? Come on!
> You know anyone can live with that but they might not like it. This
> is not our problem.
>
> Alex
I know it's stupid but providing them a patchset (automatically
generated) or a mina.jar bundled with slf4j-nop, will make them happy in
their ignorance.
That won't bloat, that won't hurt sfl4j, that won't eat your cat and
I'm pretty sure one day they will be bored and integrate slf4j.
I can say that because 2 years ago I was running a MINA version patched
for removing *all* the call to slf4j (and some other tunning) but since
it proved to be a nice piece of code and I was quite bored to maintain
it and I finally adopted slf4j.
My only regret is to have too much code depending on log4j.
Julien
Re: Revisiting logging in MINA 2.0
Posted by Alex Karasulu <ak...@apache.org>.
On Dec 18, 2007 4:47 AM, Julien Vermillard <jv...@archean.fr> wrote:
> On Tue, 18 Dec 2007 10:32:41 +0100
> Emmanuel Lecharny <el...@gmail.com> wrote:
>
> > Hi Trustin,
> >
> > I think that everybody should keep calm and peaceful. What are we
> > discussing about ? A logging framework and nothing else.
> >
> > As you said, you have added a page explaining how to use SLF4J with
> > MINA and another project. It works, it is simple, and you have added
> > the full howto. So what is the problem? Does someone will trade off
> > against MINA just because he has 'problem' with slf4j when we _know_
> > that slf4j is not a problem at all? come on ... Adding 2 jars in a
> > classpath is a good price to pay for benefit from MINA.
> >
>
> Hi Emmanuel,
> I think everybody understood your point. I think everybody agree here
> for say slf4j is really not a problem. The idea is to give some
> solution for the people who can't live with another dependency that
> will look 'ugly' in their classpath (I know you think it's stupid :D).
>
Can't live with another dependency that will look 'ugly'? Come on! You know
anyone can live with that but they might not like it. This is not our
problem.
Alex
Re: Revisiting logging in MINA 2.0
Posted by Maarten Bosteels <mb...@gmail.com>.
On Dec 18, 2007 10:47 AM, Julien Vermillard <jv...@archean.fr> wrote:
> On Tue, 18 Dec 2007 10:32:41 +0100
> Emmanuel Lecharny <el...@gmail.com> wrote:
>
> > Hi Trustin,
> >
> > I think that everybody should keep calm and peaceful. What are we
> > discussing about ? A logging framework and nothing else.
> >
> > As you said, you have added a page explaining how to use SLF4J with
> > MINA and another project. It works, it is simple, and you have added
> > the full howto. So what is the problem? Does someone will trade off
> > against MINA just because he has 'problem' with slf4j when we _know_
> > that slf4j is not a problem at all? come on ... Adding 2 jars in a
> > classpath is a good price to pay for benefit from MINA.
> >
>
> Hi Emmanuel,
> I think everybody understood your point. I think everybody agree here
> for say slf4j is really not a problem. The idea is to give some
> solution for the people who can't live with another dependency that
> will look 'ugly' in their classpath (I know you think it's stupid :D).
>
> So that why releasing a patchset for them, or a mina.jar bundled with
> slf4j-nop will be fine and will hurt nobody.
Question remains if the MINA team should try to solve this, since we
all agree that there is no problem with SLF4J ?
I hope we're not sending out the wrong message about SLF4J by creating
such a tool ?
I think a lot of people (including me) would really like to see a
massive adoption of SLF4J by other projects (instead of JCL)
so that the entire java community can stop wasting time discussing
logging frameworks :-p
Of course, it's not MINA's task to promote SLF4J but at least we
should give it the credit it deserves.
Maarten
> Or perhaps a very fine wrapper if Trustin come with something really light, and non intrusive.
>
> Julien
Re: Revisiting logging in MINA 2.0
Posted by Emmanuel Lecharny <el...@gmail.com>.
Julien Vermillard wrote:
> mina.jar bundled with
> slf4j-nop will be fine and will hurt nobody.
I buy this idea !
Thanks Julien !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Revisiting logging in MINA 2.0
Posted by Julien Vermillard <jv...@archean.fr>.
On Tue, 18 Dec 2007 10:32:41 +0100
Emmanuel Lecharny <el...@gmail.com> wrote:
> Hi Trustin,
>
> I think that everybody should keep calm and peaceful. What are we
> discussing about ? A logging framework and nothing else.
>
> As you said, you have added a page explaining how to use SLF4J with
> MINA and another project. It works, it is simple, and you have added
> the full howto. So what is the problem? Does someone will trade off
> against MINA just because he has 'problem' with slf4j when we _know_
> that slf4j is not a problem at all? come on ... Adding 2 jars in a
> classpath is a good price to pay for benefit from MINA.
>
Hi Emmanuel,
I think everybody understood your point. I think everybody agree here
for say slf4j is really not a problem. The idea is to give some
solution for the people who can't live with another dependency that
will look 'ugly' in their classpath (I know you think it's stupid :D).
So that why releasing a patchset for them, or a mina.jar bundled with
slf4j-nop will be fine and will hurt nobody. Or perhaps a very fine
wrapper if Trustin come with something really light, and non intrusive.
Julien
Re: Revisiting logging in MINA 2.0
Posted by Emmanuel Lecharny <el...@gmail.com>.
Hi Trustin,
I think that everybody should keep calm and peaceful. What are we
discussing about ? A logging framework and nothing else.
As you said, you have added a page explaining how to use SLF4J with MINA
and another project. It works, it is simple, and you have added the full
howto. So what is the problem? Does someone will trade off against MINA
just because he has 'problem' with slf4j when we _know_ that slf4j is
not a problem at all? come on ... Adding 2 jars in a classpath is a good
price to pay for benefit from MINA.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Revisiting logging in MINA 2.0
Posted by Trustin Lee <tr...@gmail.com>.
You made many good points but I need to correct some.
On Dec 18, 2007 3:51 PM, Alex Karasulu <ak...@apache.org> wrote:
<snip/>
> (4) I won't go into detail to keep some things private but I know you wanted
> to find this thread [1] because it was one which you suspected was a veto
> against you. You explicitly searched for and found this thread after some
> recent events.
I have never searched for that thread. What I searched for was a vote
about inviting someone into the PMC. Moreover, what's up with the
veto from the community? If the community doesn't like my idea, then
that's OK.
People can veto my idea, but I also have my right to keep persuading
my idea as long as I think it's really right and it is the
responsibility of the community to pursuade me that my point is wrong
or it's just a matter of trade-off. Additionally, we didn't have
issues related with framework on top of framework (or library) and
logger reentrancy at that time, and that's why I think we need to
reconsider the previous decision.
I don't feel offended by the decision of the community. What really
dismays me is this kind of personal offense. Saying 'I won't go into
detail to keep some things private' just makes me laugh; what would
people imagine about me? Is this intentional to spread out some
conspiracy theory?
> However, regarding this thread coming back to life, it occurred right after
> you explicitly searched for it. You wanted to bring it up again, primarily
> because it was an outstanding issue that you felt was legitimate. Most
> importantly, it did not unfold in the manner you wanted it to be addressed.
Again, I did never searched for it both implicitly and explicitly, and
please note we got two new issues related with the current logging in
MINA which were discovered very recently. You are saying that I will
do the best for MINA and I want to control this project at the same
time by saying 'Most importantly, it did not unfold in the manner you
wanted it to be addressed.' It sounds like I am driving this project
for my personal benefit and you are upsetting me seriously.
> This is all fine, but I'm wondering why David kicked it off and joined in.
> I'm not suggesting we have a "follow the leader" situation but the
> possibility is starting to occur regularly in my head. This is happening
> because I fear having the merits of my points undermined by back channel
> coordination. Again I am not accusing you of it. I am stating it as a
> concern and something that my reasoning points to as a possibility.
You don't need to worry about that at all. I found David and I have
similar idea about logging and he is also the author of a framework
that suffers with many logging framework JARs. He has his concern and
I have to resolve his concern as a committer of MINA project not as a
colleague of him. Of course, our employer provides a private IRC
channel, but please note that our communication about MINA almost
always occurred in #mina channel at freenode.net or this mailing list.
> Thankfully, the majority, of individuals on thread [0], naturally opposed
> the emergence of yet another logging API. If they did not, then my voice or
> any other opposing voice, would be drowned out. As a well respected and
> empowered member of this community, you should try to prevent your over
> whelming stature from drowning out fainter voices of reason.
It sounds like that I have ever tried to bury someone's voice. Did I
get something wrong?
> Sometimes
> there is no absolute right or wrong decision and it's a trade off. So, when
> you possess so much influence, the responsible thing to do is to look out
> for those that have less influence but are trying to make a point for the
> benefit of the project.
Who have less influence and who have more? Do I have more influence
over this issue? Or... is that you? I might have more influence in
overall decision, but this thread is not the case as you already know.
And.. explain me why it is a matter of trade-off. To me, it's a
critical issue that hinders the adoption of MINA in many library
projects. Anyone can create his or her own protocol implementation
and provide it as a new library wrapped with more protocol-specific
API, and then now we are forcing them to use SLF4J just because we
believe it's good no matter how he or she thinks about SLF4J. I think
it's even against the spirit of the open source activity; it's rather
the violence over potential users.
> The majority has expressed it's disinterest with this idea and sometimes you
> need to yield to the community over your own beliefs of what is the best
> route. Let the community find out for itself if it is wrong. Besides, they
> got your message. They already have the information for your approach
> imprinted twice now in the archives. If the rest of us is wrong we can
> revisit the topic. It's fair to say, the majority is still not interested
> in pursuing yet another logging API to be maintained by MINA. So can we
> drop this, please?
To finish this discussion, Maarten or any other community members will
have to provide a better alternative to my idea. Why are you and they
ignoring those minorities who have *less influence* really by saying
'just live with it'? There are people out there who just can't live
with it. Shoule we let people drop MINA from their dependency like I
did for Commons BeanUtils just because of logging? That is a real
nonsense.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: Revisiting logging in MINA 2.0
Posted by Alex Karasulu <ak...@apache.org>.
On Dec 17, 2007 11:13 PM, Trustin Lee <tr...@gmail.com> wrote:
> On Dec 18, 2007 3:40 AM, Alex Karasulu <ak...@apache.org> wrote:
> > On Dec 17, 2007 11:29 AM, Maarten Bosteels <mb...@gmail.com>
> wrote:
> > > IMO, that is a rather weak argument for resorting to our own "thin
> > > layer for logging".
> >
> > Yes I agree completely. It's unnecessary to add yet another logging
> layer.
> >
> > I know several JBoss people are resentful with having to use SLF4J while
> now
> > using MINA but there is no reason why we should push forward with that.
>
> You understood plain wrong. It's not about JBoss people but about any
> possible users who want to build their own framework on top of MINA.
> Do you think I am pushing this because I am working for JBoss? Never.
No I am not saying you are "pushing this because [you are] working for
JBoss". You have jumped to the wrong conclusion. Let me tell you what I
know about the present situation and what I am thinking or fearing:
(1) I am aware of a few things regarding JBoss:
(a) I know David Lloyd is a JBoss employee. Yes the other guy with
your same opinion.
(b) I know you, Trustin, are a JBoss employee.
(c) I know that you guys interact outside of this list through office
channels.
(d) I have friends at JBoss who have asked several times before JBoss
hired you if I can work on you to drop SLF4J. They should know no one can
work on you :). I refused to do that since they can make their points
themselves on the list directly with you.
NOTE: I've always liked people in both JBoss and Geronimo communities.
Because of these relations and my association with both Apache and JBoss I
have always remained neutral and unbiased to both. That will always remain
the case.
(2) I know you and David are the minority pushing for the same logging API
in MINA. Just look at the email trail [0]. There are many more who are
opposed to this idea.
(3) You pushed this same agenda in the past before you were a JBoss employee
[1]. (How can I suggest JBoss is making you do this?)
(4) I won't go into detail to keep some things private but I know you wanted
to find this thread [1] because it was one which you suspected was a veto
against you. You explicitly searched for and found this thread after some
recent events.
(5) I know you mean the best for MINA since it is somewhat a source of
recognition for you (and there is nothing wrong with that since you should
benefit from your hard effort on MINA). Also you may change employers but
will always keep your association with MINA.
So because of #3 specifically, (and #5) I am aware that you're not doing
this because of JBoss pressure. That's not the main point I was trying to
make. I know you genuinely think this is the best for MINA. I know of
others besides you employed by JBoss and these were the people I was
referring too. These were the people in #1 (d). You incorrectly presumed I
was referring to you.
However, regarding this thread coming back to life, it occurred right after
you explicitly searched for it. You wanted to bring it up again, primarily
because it was an outstanding issue that you felt was legitimate. Most
importantly, it did not unfold in the manner you wanted it to be addressed.
This is all fine, but I'm wondering why David kicked it off and joined in.
I'm not suggesting we have a "follow the leader" situation but the
possibility is starting to occur regularly in my head. This is happening
because I fear having the merits of my points undermined by back channel
coordination. Again I am not accusing you of it. I am stating it as a
concern and something that my reasoning points to as a possibility.
Thankfully, the majority, of individuals on thread [0], naturally opposed
the emergence of yet another logging API. If they did not, then my voice or
any other opposing voice, would be drowned out. As a well respected and
empowered member of this community, you should try to prevent your over
whelming stature from drowning out fainter voices of reason. Sometimes
there is no absolute right or wrong decision and it's a trade off. So, when
you possess so much influence, the responsible thing to do is to look out
for those that have less influence but are trying to make a point for the
benefit of the project.
The majority has expressed it's disinterest with this idea and sometimes you
need to yield to the community over your own beliefs of what is the best
route. Let the community find out for itself if it is wrong. Besides, they
got your message. They already have the information for your approach
imprinted twice now in the archives. If the rest of us is wrong we can
revisit the topic. It's fair to say, the majority is still not interested
in pursuing yet another logging API to be maintained by MINA. So can we
drop this, please?
Alex
-----------------------------
[0] - http://mina.markmail.org/search/?q=Revisiting+logging+in+MINA+2.0
[1] - http://mina.markmail.org/search/?q=Is+SLF4J+hard+to+configure%3F
Re: Revisiting logging in MINA 2.0
Posted by Trustin Lee <tr...@gmail.com>.
On Dec 18, 2007 3:40 AM, Alex Karasulu <ak...@apache.org> wrote:
> On Dec 17, 2007 11:29 AM, Maarten Bosteels <mb...@gmail.com> wrote:
> > On Dec 17, 2007 6:25 AM, Trustin Lee <tr...@gmail.com> wrote:
> ...
> > 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".
>
> Yes I agree completely. It's unnecessary to add yet another logging layer.
>
> I know several JBoss people are resentful with having to use SLF4J while now
> using MINA but there is no reason why we should push forward with that.
You understood plain wrong. It's not about JBoss people but about any
possible users who want to build their own framework on top of MINA.
Do you think I am pushing this because I am working for JBoss? Never.
I got this kind of request more than 10 times in my previous company.
What does that mean? There are much more people than you expect who
care about the number of JARs and complication related with using many
logging frameworks at the same time.
> Why not just work with Ceki or see if you can get karma on that project to
> fix these problems and/or facilitate the advance of a release with the fix?
> Ceki, I am sure would appreciate that. Plus the work you do there can
> benefit other projects using this framework. I have CC'd Ceki to get his
> attention so we can do something sane about this.
SLF4J cannot help this problem because SLF4J itself doesn't have any 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.
>
> There are many people in this situation. Adding yet another framework
> whether mini or not is going to add to the confusion.
It's also often true that people get confused with configuring SLF4J.
Yeah, it's brain-dead easy once understood, but it adds a lot of
confusion to novice. Anyways, we have the dedicated page for logging
configuration so 'the confusion' you are referring to is not a problem
at all. As you already know, it's just adding one line of code to
switch the preferred logging framework from users' point of view and I
don't think that's really a big burden comparing to adding two JARs in
the classpath.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: Revisiting logging in MINA 2.0
Posted by Alex Karasulu <ak...@apache.org>.
On Dec 17, 2007 11:29 AM, Maarten Bosteels <mb...@gmail.com> wrote:
>
> On Dec 17, 2007 6:25 AM, Trustin Lee <tr...@gmail.com> wrote:
>
...
> 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".
>
Yes I agree completely. It's unnecessary to add yet another logging layer.
I know several JBoss people are resentful with having to use SLF4J while now
using MINA but there is no reason why we should push forward with that.
Why not just work with Ceki or see if you can get karma on that project to
fix these problems and/or facilitate the advance of a release with the fix?
Ceki, I am sure would appreciate that. Plus the work you do there can
benefit other projects using this framework. I have CC'd Ceki to get his
attention so we can do something sane about this.
...
> 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.
>
There are many people in this situation. Adding yet another framework
whether mini or not is going to add to the confusion.
>
> 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.
>
Absolutely!
Alex
Re: Revisiting logging in MINA 2.0
Posted by Maarten Bosteels <mb...@gmail.com>.
Hello all,
On Dec 17, 2007 6:25 AM, Trustin Lee <tr...@gmail.com> wrote:
> Hi Maarten,
>
> On Dec 15, 2007 3:26 AM, Maarten Bosteels <mb...@gmail.com> 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
>
Re: Revisiting logging in MINA 2.0
Posted by Trustin Lee <tr...@gmail.com>.
Hi Maarten,
On Dec 15, 2007 3:26 AM, Maarten Bosteels <mb...@gmail.com> 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
Re: Revisiting logging in MINA 2.0
Posted by "David M. Lloyd" <da...@redhat.com>.
On Fri, 14 Dec 2007 19:26:13 +0100
"Maarten Bosteels" <mb...@gmail.com> wrote:
> about (1) and (3) : I have (almost) no experience with java.util.logging but
> I from the info in this thread I understand that is necessary to set a
> system property to use a custom LogManager.
> This means two webapps deployed on the same tomcat instance MUST share the
> same LogManager ?
> One could argue that this is tomcat's fault, because it should have separate
> system properties per webapp ...
Yes, but the LogManager is the container's responsibility. It doesn't
really matter that there's only one. You can still set separate
handlers for each webapp if you want to.
> I don't understand the so-called "barrier of configuring SLF4J".
> There is NO configuration, just using the jar of your choice. And optionally
> configuring the framework of your choice.
>
> And I don't understand why people have problems with a dependency on SLF4J ?
The problem is not applications. The problem is other frameworks that
want to use MINA as the underlying transport handler. Many of these
frameworks must then depend on more than one log facade jar.
> I don't like the idea of a thin layer inside MINA, why would that be any
> better than depend on SLF4J ?
> Would people A find it more acceptable if the SLF4J classes where included
> inside the mina jar ? (this doesn't make sense to me, but then they wouldn't
> SEE the SLF4J dependency)
Yes, that would be better - but then the slf4j classes have to be
relocated under another package (perhaps something like jarjar could
help with this). Otherwise other projects doing the same thing may
conflict.
> SLF4J has a richer API than JUL (MDC, Marker, varargs, ...)
> Using java.util.logging directly in MINA means we would lose the ability to
> use this API.
Using a wrapper class solves these issues.
- DML
Re: Revisiting logging in MINA 2.0
Posted by Maarten Bosteels <mb...@gmail.com>.
Hello all,
On Dec 13, 2007 3:50 AM, Trustin Lee <tr...@gmail.com> wrote:
> This issue is becoming a real headache even a bottle of tylenol can't
> fix, along with the reentrant logging issue: http://xrl.us/bctaa
>
> I think these two issues should be considered together to resolve the
> issues related with logging. Let me summarize current situation:
>
> 1) There are people (A) who don't want to use SLF4J but java.util.logging.
> 2) There are people (B) who like to use SLF4J and they say SLF4J
> supports java.util.logging along with log4j.
> 3) People A say java.util.logging can also do the same by employing a
> proper LogManager implementation.
> 4) There is a logger reentrance problem in MINA, which means it is
> difficult to write a MINA-based appender for the most logging
> frameworks that doesn't allow reentrance. This problem can be worked
> around by turning off logging in MINA, but this is not reasonable.
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.
about (1) and (3) : I have (almost) no experience with java.util.logging but
I from the info in this thread I understand that is necessary to set a
system property to use a custom LogManager.
This means two webapps deployed on the same tomcat instance MUST share the
same LogManager ?
One could argue that this is tomcat's fault, because it should have separate
system properties per webapp ...
Without considering the item #4, it might look like a debate about
> choosing the default logging framework for MINA 2. However, taking
> the item #4 into picture, it leads me to think we need a thin built-in
> layer for logging that is dedicated to MINA. Moreover, such a layer
> could satisfy both party (people A and B). Also, we could make the
> SLF4J dependency optional by making java.util.logging the default
> logger. This will potentially reduce the barrier of configuring SLF4J
> which is frequently asked.
I don't understand the so-called "barrier of configuring SLF4J".
There is NO configuration, just using the jar of your choice. And optionally
configuring the framework of your choice.
And I don't understand why people have problems with a dependency on SLF4J ?
I don't like the idea of a thin layer inside MINA, why would that be any
better than depend on SLF4J ?
Would people A find it more acceptable if the SLF4J classes where included
inside the mina jar ? (this doesn't make sense to me, but then they wouldn't
SEE the SLF4J dependency)
SLF4J has a richer API than JUL (MDC, Marker, varargs, ...)
Using java.util.logging directly in MINA means we would lose the ability to
use this API.
So many projects are using SLF4J, do they get the same questions ?
>From the poll we did in september, only one person (out of 19) was using
java.util.logging.
I wonder how many MINA users REALLY have a problem with SLF4J.
Of course, this doesn't mean that users have to use that logging layer
> to log their application messages but it means only the classes under
> org.apache.mina should use that layer for all logging.
>
> Does my idea make sense? Or do you have any better idea?
I am clearly part of people B :-)
To be short, I fail to see the problem (under the assumpton that (4) is a
problem in log4j not in Mina)
>
>
> We are all obssessed in logging right? :D
I am not! :D
regards,
Maarten
Re: Revisiting logging in MINA 2.0
Posted by Emmanuel Lecharny <el...@gmail.com>.
Julien Vermillard wrote:
>>
>> Ok, I open my client project today, and what do I see ? more than 60
>> f**ing jars. What kind of problem can it be to add one more jar ???
>> Maven, maven, maven !
>>
>>
> A real problem is trying to deploy native libs with maven and trying to
> find a nice solution in the doc ;)
>
Did I ever said that I was in love with Maven ? ;) I might have been
totally drunk then ;)
> Julien
>
>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Revisiting logging in MINA 2.0
Posted by Julien Vermillard <jv...@archean.fr>.
On Tue, 18 Dec 2007 10:39:00 +0100
Emmanuel Lecharny <el...@gmail.com> wrote:
> Trustin Lee wrote:
> > On Dec 18, 2007 5:38 PM, Julien Vermillard <jv...@archean.fr>
> > wrote:
> >> We all agree configuring slf4j is a piece of cake (drop the good
> >> jar).
> >>
> >> I can understand seeing another jar in the dependencies list can
> >> annoy some potential MINA users (who said politics ?:D).
> >>
> >>
> Ok, I open my client project today, and what do I see ? more than 60
> f**ing jars. What kind of problem can it be to add one more jar ???
> Maven, maven, maven !
>
A real problem is trying to deploy native libs with maven and trying to
find a nice solution in the doc ;)
Julien
Re: Revisiting logging in MINA 2.0
Posted by Emmanuel Lecharny <el...@gmail.com>.
Trustin Lee wrote:
> On Dec 18, 2007 5:38 PM, Julien Vermillard <jv...@archean.fr> wrote:
>
>> We all agree configuring slf4j is a piece of cake (drop the good jar).
>>
>> I can understand seeing another jar in the dependencies list can annoy
>> some potential MINA users (who said politics ?:D).
>>
>>
Ok, I open my client project today, and what do I see ? more than 60
f**ing jars. What kind of problem can it be to add one more jar ???
Maven, maven, maven !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Revisiting logging in MINA 2.0
Posted by Maarten Bosteels <mb...@gmail.com>.
On Dec 18, 2007 9:51 AM, Trustin Lee <tr...@gmail.com> wrote:
>
> On Dec 18, 2007 5:38 PM, Julien Vermillard <jv...@archean.fr> wrote:
> > On Tue, 18 Dec 2007 13:01:40 +0900
> > "Trustin Lee" <tr...@gmail.com> wrote:
> >
> >
> > > On Dec 18, 2007 3:34 AM, Emmanuel Lecharny <el...@gmail.com>
> > > wrote:
> > > > Trustin Lee wrote:
> > > > > <snip/>
> > > >
> > > > > However, taking
> > > > > the item #4 into picture, it leads me to think we need a thin
> > > > > built-in layer for logging that is dedicated to MINA.
> > > > Please, don't ! This is MINA, a Network framework, not a Logger
> > > > framework ! We already have so many meta-meta-meta-loger around
> > > > there:)
> > >
> > > Yeah, it's a framework and I don't want it to force others to use the
> > > logging framework of our preference. Why should we do that? Because
> > > we are satisfied with SLF4J? Yes I am, but it simply doesn't make any
> > > sense to other people.
> > >
> > > As David said, what would people think if he or she has mina-core.jar,
> > > slf4j-log4j12.jar, log4j.jar and commons-logging.jar?
> > >
> > > Moreover, what I am suggesting is not about embeding another logging
> > > framework but adding a few logger classes, which is minimal, and it
> > > will not be used anywhere outside of MINA code itself.
> > >
> > > Trustin
> >
> > Hi,
> > First of all, logging is an important issue for me, because it's a main
> > selling point of the product I work on and the most dangerous feature
> > for my flash memory based systems.
> >
> > But I'm not that obsessed too ;)
>
> No you are not. I can assure that. :D
>
> > I was quite skeptical with having *another* dependency with slf4j, but
> > I can say I'm satisfied today. No problems with slf4j, and I'm
> > happy knowing I can change the underlying framework *easily*.
> >
> > We all agree configuring slf4j is a piece of cake (drop the good jar).
> >
> > I can understand seeing another jar in the dependencies list can annoy
> > some potential MINA users (who said politics ?:D).
> >
> > I think what Trustin got in mind is something *very* thin so perhaps if
> > we see the code, everybody will calm down and think it's a good
> > mix of the two world.
> >
> > Anyway if the thin layer can't make everybody agree why not simply
> > provide some scripts/tools/whatever for quickly patch the code for
> > removing the dependencies and inserting your logging statement ?
>
> We can do that, too. The problem though is that we have an
> IoSessionLogger class that implements SLF4J Logger interface directly.
> Once we can provide a solution for this one class, then we are all
> good. We can keep our official distribution stick to SLF4J and let
> people convert it to use other logging framework by applying some
> automated patch. I'd like to use Spoon project to create a tool that
> does the trick and open source it. WDYT? Doesn't it sound like
> almost a perfect solution? ;)
I guess I could live with that ;-)
regards,
Maarten
>
> If there's no objection, let me start this project in the Apache Labs
> or somewhere else. However, I'm not sure about what to do when this
> attempt fails. My kernel will panic, eek! :D
>
>
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP Key ID: 0x0255ECA6
>
Re: Revisiting logging in MINA 2.0
Posted by Trustin Lee <tr...@gmail.com>.
On Dec 18, 2007 5:38 PM, Julien Vermillard <jv...@archean.fr> wrote:
> On Tue, 18 Dec 2007 13:01:40 +0900
> "Trustin Lee" <tr...@gmail.com> wrote:
>
>
> > On Dec 18, 2007 3:34 AM, Emmanuel Lecharny <el...@gmail.com>
> > wrote:
> > > Trustin Lee wrote:
> > > > <snip/>
> > >
> > > > However, taking
> > > > the item #4 into picture, it leads me to think we need a thin
> > > > built-in layer for logging that is dedicated to MINA.
> > > Please, don't ! This is MINA, a Network framework, not a Logger
> > > framework ! We already have so many meta-meta-meta-loger around
> > > there:)
> >
> > Yeah, it's a framework and I don't want it to force others to use the
> > logging framework of our preference. Why should we do that? Because
> > we are satisfied with SLF4J? Yes I am, but it simply doesn't make any
> > sense to other people.
> >
> > As David said, what would people think if he or she has mina-core.jar,
> > slf4j-log4j12.jar, log4j.jar and commons-logging.jar?
> >
> > Moreover, what I am suggesting is not about embeding another logging
> > framework but adding a few logger classes, which is minimal, and it
> > will not be used anywhere outside of MINA code itself.
> >
> > Trustin
>
> Hi,
> First of all, logging is an important issue for me, because it's a main
> selling point of the product I work on and the most dangerous feature
> for my flash memory based systems.
>
> But I'm not that obsessed too ;)
No you are not. I can assure that. :D
> I was quite skeptical with having *another* dependency with slf4j, but
> I can say I'm satisfied today. No problems with slf4j, and I'm
> happy knowing I can change the underlying framework *easily*.
>
> We all agree configuring slf4j is a piece of cake (drop the good jar).
>
> I can understand seeing another jar in the dependencies list can annoy
> some potential MINA users (who said politics ?:D).
>
> I think what Trustin got in mind is something *very* thin so perhaps if
> we see the code, everybody will calm down and think it's a good
> mix of the two world.
>
> Anyway if the thin layer can't make everybody agree why not simply
> provide some scripts/tools/whatever for quickly patch the code for
> removing the dependencies and inserting your logging statement ?
We can do that, too. The problem though is that we have an
IoSessionLogger class that implements SLF4J Logger interface directly.
Once we can provide a solution for this one class, then we are all
good. We can keep our official distribution stick to SLF4J and let
people convert it to use other logging framework by applying some
automated patch. I'd like to use Spoon project to create a tool that
does the trick and open source it. WDYT? Doesn't it sound like
almost a perfect solution? ;)
If there's no objection, let me start this project in the Apache Labs
or somewhere else. However, I'm not sure about what to do when this
attempt fails. My kernel will panic, eek! :D
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: Revisiting logging in MINA 2.0
Posted by Julien Vermillard <jv...@archean.fr>.
On Tue, 18 Dec 2007 13:01:40 +0900
"Trustin Lee" <tr...@gmail.com> wrote:
> On Dec 18, 2007 3:34 AM, Emmanuel Lecharny <el...@gmail.com>
> wrote:
> > Trustin Lee wrote:
> > > <snip/>
> >
> > > However, taking
> > > the item #4 into picture, it leads me to think we need a thin
> > > built-in layer for logging that is dedicated to MINA.
> > Please, don't ! This is MINA, a Network framework, not a Logger
> > framework ! We already have so many meta-meta-meta-loger around
> > there:)
>
> Yeah, it's a framework and I don't want it to force others to use the
> logging framework of our preference. Why should we do that? Because
> we are satisfied with SLF4J? Yes I am, but it simply doesn't make any
> sense to other people.
>
> As David said, what would people think if he or she has mina-core.jar,
> slf4j-log4j12.jar, log4j.jar and commons-logging.jar?
>
> Moreover, what I am suggesting is not about embeding another logging
> framework but adding a few logger classes, which is minimal, and it
> will not be used anywhere outside of MINA code itself.
>
> Trustin
Hi,
First of all, logging is an important issue for me, because it's a main
selling point of the product I work on and the most dangerous feature
for my flash memory based systems.
But I'm not that obsessed too ;)
I was quite skeptical with having *another* dependency with slf4j, but
I can say I'm satisfied today. No problems with slf4j, and I'm
happy knowing I can change the underlying framework *easily*.
We all agree configuring slf4j is a piece of cake (drop the good jar).
I can understand seeing another jar in the dependencies list can annoy
some potential MINA users (who said politics ?:D).
I think what Trustin got in mind is something *very* thin so perhaps if
we see the code, everybody will calm down and think it's a good
mix of the two world.
Anyway if the thin layer can't make everybody agree why not simply
provide some scripts/tools/whatever for quickly patch the code for
removing the dependencies and inserting your logging statement ?
Julien
Re: Revisiting logging in MINA 2.0
Posted by Emmanuel Lecharny <el...@gmail.com>.
Trustin Lee wrote:
> On Dec 18, 2007 3:34 AM, Emmanuel Lecharny <el...@gmail.com> wrote:
>
>> Trustin Lee wrote:
>>
>>> <snip/>
>>>
>>> However, taking
>>> the item #4 into picture, it leads me to think we need a thin built-in
>>> layer for logging that is dedicated to MINA.
>>>
>> Please, don't ! This is MINA, a Network framework, not a Logger
>> framework ! We already have so many meta-meta-meta-loger around there:)
>>
>
> Yeah, it's a framework and I don't want it to force others to use the
> logging framework of our preference. Why should we do that? Because
> we are satisfied with SLF4J? Yes I am, but it simply doesn't make any
> sense to other people.
>
No, simply because it works. Don't fix it :) As there are already 2
existing logger plus at least 2 meta-logger, you _won't_ be able to
please everyone. We would have chose CL a while back, and we would have
seen the very same problem. As far as we know, SLF4J hasn't be a problem
at all, so why do we have ro suddenly change because a dude asked for
this change ?
> As David said, what would people think if he or she has mina-core.jar,
> slf4j-log4j12.jar, log4j.jar and commons-logging.jar?
>
They will think : "Thanks to maven, I don't have to grab myself those
jars from the web" !
> Moreover, what I am suggesting is not about embeding another logging
> framework but adding a few logger classes, which is minimal, and it
> will not be used anywhere outside of MINA code itself.
>
This is exactly the same thing : you start with a thin abstraction
layer, and you end with a meta-meta-[-meta*]-looger again, inside MINA,
cluttering the code. This is a typical NIH syndrom. You are trying to
cure the symptoms, not the causes.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Revisiting logging in MINA 2.0
Posted by Trustin Lee <tr...@gmail.com>.
On Dec 18, 2007 3:34 AM, Emmanuel Lecharny <el...@gmail.com> wrote:
> Trustin Lee wrote:
> > <snip/>
>
> > However, taking
> > the item #4 into picture, it leads me to think we need a thin built-in
> > layer for logging that is dedicated to MINA.
> Please, don't ! This is MINA, a Network framework, not a Logger
> framework ! We already have so many meta-meta-meta-loger around there:)
Yeah, it's a framework and I don't want it to force others to use the
logging framework of our preference. Why should we do that? Because
we are satisfied with SLF4J? Yes I am, but it simply doesn't make any
sense to other people.
As David said, what would people think if he or she has mina-core.jar,
slf4j-log4j12.jar, log4j.jar and commons-logging.jar?
Moreover, what I am suggesting is not about embeding another logging
framework but adding a few logger classes, which is minimal, and it
will not be used anywhere outside of MINA code itself.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: Revisiting logging in MINA 2.0
Posted by Emmanuel Lecharny <el...@gmail.com>.
Trustin Lee wrote:
> <snip/>
> However, taking
> the item #4 into picture, it leads me to think we need a thin built-in
> layer for logging that is dedicated to MINA.
Please, don't ! This is MINA, a Network framework, not a Logger
framework ! We already have so many meta-meta-meta-loger around there:)
> Cheers,
> Trustin
>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Revisiting logging in MINA 2.0
Posted by Trustin Lee <tr...@gmail.com>.
This issue is becoming a real headache even a bottle of tylenol can't
fix, along with the reentrant logging issue: http://xrl.us/bctaa
I think these two issues should be considered together to resolve the
issues related with logging. Let me summarize current situation:
1) There are people (A) who don't want to use SLF4J but java.util.logging.
2) There are people (B) who like to use SLF4J and they say SLF4J
supports java.util.logging along with log4j.
3) People A say java.util.logging can also do the same by employing a
proper LogManager implementation.
4) There is a logger reentrance problem in MINA, which means it is
difficult to write a MINA-based appender for the most logging
frameworks that doesn't allow reentrance. This problem can be worked
around by turning off logging in MINA, but this is not reasonable.
Without considering the item #4, it might look like a debate about
choosing the default logging framework for MINA 2. However, taking
the item #4 into picture, it leads me to think we need a thin built-in
layer for logging that is dedicated to MINA. Moreover, such a layer
could satisfy both party (people A and B). Also, we could make the
SLF4J dependency optional by making java.util.logging the default
logger. This will potentially reduce the barrier of configuring SLF4J
which is frequently asked.
Of course, this doesn't mean that users have to use that logging layer
to log their application messages but it means only the classes under
org.apache.mina should use that layer for all logging.
Does my idea make sense? Or do you have any better idea?
We are all obssessed in logging right? :D
Cheers,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: Revisiting logging in MINA 2.0
Posted by "David M. Lloyd" <da...@redhat.com>.
On Wed, 12 Dec 2007 10:50:49 -0800
Brian McCallister <br...@skife.org> wrote:
> David,
>
> I disagree. If you use jdk logging you require anyone using the
> library to also use jdk logging.
What makes you think that?
> If you use slf4j (or commons-logging)
> you require them put an slf4j implementation on their classpath which
> delegates to the logging implementation they use for everything else.
>
> I don't want to configure jdk logging and juli and log4j and logkit
> and nlog4j and slf4j in order to use assorted libraries, I want to
> configure log4j and then tell everything else to use log4j. This is
> what slf4j does.
It is also possible to make JDK logging do this. Granted you have to
set one system property and include a JAR. If, on the other hand, you
were already using JDK logging, you don't have to do anything at all.
The difference with slf4j is that you always must have slf4j to make it
work.
>
> -Brian
>
>
> On Dec 11, 2007, at 11:05 AM, David M. Lloyd wrote:
>
> > Hello fellow MINA users. I come before you today to hopefully change
> > your collective minds on an issue that is causing me trouble, and is
> > preventing two other big projects that I know of from adopting MINA
> > for
> > I/O.
> >
> > The issue is, of course, logging. The problem is simple: anyone who
> > wants to use MINA must also have slf4j in their classpath to support
> > logging. This is not optional.
> >
> > The reason that this becomes a difficulty is that MINA is a framework
> > that is very attractive not only to your average end-developer, but
> > also to other framework authors. As a framework author myself, I plan
> > to use MINA for high-throughput network I/O - it's well-written,
> > clean,
> > and proven to be quite efficient. However, my framework, MINA, and
> > another dependency of my project each use a different logging API,
> > resulting in the need for the user to have two different logging JARs
> > in the classpath in order to use my framework.
> >
> > It is my firm believe that ALL framework libraries that require
> > logging
> > should use JDK logging. The reason is simple: the user does not then
> > have any external JAR requirement for logging, unless they CHOOSE to
> > use a different framework.
> >
> > You may be thinking that by using JDK logging, you are somehow taking
> > away the user's choice of logging frameworks. But this is not an
> > accurate view of the situation. Even if the user doesn't want to use
> > or configure JDK logging, there is nothing preventing the container or
> > the user's log framework of choice from registering its own
> > LogManager. Indeed just about every major container out there does
> > this, and with good reason - many existing frameworks already use JDK
> > logging. And why wouldn't they? It's a logging API that does the
> > job,
> > and it's been built in to every JDK since 1.4.0.
> >
> > In fact, by using JDK logging you INCREASE the user's ability to
> > choose
> > logging frameworks, by not requiring them to include a logging meta-
> > jar
> > of any sort.
> >
> > Even if you (MINA developers) will ONLY use slf4j, PLEASE make it
> > optional somehow. Give the user the choice of not using slf4j rather
> > than imposing it on them (and us, the developers who want to leverage
> > MINA for our own frameworks).
> >
> > Please take some time to consider what I've said. If the slf4j
> > dependency is made optional or removed, I know for a fact that several
> > more projects will be using MINA for I/O that otherwise considered the
> > logging framework issue a show-stopper.
> >
> > Thanks!
> >
> > - DML
>
Re: Revisiting logging in MINA 2.0
Posted by Brian McCallister <br...@skife.org>.
David,
I disagree. If you use jdk logging you require anyone using the
library to also use jdk logging. If you use slf4j (or commons-logging)
you require them put an slf4j implementation on their classpath which
delegates to the logging implementation they use for everything else.
I don't want to configure jdk logging and juli and log4j and logkit
and nlog4j and slf4j in order to use assorted libraries, I want to
configure log4j and then tell everything else to use log4j. This is
what slf4j does.
-Brian
On Dec 11, 2007, at 11:05 AM, David M. Lloyd wrote:
> Hello fellow MINA users. I come before you today to hopefully change
> your collective minds on an issue that is causing me trouble, and is
> preventing two other big projects that I know of from adopting MINA
> for
> I/O.
>
> The issue is, of course, logging. The problem is simple: anyone who
> wants to use MINA must also have slf4j in their classpath to support
> logging. This is not optional.
>
> The reason that this becomes a difficulty is that MINA is a framework
> that is very attractive not only to your average end-developer, but
> also to other framework authors. As a framework author myself, I plan
> to use MINA for high-throughput network I/O - it's well-written,
> clean,
> and proven to be quite efficient. However, my framework, MINA, and
> another dependency of my project each use a different logging API,
> resulting in the need for the user to have two different logging JARs
> in the classpath in order to use my framework.
>
> It is my firm believe that ALL framework libraries that require
> logging
> should use JDK logging. The reason is simple: the user does not then
> have any external JAR requirement for logging, unless they CHOOSE to
> use a different framework.
>
> You may be thinking that by using JDK logging, you are somehow taking
> away the user's choice of logging frameworks. But this is not an
> accurate view of the situation. Even if the user doesn't want to use
> or configure JDK logging, there is nothing preventing the container or
> the user's log framework of choice from registering its own
> LogManager. Indeed just about every major container out there does
> this, and with good reason - many existing frameworks already use JDK
> logging. And why wouldn't they? It's a logging API that does the
> job,
> and it's been built in to every JDK since 1.4.0.
>
> In fact, by using JDK logging you INCREASE the user's ability to
> choose
> logging frameworks, by not requiring them to include a logging meta-
> jar
> of any sort.
>
> Even if you (MINA developers) will ONLY use slf4j, PLEASE make it
> optional somehow. Give the user the choice of not using slf4j rather
> than imposing it on them (and us, the developers who want to leverage
> MINA for our own frameworks).
>
> Please take some time to consider what I've said. If the slf4j
> dependency is made optional or removed, I know for a fact that several
> more projects will be using MINA for I/O that otherwise considered the
> logging framework issue a show-stopper.
>
> Thanks!
>
> - DML
Re: Revisiting logging in MINA 2.0
Posted by "David M. Lloyd" <da...@redhat.com>.
On Tue, 11 Dec 2007 21:25:14 -0800
"Cameron Taggart" <ca...@gmail.com> wrote:
> > But why? JDK logging is always available. It's the responsibility of
> > any good logging framework that has existed since 2001 to install a JDK
> > LogManager in my opinion.
>
> Do you know of a LogManager that can be used for slf4j? I asked about
> one on their mailing list last May. It is a missing piece to the
> puzzle that would benefit both java.util.logging and slf4j.
>
> http://www.slf4j.org/pipermail/user/2007-May/000349.html
>
> Cameron
Well, slf4j is just a logging facade, isn't it? So you'd want to
delegate to the underlying framework?
You probably could do a LogManager that delegates to slf4j though. If
things go well at work, we will soon have a public project that
implements this and many other small useful LogManagers - delegating to
log4j for sure. I never thought about delegating to a facade, but I
guess it could work as long as the facade doesn't delegate back to JDK
logging. :)
- DML
Re: Revisiting logging in MINA 2.0
Posted by Cameron Taggart <ca...@gmail.com>.
> But why? JDK logging is always available. It's the responsibility of
> any good logging framework that has existed since 2001 to install a JDK
> LogManager in my opinion.
Do you know of a LogManager that can be used for slf4j? I asked about
one on their mailing list last May. It is a missing piece to the
puzzle that would benefit both java.util.logging and slf4j.
http://www.slf4j.org/pipermail/user/2007-May/000349.html
Cameron
Re: Revisiting logging in MINA 2.0
Posted by "David M. Lloyd" <da...@redhat.com>.
On Tue, 11 Dec 2007 11:12:05 -0800
"Scott Peters" <sp...@visto.com> wrote:
> The Jericho html parser project allows for multiple logging systems to
> be used; SLF4J & Log4j being two of them. MINA could be modified to do
> the same sort of reflections lookup to determine which logging system is
> available. Just keep in mind someone may have to programmatically
> override the auto-detected logging system as we have here. :^)
But why? JDK logging is always available. It's the responsibility of
any good logging framework that has existed since 2001 to install a JDK
LogManager in my opinion.
I'm not saying that your idea isn't workable - it could probably be
done (like you say, other projects already do this). It just seems
more complicated than it needs to be. But I'll accept any solution
that gets rid of the dependency. :-)
- DML
> -----Original Message-----
> From: David M. Lloyd [mailto:david.lloyd@redhat.com]
> Sent: Tuesday, December 11, 2007 11:06 AM
> To: dev@mina.apache.org
> Subject: Revisiting logging in MINA 2.0
>
> Hello fellow MINA users. I come before you today to hopefully change
> your collective minds on an issue that is causing me trouble, and is
> preventing two other big projects that I know of from adopting MINA for
> I/O.
>
> The issue is, of course, logging. The problem is simple: anyone who
> wants to use MINA must also have slf4j in their classpath to support
> logging. This is not optional.
>
> The reason that this becomes a difficulty is that MINA is a framework
> that is very attractive not only to your average end-developer, but
> also to other framework authors. As a framework author myself, I plan
> to use MINA for high-throughput network I/O - it's well-written, clean,
> and proven to be quite efficient. However, my framework, MINA, and
> another dependency of my project each use a different logging API,
> resulting in the need for the user to have two different logging JARs
> in the classpath in order to use my framework.
>
> It is my firm believe that ALL framework libraries that require logging
> should use JDK logging. The reason is simple: the user does not then
> have any external JAR requirement for logging, unless they CHOOSE to
> use a different framework.
>
> You may be thinking that by using JDK logging, you are somehow taking
> away the user's choice of logging frameworks. But this is not an
> accurate view of the situation. Even if the user doesn't want to use
> or configure JDK logging, there is nothing preventing the container or
> the user's log framework of choice from registering its own
> LogManager. Indeed just about every major container out there does
> this, and with good reason - many existing frameworks already use JDK
> logging. And why wouldn't they? It's a logging API that does the job,
> and it's been built in to every JDK since 1.4.0.
>
> In fact, by using JDK logging you INCREASE the user's ability to choose
> logging frameworks, by not requiring them to include a logging meta-jar
> of any sort.
>
> Even if you (MINA developers) will ONLY use slf4j, PLEASE make it
> optional somehow. Give the user the choice of not using slf4j rather
> than imposing it on them (and us, the developers who want to leverage
> MINA for our own frameworks).
>
> Please take some time to consider what I've said. If the slf4j
> dependency is made optional or removed, I know for a fact that several
> more projects will be using MINA for I/O that otherwise considered the
> logging framework issue a show-stopper.
>
> Thanks!
>
> - DML
RE: Revisiting logging in MINA 2.0
Posted by Scott Peters <sp...@visto.com>.
The Jericho html parser project allows for multiple logging systems to
be used; SLF4J & Log4j being two of them. MINA could be modified to do
the same sort of reflections lookup to determine which logging system is
available. Just keep in mind someone may have to programmatically
override the auto-detected logging system as we have here. :^)
Just a thought,
-Scott
-----Original Message-----
From: David M. Lloyd [mailto:david.lloyd@redhat.com]
Sent: Tuesday, December 11, 2007 11:06 AM
To: dev@mina.apache.org
Subject: Revisiting logging in MINA 2.0
Hello fellow MINA users. I come before you today to hopefully change
your collective minds on an issue that is causing me trouble, and is
preventing two other big projects that I know of from adopting MINA for
I/O.
The issue is, of course, logging. The problem is simple: anyone who
wants to use MINA must also have slf4j in their classpath to support
logging. This is not optional.
The reason that this becomes a difficulty is that MINA is a framework
that is very attractive not only to your average end-developer, but
also to other framework authors. As a framework author myself, I plan
to use MINA for high-throughput network I/O - it's well-written, clean,
and proven to be quite efficient. However, my framework, MINA, and
another dependency of my project each use a different logging API,
resulting in the need for the user to have two different logging JARs
in the classpath in order to use my framework.
It is my firm believe that ALL framework libraries that require logging
should use JDK logging. The reason is simple: the user does not then
have any external JAR requirement for logging, unless they CHOOSE to
use a different framework.
You may be thinking that by using JDK logging, you are somehow taking
away the user's choice of logging frameworks. But this is not an
accurate view of the situation. Even if the user doesn't want to use
or configure JDK logging, there is nothing preventing the container or
the user's log framework of choice from registering its own
LogManager. Indeed just about every major container out there does
this, and with good reason - many existing frameworks already use JDK
logging. And why wouldn't they? It's a logging API that does the job,
and it's been built in to every JDK since 1.4.0.
In fact, by using JDK logging you INCREASE the user's ability to choose
logging frameworks, by not requiring them to include a logging meta-jar
of any sort.
Even if you (MINA developers) will ONLY use slf4j, PLEASE make it
optional somehow. Give the user the choice of not using slf4j rather
than imposing it on them (and us, the developers who want to leverage
MINA for our own frameworks).
Please take some time to consider what I've said. If the slf4j
dependency is made optional or removed, I know for a fact that several
more projects will be using MINA for I/O that otherwise considered the
logging framework issue a show-stopper.
Thanks!
- DML