Re: Revisiting logging in MINA 2.0
You made many good points but I need to correct some. On Dec 18, 2007 3:51 PM, Alex Karasulu [EMAIL PROTECTED] 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,
Re: Revisiting logging in MINA 2.0
On Tue, 18 Dec 2007 13:01:40 +0900 Trustin Lee [EMAIL PROTECTED] wrote: On Dec 18, 2007 3:34 AM, Emmanuel Lecharny [EMAIL PROTECTED] 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
On Dec 18, 2007 5:38 PM, Julien Vermillard [EMAIL PROTECTED] wrote: On Tue, 18 Dec 2007 13:01:40 +0900 Trustin Lee [EMAIL PROTECTED] wrote: On Dec 18, 2007 3:34 AM, Emmanuel Lecharny [EMAIL PROTECTED] 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
On Dec 18, 2007 9:28 AM, Trustin Lee [EMAIL PROTECTED] wrote: You made many good points but I need to correct some. On Dec 18, 2007 3:51 PM, Alex Karasulu [EMAIL PROTECTED] 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
Re: Revisiting logging in MINA 2.0
On Dec 18, 2007 5:53 PM, Maarten Bosteels [EMAIL PROTECTED] wrote: On Dec 18, 2007 9:28 AM, Trustin Lee [EMAIL PROTECTED] wrote: You made many good points but I need to correct some. On Dec 18, 2007 3:51 PM, Alex Karasulu [EMAIL PROTECTED] 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.
Re: Revisiting logging in MINA 2.0
Trustin Lee wrote: On Dec 18, 2007 3:34 AM, Emmanuel Lecharny [EMAIL PROTECTED] 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
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
Trustin Lee wrote: On Dec 18, 2007 5:38 PM, Julien Vermillard [EMAIL PROTECTED] 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
On Tue, 18 Dec 2007 10:39:00 +0100 Emmanuel Lecharny [EMAIL PROTECTED] wrote: Trustin Lee wrote: On Dec 18, 2007 5:38 PM, Julien Vermillard [EMAIL PROTECTED] 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
On Tue, 18 Dec 2007 10:32:41 +0100 Emmanuel Lecharny [EMAIL PROTECTED] 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
On Dec 18, 2007 10:47 AM, Julien Vermillard [EMAIL PROTECTED] wrote: On Tue, 18 Dec 2007 10:32:41 +0100 Emmanuel Lecharny [EMAIL PROTECTED] 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
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
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
log2log (Was: Re: Revisiting logging in MINA 2.0)
On Dec 18, 2007 6:58 PM, Maarten Bosteels [EMAIL PROTECTED] wrote: On Dec 18, 2007 10:47 AM, Julien Vermillard [EMAIL PROTECTED] wrote: On Tue, 18 Dec 2007 10:32:41 +0100 Emmanuel Lecharny [EMAIL PROTECTED] 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. Well, it will also help adoption of SLF4J because the tool will provide a mean to convert Log4J code to SLF4J code. It will just give some freedom of choice. So it also can be a weapon to help SLF4J to rule the world of logging. :) Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: Revisiting logging in MINA 2.0
On Dec 18, 2007 4:47 AM, Julien Vermillard [EMAIL PROTECTED] wrote: On Tue, 18 Dec 2007 10:32:41 +0100 Emmanuel Lecharny [EMAIL PROTECTED] 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
On Tue, 18 Dec 2007 09:08:15 -0500 Alex Karasulu [EMAIL PROTECTED] wrote: On Dec 18, 2007 4:47 AM, Julien Vermillard [EMAIL PROTECTED] wrote: On Tue, 18 Dec 2007 10:32:41 +0100 Emmanuel Lecharny [EMAIL PROTECTED] 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
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 -- [EMAIL PROTECTED] - http://fotap.org/~osi smime.p7s Description: S/MIME cryptographic signature
Re: Revisiting logging in MINA 2.0
Hello all, On Dec 17, 2007 6:25 AM, Trustin Lee [EMAIL PROTECTED] wrote: Hi Maarten, On Dec 15, 2007 3:26 AM, Maarten Bosteels [EMAIL PROTECTED] wrote: about (4) : I thought the deadlock is caused by a bug in log4j (namely that it doesn't use proper synchronization) ? If that's the case I think we should not try to fix it in MINA. I think it's not really a bug of Log4J but a missing feature (i.e. reentrant logging). There are two workaround for the dead lock; one is to turn OFF logging for MINA, and the other is use a differnt appender (i.e. non-MINA-based one). The second solution might be most viable solution that causes no change in our source code. However, some built-in filters that logs messages might be used for the MINA-based appender, and the log messages logged by the filter might need to be transmitted via the MINA-based appender because it's not a critical but just informing message. So... the two workarounds I've mentioned are not likely to solve this problem perfectly. We can ask Log4J team to fix this issue and it will be fixed, but, again, considering that people wants to use the older version of Log4J or doesn't want to upgrade the Log4J due to some reason (e.g. custom patch) won't see this problem resolved in Log4J. And.. that's why I am suggesting a thin layer for logging. Suppose that the log4j team fixes this issue in their next release, then the only people who would need this thin layer are people who a) want to use a MINA based appender (which is not yet part of standard log4j as far as I know) b) AND don't want to upgrade to a newer log4j version IMO, that is a rather weak argument for resorting to our own thin layer for logging. By doing so, a user can bypass the existing logging framework to log messages from MINA itself. Of course, this doesn't necessarily mean that we will not experience dead lock or infinite recursion. However, at least we have control over such a tricky situation, and cut down unnecessary recursion. Another merit of the thin logging layer could be that it makes a JUL user doesn't need to add SLF4J JARs unnecessary. I sometime don't understand why the number of JARs are important. However, as David pointed out, it's pretty critical to the frameworks that depends on the other frameworks. For example, in the early stage of JMX integration implementation, I have used Commons BeanUtils which depends on commons logging. This meant a MiNA user who wants to use JMX integration module needs to add another JAR to his or her classpath. I agree, there are currently two logging facades that are widely used by frameworks/libraries: jakarta-commons-logging (JCL) and SLF4J. The consequence is that for any project with dependencies, there is a reasonable chance that both logging facades need to be on the classpath. But is that a problem ? Our application depends on JCL (because of spring,) and on SLF4J (because of MINA) and we let both facades point to log4j. Works pefectly. Really, I do not see the problem. Of course, I would prefer it if we would only need SLF4J, but that's a problem that MINA can not solve. I am afraid that a thin layer in MINA will just make things more complex. Could you explain a bit how that thin layer would work ? Maarten logger.info(I am NOT obsessed with logging); If he or she is using a Maven, then it also means that he or she has to add many exclusion tags to dependency section, which is pain in the butt. These thoughts lead me to think all frameworks have to: 1) provide a thin logging layer or 2) not log at all. I'd prefer the solution #1. David answered other questions pretty nicely, so that's all for me. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: Revisiting logging in MINA 2.0
On Mon, 17 Dec 2007 17:29:24 +0100 Maarten Bosteels [EMAIL PROTECTED] 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
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
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
On Dec 17, 2007 11:29 AM, Maarten Bosteels [EMAIL PROTECTED] wrote: On Dec 17, 2007 6:25 AM, Trustin Lee [EMAIL PROTECTED] 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
Hi David, On Dec 17, 2007 5:46 PM, David M. Lloyd [EMAIL PROTECTED] wrote: On Mon, 17 Dec 2007 17:29:24 +0100 Maarten Bosteels [EMAIL PROTECTED] 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
On Mon, 17 Dec 2007 20:11:20 +0100 Maarten Bosteels [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Dec 17, 2007 11:29 AM, Maarten Bosteels [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Dec 17, 2007 6:25 AM, Trustin Lee [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 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
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
On Dec 18, 2007 3:34 AM, Emmanuel Lecharny [EMAIL PROTECTED] 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
On Dec 18, 2007 3:40 AM, Alex Karasulu [EMAIL PROTECTED] wrote: On Dec 17, 2007 11:29 AM, Maarten Bosteels [EMAIL PROTECTED] wrote: On Dec 17, 2007 6:25 AM, Trustin Lee [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] wrote: On Dec 18, 2007 3:40 AM, Alex Karasulu [EMAIL PROTECTED] wrote: On Dec 17, 2007 11:29 AM, Maarten Bosteels [EMAIL PROTECTED] wrote: On Dec 17, 2007 6:25 AM, Trustin Lee [EMAIL PROTECTED] 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
Hi Maarten, On Dec 15, 2007 3:26 AM, Maarten Bosteels [EMAIL PROTECTED] wrote: about (4) : I thought the deadlock is caused by a bug in log4j (namely that it doesn't use proper synchronization) ? If that's the case I think we should not try to fix it in MINA. I think it's not really a bug of Log4J but a missing feature (i.e. reentrant logging). There are two workaround for the dead lock; one is to turn OFF logging for MINA, and the other is use a differnt appender (i.e. non-MINA-based one). The second solution might be most viable solution that causes no change in our source code. However, some built-in filters that logs messages might be used for the MINA-based appender, and the log messages logged by the filter might need to be transmitted via the MINA-based appender because it's not a critical but just informing message. So... the two workarounds I've mentioned are not likely to solve this problem perfectly. We can ask Log4J team to fix this issue and it will be fixed, but, again, considering that people wants to use the older version of Log4J or doesn't want to upgrade the Log4J due to some reason (e.g. custom patch) won't see this problem resolved in Log4J. And.. that's why I am suggesting a thin layer for logging. By doing so, a user can bypass the existing logging framework to log messages from MINA itself. Of course, this doesn't necessarily mean that we will not experience dead lock or infinite recursion. However, at least we have control over such a tricky situation, and cut down unnecessary recursion. Another merit of the thin logging layer could be that it makes a JUL user doesn't need to add SLF4J JARs unnecessary. I sometime don't understand why the number of JARs are important. However, as David pointed out, it's pretty critical to the frameworks that depends on the other frameworks. For example, in the early stage of JMX integration implementation, I have used Commons BeanUtils which depends on commons logging. This meant a MiNA user who wants to use JMX integration module needs to add another JAR to his or her classpath. If he or she is using a Maven, then it also means that he or she has to add many exclusion tags to dependency section, which is pain in the butt. These thoughts lead me to think all frameworks have to: 1) provide a thin logging layer or 2) not log at all. I'd prefer the solution #1. David answered other questions pretty nicely, so that's all for me. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: Revisiting logging in MINA 2.0
BTW I think we need something different from JarJar (http://code.google.com/p/jarjar/). We need a simple skeleton code from which a thin logging layer code is generated into the specified package (org.apache.mina.common in MINA's case). It could be reused among many frameworks including MINA. Trustin On Dec 17, 2007 2:25 PM, Trustin Lee [EMAIL PROTECTED] wrote: Hi Maarten, On Dec 15, 2007 3:26 AM, Maarten Bosteels [EMAIL PROTECTED] wrote: about (4) : I thought the deadlock is caused by a bug in log4j (namely that it doesn't use proper synchronization) ? If that's the case I think we should not try to fix it in MINA. I think it's not really a bug of Log4J but a missing feature (i.e. reentrant logging). There are two workaround for the dead lock; one is to turn OFF logging for MINA, and the other is use a differnt appender (i.e. non-MINA-based one). The second solution might be most viable solution that causes no change in our source code. However, some built-in filters that logs messages might be used for the MINA-based appender, and the log messages logged by the filter might need to be transmitted via the MINA-based appender because it's not a critical but just informing message. So... the two workarounds I've mentioned are not likely to solve this problem perfectly. We can ask Log4J team to fix this issue and it will be fixed, but, again, considering that people wants to use the older version of Log4J or doesn't want to upgrade the Log4J due to some reason (e.g. custom patch) won't see this problem resolved in Log4J. And.. that's why I am suggesting a thin layer for logging. By doing so, a user can bypass the existing logging framework to log messages from MINA itself. Of course, this doesn't necessarily mean that we will not experience dead lock or infinite recursion. However, at least we have control over such a tricky situation, and cut down unnecessary recursion. Another merit of the thin logging layer could be that it makes a JUL user doesn't need to add SLF4J JARs unnecessary. I sometime don't understand why the number of JARs are important. However, as David pointed out, it's pretty critical to the frameworks that depends on the other frameworks. For example, in the early stage of JMX integration implementation, I have used Commons BeanUtils which depends on commons logging. This meant a MiNA user who wants to use JMX integration module needs to add another JAR to his or her classpath. If he or she is using a Maven, then it also means that he or she has to add many exclusion tags to dependency section, which is pain in the butt. These thoughts lead me to think all frameworks have to: 1) provide a thin logging layer or 2) not log at all. I'd prefer the solution #1. David answered other questions pretty nicely, so that's all for me. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6 -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: Revisiting logging in MINA 2.0
On Thursday 13 December 2007 18:26:38 Trustin Lee wrote: On Dec 14, 2007 2:05 AM, Luc Willems [EMAIL PROTECTED] 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
Hello all, On Dec 13, 2007 3:50 AM, Trustin Lee [EMAIL PROTECTED] 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
On Fri, 14 Dec 2007 19:26:13 +0100 Maarten Bosteels [EMAIL PROTECTED] 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
On Dec 14, 2007 2:05 AM, Luc Willems [EMAIL PROTECTED] 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
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
On Wed, 12 Dec 2007 10:50:49 -0800 Brian McCallister [EMAIL PROTECTED] 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
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
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:[EMAIL PROTECTED] 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
On Tue, 11 Dec 2007 11:12:05 -0800 Scott Peters [EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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
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
On Tue, 11 Dec 2007 21:25:14 -0800 Cameron Taggart [EMAIL PROTECTED] 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
