I completely agree with Emmanuel.
Taking a decision based on the fact that mina *now* only has two places that
uses logging is dangerous: if MINA wants to become a "network platform" it
should not have these constraints. It should always be very easy to add
logging statements anywhere in the code. Removing a few logging statements
because they do not fit in the "abstraction layer" smells like a design
problem.
We are using log4j (no idea what the hell is wrong with it), but we also
need commons-logging because Spring depends on it.
And since we started using MINA, I also had to read the SLF4J docs, and I am
glad I did.
(I did not know that the classloader issues are solved in the latest CL
version)
MINA is the only library we use that depends on SLF4J but I really don't
mind.
If commons-logging really has solved all its infamous issues, than maybe
MINA
(and all other Apache projets) should switch to commons-logging, but if it
hasn't I think MINA should stick to SLF4J (or at least default to it)
On the other hand, it is a shame that there are so many java logging
toolkits which all have more or less the same features, and it's a shame
that not all Apache projects could agree on one logging toolkit, but that's
another story I guess ...
Maarten
On 8/1/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Emmanuel, I agree. I think it would be better if MINA had more logging
that could be switched on. For example, following on from the question
Elizabeth raised, it would be nice to know when MINA is running through
codec factories etc and what is going on when it is choosing a decoder to
use.
I like slf4j (and MINA was the first time I had used it) and since commons
logging can work with slf4j I'd like to keep slf4j unless we are completely
happy that commons logging has addressed all the classloader issues and so
on.
RG
*"Emmanuel Lecharny" <[EMAIL PROTECTED]>*
01/08/2006 16:10
Please respond to mina-dev
To: [email protected]
cc:
Subject: Re: [jira] Commented: (DIRMINA-233) Provide an
extra thin logging layer for those who don't want SLF4J
Well, the question and concern should be : "why does mina log so little ?"
In my mind, logging is really a must for any product, and especially for a
framework. It helps users to understand what is happening, and also people
who maintain the code to be able to understand user's problem, just asking
them for smething more interesting and helpfull than a stacktrace.
It may be just me, but I feel that mina is not logging enough, so
targeting
a "*NO* dependency just because of this lack of logs is a way to say that
you don't need shampoo because you are bold ;)
As we say in France : "Pas de bras, pas de chocolat " ;)
PS: i'm not saying that Mina is badly written, just in case somone
misinterpreted my opinion :)
Emmanuel
On 8/1/06, Julien Vermillard (JIRA) <[EMAIL PROTECTED]> wrote:
>
> [
>
http://issues.apache.org/jira/browse/DIRMINA-233?page=comments#action_12424888
]
>
> Julien Vermillard commented on DIRMINA-233:
> -------------------------------------------
>
> +1 I agree with Peter, the usage of logging MINA do is pretty small for
> having a dependency
>
> > Provide an extra thin logging layer for those who don't want SLF4J
> > ------------------------------------------------------------------
> >
> > Key: DIRMINA-233
> > URL: http://issues.apache.org/jira/browse/DIRMINA-233
> > Project: Directory MINA
> > Issue Type: Task
> > Reporter: Trustin Lee
> >
> > As MINA gets more and more popular, the number of people who doesn't
> want SLF4J increased because they were using other logging frameworks
such
> as Log4J or commons-logging. We know SLF4J provides what exactly Log4J
or
> commons-logging provides, but it's just a matter of preference. We need
to
> meet as many people's preference as we can as a general network
application
> framework.
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see:
http://www.atlassian.com/software/jira
>
>
>
--
Cordialement,
Emmanuel Lécharny
This communication is for informational purposes only. It is not intended
as an offer or solicitation for the purchase or sale of any financial
instrument or as an official confirmation of any transaction. All market
prices, data and other information are not warranted as to completeness or
accuracy and are subject to change without notice. Any comments or
statements made herein do not necessarily reflect those of JPMorgan Chase &
Co., its subsidiaries and affiliates.
This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure under
applicable law. If you are not the intended recipient, you are hereby
notified that any disclosure, copying, distribution, or use of the
information contained herein (including any reliance thereon) is STRICTLY
PROHIBITED. Although this transmission and any attachments are believed to
be free of any virus or other defect that might affect any computer system
into which it is received and opened, it is the responsibility of the
recipient to ensure that it is virus free and no responsibility is accepted
by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for
any loss or damage arising in any way from its use. If you received this
transmission in error, please immediately contact the sender and destroy the
material in its entirety, whether in electronic or hard copy format. Thank
you.
