Re: [general] Apache + Meritocracy [Was: [logging] logging vs slf4j]
I agree with sebb. I prefer an organization where everyone gets one vote. This is obviously not the only way an organization can run, but I like neither having a diminished or overwhelming power with my vote. The best part of having only +1 is that you can't use your merit to strong-arm decisions over anyone -- you have to build consensus using reason. If you can't convince your team, the idea isn't worth doing no matter how much more voting power you wish you had. I find this especially equitable since there can be a split of people who do the work (committers) and vote (PMC). There are some who commit only and can't vote, others do commit and vote, and others who just vote. Being on a PMC myself, I am happy my vote is equal to every one else on the committee. On Thu, Aug 11, 2011 at 7:00 AM, sebb wrote: > Why should my vote carry more weight? > > I may have created more SVN revisions than others, but I don't think > that gives my vote any more value. > > Apart from the fact that commit count has little bearing on actual > work done, and is not an indicator of quality, there are other ways of > contributing (e.g. mailing list feedback, commit review, release > testing, bug reporting) that I consider equally valuable. > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [general] Apache + Meritocracy [Was: [logging] logging vs slf4j]
On 11 August 2011 10:21, Ceki Gülcü wrote: > On 11/08/2011 8:13 AM, Henri Yandell wrote: > > >> I was going to say: "That would put Sebb in charge of the ASF!!!", but >> then I noticed that after the import of Jena Andy Seaborne appears to >> be the top count committer (I know, that doesn't measure size of >> commit). [http://svnsearch.org/svnsearch/repos/ASF/search] > > The person with the most commit points is not necessarily in > charge. Sebastian Bazley's vote would carry more weight than Henri Why should my vote carry more weight? I may have created more SVN revisions than others, but I don't think that gives my vote any more value. Apart from the fact that commit count has little bearing on actual work done, and is not an indicator of quality, there are other ways of contributing (e.g. mailing list feedback, commit review, release testing, bug reporting) that I consider equally valuable. > Yandell's or Simone Tripodi's vote, but Henri and Simone voting > together would beat Sebastian's *lone* vote every time. It's basic > arithmetic and I won't insult you with an example containing figures. > >> I think the problem with this is that it's an extremely arbitrary way >> of dealing with failure to find consensus. It's also not very >> meritocratic - it's based on what people have done and not what people >> are willing to do. The 'prove it in a branch' is more merit-based and >> less likely to result in status quo decisions. > > Yes, committocracy, i.e. decision making based on a commit point > weighted voting system, does only take into account past > contributions. Future contributions are ignored until such a time > where the future becomes the past. > >> Yup - . It's a good conversation to have had - great to hear of log4j >> 2.0 work and to have you still active in the conversation. > > Yah, it has been a good discussion. Thanks for your time and input. > > -- > Ceki > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [general] Apache + Meritocracy [Was: [logging] logging vs slf4j]
On 11/08/2011 8:13 AM, Henri Yandell wrote: I was going to say: "That would put Sebb in charge of the ASF!!!", but then I noticed that after the import of Jena Andy Seaborne appears to be the top count committer (I know, that doesn't measure size of commit). [http://svnsearch.org/svnsearch/repos/ASF/search] The person with the most commit points is not necessarily in charge. Sebastian Bazley's vote would carry more weight than Henri Yandell's or Simone Tripodi's vote, but Henri and Simone voting together would beat Sebastian's *lone* vote every time. It's basic arithmetic and I won't insult you with an example containing figures. I think the problem with this is that it's an extremely arbitrary way of dealing with failure to find consensus. It's also not very meritocratic - it's based on what people have done and not what people are willing to do. The 'prove it in a branch' is more merit-based and less likely to result in status quo decisions. Yes, committocracy, i.e. decision making based on a commit point weighted voting system, does only take into account past contributions. Future contributions are ignored until such a time where the future becomes the past. Yup - . It's a good conversation to have had - great to hear of log4j 2.0 work and to have you still active in the conversation. Yah, it has been a good discussion. Thanks for your time and input. -- Ceki - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [general] Apache + Meritocracy [Was: [logging] logging vs slf4j]
On Wed, Aug 10, 2011 at 6:06 AM, Ceki Gülcü wrote: > On 10/08/2011 8:02 AM, Henri Yandell wrote: > > > > Thank you for posting this summary of the Apache way. Yes, it is damn > hard to track contributions, especially if one wishes to do it > accurately and fairly. However, it is possible and even easy to keep > *approximate* track of contributions, e.g. via "commit points" as > described in my committocracy post. I was going to say: "That would put Sebb in charge of the ASF!!!", but then I noticed that after the import of Jena Andy Seaborne appears to be the top count committer (I know, that doesn't measure size of commit). [http://svnsearch.org/svnsearch/repos/ASF/search] I think the problem with this is that it's an extremely arbitrary way of dealing with failure to find consensus. It's also not very meritocratic - it's based on what people have done and not what people are willing to do. The 'prove it in a branch' is more merit-based and less likely to result in status quo decisions. > I quite like the consensual approach you describe. Treating others > with respect goes a long way in convincing your audience. Yes, meeting > people face to face create bonds which then help to ease > tensions. However, while the consensual approach works nicely under > many circumstances it does not always work. > > Take for example the logging issue recently discussed on this > list. Some argue in favor of adopting SLF4J, some in favor of j.u.l, > some in favor of log4j v2 and yet others wish to keep using > commons-logging. I don't see a way to reach consensus on this topic > regardless of the time and effort put into it. Creating a branch of > commons-digester using SLF4J/jul/log4jv2 will not convince anyone. Agreed - the work to move from one logger to another is presumably very easy for us. Much more of a pain for users, so I'd expect there to be resistance to change there. The interesting one will be whether a new component (or one adding logging) would hit resistance from using a different system. Some of the discussion was also not about what we should use, but whether commons-logging was done, dead etc [puts on the Attic hat]. Currently c-logging has 2 bugs fixed in trunk but no release imminent. They don't seem like trivial bugs, so I contend we should either be thinking of a release or thinking of making the component dormant. > In the current system, I would expect commons-logging to be retained > because it's the path of least action/no decision. I should mention > that not deciding can sometimes be the best decision yielding the best > results. In other words, being conservative is often OK. Yup - . It's a good conversation to have had - great to hear of log4j 2.0 work and to have you still active in the conversation. Looking at Commons, there are 17 components using c-logging (+5 in the sandbox) and 2 also using slf4j. DBCP 2.0 represents the most likely time on the horizon that a component would consider changing. > The alternative system I propose, namely committocracy, is merit-based > and where decisions can be reached in an orderly and timely fashion. > It specifically caters for cases where consensus cannot be > reached. IMO committocracy is not in contradiction with consensus > building as long as its use is restricted to special circumstances > (where consensus building has failed repeatedly). Definitely the right way to focus on it - what are the mechanisms for handling breakdown of consensus. Too often it's the loudest-wins, or the one willing to hang in the longest, or the one willing to be the most obstinate. I think committocracy is too arbitrary to be agile - it casts things in stone that the general Apache approach leaves to the social structure. In practice the respect built from historical work is more often than not the 'winning vote', we all tend to defer to those who were here before us. That gets a bit warped as people move from project to project. jim@ is a Commons committer. He made 4 commits to CLI back in 2009, but I'm still likely to listen to him above and beyond his committocracy count. I can see how that might be a good thing or a bad thing depending on situation. > Governance models are not cast in stone. The apache model will need to > improve over time or eventually become obsolete. Yup, though I think there are other areas where adaptation is more likely to be needed than this one. Whether or not we should have CLAs is one that jumps to mind. How to stop employers buying committocracy (regardless of whether we have it as an official notion or its current social notion). Patents. Decentralized development (github-like - not the source-control but the ultra-bazaar dev style). Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [general] Apache + Meritocracy [Was: [logging] logging vs slf4j]
Commits != work I'm currently in the progress of rewriting plexus-utils and other stuff from over at codehaus to be able to use an IP clean version of it for Maven again. This is needed since some folks are throwing dirt and claiming that they did most of the work, yada yada yada... Of course they had the most commits over at the codehaus SVN. But they did not say that 70% of the code did originally come from Apache Avalon (only found that out after reading Stefan Bodewigs @author tags and digged deeper). So having the most commits != having done the most work! LieGrue, strub --- On Wed, 8/10/11, Christian Grobmeier wrote: > From: Christian Grobmeier > Subject: Re: [general] Apache + Meritocracy [Was: [logging] logging vs slf4j] > To: "Commons Developers List" > Date: Wednesday, August 10, 2011, 1:47 PM > > Thank you for posting this > summary of the Apache way. Yes, it is damn > > hard to track contributions, especially if one wishes > to do it > > accurately and fairly. However, it is possible and > even easy to keep > > *approximate* track of contributions, e.g. via "commit > points" as > > described in my committocracy post. > > I hate committocracy from the bottom of my heart. I would > leave the > ASF immediately if the model would change to that. > bureaucratically open source - no thanks. > > So, why do you want to measure my coding efficiency? Not > even my Boss > (if I would have one) is allowed to do that! Commit points > measure my > coding skills probably, not my human skills. > > > Take for example the logging issue recently discussed > on this > > list. Some argue in favor of adopting SLF4J, some in > favor of j.u.l, > > some in favor of log4j v2 and yet others wish to keep > using > > commons-logging. I don't see a way to reach consensus > on this topic > > regardless of the time and effort put into it. > Creating a branch of > > commons-digester using SLF4J/jul/log4jv2 will not > convince anyone. > > > > In the current system, I would expect commons-logging > to be retained > > because it's the path of least action/no decision. I > should mention > > that not deciding can sometimes be the best decision > yielding the best > > results. In other words, being conservative is often > OK. > > There are many options. > > If it is 1:10, the 1 should think about his arguments. > If it is 5:5, people can make optional modules; or try out > which works better > At least it is possible to make branches. > And everything else which comes to your mind. > > > The alternative system I propose, namely > committocracy, is merit-based > > and where decisions can be reached in an orderly and > timely fashion. > > It specifically caters for cases where consensus > cannot be > > reached. IMO committocracy is not in contradiction > with consensus > > building as long as its use is restricted to special > circumstances > > (where consensus building has failed repeatedly). > > If you have 1 with 200 commit points, and 3 with 30 each, > then the one > is the leader/ruler. If it is to the leaders liking, then a > consens > can be found. If not, then the leader makes a decision. > This is no > consens for people on a same level. But this "same level" > is what I > like on the ASF. I am on the same level as everybody else > in this > project even when others have done so much more. > > The answer is, fellows trust me. If I vote somebody in, > because of his > merits, then the merit is not code, it is trust. You cannot > measure > trust and respect in codelines or commit messages. > > Why commitocracy? Just because I could block a decision of > my fellow? > If people are afraid that I could block decisions, then > they should > not vote me into their project. > > There is one difference between Commitocracy and > Meritocracy (as the > ASF understands it). The ASF model is around community > success, the > Commitocracy model is around software success. > > > Governance models are not cast in stone. The apache > model will need to > > improve over time or eventually become obsolete. > > As everything else in this world. At the moment I can see a > huge > number of projects coming to the ASF; a lots of new people > coming > through the incubator. I cannot say how many leave or > unsatisfied. We > would need to do an empiristic research to know that. But > at the > moment my feeling is, it works very well. > > I have read the blog post in question several times; I > simply cannot > like it, i have tried to understand everything. > Comm
Re: [general] Apache + Meritocracy [Was: [logging] logging vs slf4j]
On 10/08/2011 3:59 PM, Gary Gregory wrote: "Creating a branch of commons-digester using SLF4J/jul/log4jv2 will not convince anyone." I am sorry, but deciding for other people what they are going to think is no way to go either. Experimenting by branching is leading by example. This is a good option when a discussion on a mailing list stalls or is caught in a loop. Some people can see it all in the abstract and in words but trying code out can help everyone see an issue clearly. "Creating a branch of commons-digester using SLF4J/jul/log4jv2 will not convince anyone" because it is a trivial exercise. The sentence should *not* be generalized to all experiments and branches. It applies only to replacing one logging API with another fairly similar logging API. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [general] Apache + Meritocracy [Was: [logging] logging vs slf4j]
On 10/08/2011 3:47 PM, Christian Grobmeier wrote: So, why do you want to measure my coding efficiency? Not even my Boss (if I would have one) is allowed to do that! Commit points measure my coding skills probably, not my human skills. Commit points as described in my blog measure the number of days in which a committer made commits. The measure is independent of the value of the commits or the skills of the committer. So for a git repository, the commit points accumulated by Alice can be obtained with the following command: git log --format='%ad %an' --date=short|uniq|grep Alice|wc -l That's all there is to it. If you have 1 with 200 commit points, and 3 with 30 each, then the one is the leader/ruler. If it is to the leaders liking, then a consens can be found. If not, then the leader makes a decision. This is no consens for people on a same level. But this "same level" is what I like on the ASF. I am on the same level as everybody else in this project even when others have done so much more. Votes based on commit points are necessary only when consensus cannot be reached. The default actions is to discuss a given proposal and try to reach consensus. Only after repeated failures is a decision made by a vote weighted by commit points. The answer is, fellows trust me. If I vote somebody in, because of his merits, then the merit is not code, it is trust. You cannot measure trust and respect in codelines or commit messages. You can trust someone without systematic agreement. There are many people which I like, respect and trust without being always in agreement with them. Presumably, the same goes for most people. Committocracy addresses the situation where consensus cannot be reached. Why commitocracy? Just because I could block a decision of my fellow? If people are afraid that I could block decisions, then they should not vote me into their project. As the number of committers grow, it becomes harder and harder to reach consensus on certain divisive issues. There is one difference between Commitocracy and Meritocracy (as the ASF understands it). The ASF model is around community success, the Commitocracy model is around software success. Committocracy is essentially about community building. I don't think it makes sense to talk about a community governance model such as committocracy without the community of committers being at the center. Governance models are not cast in stone. The apache model will need to improve over time or eventually become obsolete. As everything else in this world. At the moment I can see a huge number of projects coming to the ASF; a lots of new people coming through the incubator. I cannot say how many leave or unsatisfied. We would need to do an empiristic research to know that. But at the moment my feeling is, it works very well. Indeed, evolution applies to most ecosystems. I have read the blog post in question several times; I simply cannot like it, i have tried to understand everything. Committocracy is not the answer, at least not for me. Sure. No problem. I would like to add that I have full respect to your (Cekis) ideas and if something on my post is offending then it is because I am not very good with english. I simply don't like the model, thats all :-) No worries. Cheers, Christian -- Ceki - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [general] Apache + Meritocracy [Was: [logging] logging vs slf4j]
On Wed, Aug 10, 2011 at 9:06 AM, Ceki Gülcü wrote: > On 10/08/2011 8:02 AM, Henri Yandell wrote: >> >> On Tue, Aug 9, 2011 at 10:16 AM, Ceki Gulcu wrote: >> >>> * On the ASF model >>> >>> In a nutshell, while the ASF is a great organization in many ways, it >>> is not a meritocracy mainly because merit is not measured at all and >>> at the project level no responsiblity is accrued on merit beyond >>> committership. BTW, the BDFL model is not a meritocracy >>> either. Finding a good model for running organisations is no simple >>> matter. The Apache model may even be better than some but it bothers >>> me that the ASF misrepresents itself as a meritocracy. >> >> Yup. >> >> Damn... should probably say more. >> >> It tries to be meritocratic for adding committers. It's damn hard to >> track how much someone is contributing sometimes. I wrote a JIRA >> Contributions report that I like a lot - with each release I look and >> see who was involved in the release and whether anyone who is a >> non-committer stands out as having done a chunk. >> >> Beyond that it's mostly peer/respect driven. Getting to be a member is >> based on respect of peers; leading to new groups having low members >> while the culture overlaps with the new group. >> >> Discussions are still meritocratic, in that they favour those prepared >> to do the work, but that's only at the meme level and not in any of >> the actual methods; meaning you have to be pretty obstinate to push >> past that inactive committer -1. The loose meme is that inactive >> should only be casting -0 and +0. >> >> Getting your way (per se) in discussions is also peer/respect driven; >> meaning you have to expend energy on convincing others rather than >> coding. An annoying drag on your time to code. There are culture memes >> that can lessen that, but they're not well communicated. >> >> Rules for Revolutionaries is definitely the best, though I rarely seem >> to see it actually documented for a project. We don't have a rule for >> revolutionary change for example. I spent lots of time trying to >> convince people that we should do a JDK 1.5 Lang; then realized I >> should just start on a branch (or trunk; I forget which). >> >> So here's our Commons Rules for Revolutionaries: >> >> * Give heads up. Make a branch and JFDI. Then discuss. >> ** Subnote. If not a Commons committer; then discuss making a >> sandbox branch, make a branch and JFDI. >> *** Subsubnote. If not an Apache committer; make a github fork or >> svn copy, JFDI and discuss. >> >> Maybe that will help someone in the future :) I always wonder if that >> would have helped in log4j. >> >> End of ramble :) >> >> It does worry me, the balance between innovation and stability (rules >> for revs), and the interaction of lots of skilled people. On the >> latter the meme is "Go to ApacheCon". Meet someone face to face and >> much of the irritation that can build up fades away. > > > > Thank you for posting this summary of the Apache way. Yes, it is damn > hard to track contributions, especially if one wishes to do it > accurately and fairly. However, it is possible and even easy to keep > *approximate* track of contributions, e.g. via "commit points" as > described in my committocracy post. > > I quite like the consensual approach you describe. Treating others > with respect goes a long way in convincing your audience. Yes, meeting > people face to face create bonds which then help to ease > tensions. However, while the consensual approach works nicely under > many circumstances it does not always work. > > Take for example the logging issue recently discussed on this > list. Some argue in favor of adopting SLF4J, some in favor of j.u.l, > some in favor of log4j v2 and yet others wish to keep using > commons-logging. I don't see a way to reach consensus on this topic > regardless of the time and effort put into it. Creating a branch of > commons-digester using SLF4J/jul/log4jv2 will not convince anyone. "Creating a branch of commons-digester using SLF4J/jul/log4jv2 will not convince anyone." I am sorry, but deciding for other people what they are going to think is no way to go either. Experimenting by branching is leading by example. This is a good option when a discussion on a mailing list stalls or is caught in a loop. Some people can see it all in the abstract and in words but trying code out can help everyone see an issue clearly. Cheers, Gary > > In the current system, I would expect commons-logging to be retained > because it's the path of least action/no decision. I should mention > that not deciding can sometimes be the best decision yielding the best > results. In other words, being conservative is often OK. > > The alternative system I propose, namely committocracy, is merit-based > and where decisions can be reached in an orderly and timely fashion. > It specifically caters for cases where consensus cannot be > reached. IMO committocracy is not in contradiction with consensus > buildin
Re: [general] Apache + Meritocracy [Was: [logging] logging vs slf4j]
> Thank you for posting this summary of the Apache way. Yes, it is damn > hard to track contributions, especially if one wishes to do it > accurately and fairly. However, it is possible and even easy to keep > *approximate* track of contributions, e.g. via "commit points" as > described in my committocracy post. I hate committocracy from the bottom of my heart. I would leave the ASF immediately if the model would change to that. bureaucratically open source - no thanks. So, why do you want to measure my coding efficiency? Not even my Boss (if I would have one) is allowed to do that! Commit points measure my coding skills probably, not my human skills. > Take for example the logging issue recently discussed on this > list. Some argue in favor of adopting SLF4J, some in favor of j.u.l, > some in favor of log4j v2 and yet others wish to keep using > commons-logging. I don't see a way to reach consensus on this topic > regardless of the time and effort put into it. Creating a branch of > commons-digester using SLF4J/jul/log4jv2 will not convince anyone. > > In the current system, I would expect commons-logging to be retained > because it's the path of least action/no decision. I should mention > that not deciding can sometimes be the best decision yielding the best > results. In other words, being conservative is often OK. There are many options. If it is 1:10, the 1 should think about his arguments. If it is 5:5, people can make optional modules; or try out which works better At least it is possible to make branches. And everything else which comes to your mind. > The alternative system I propose, namely committocracy, is merit-based > and where decisions can be reached in an orderly and timely fashion. > It specifically caters for cases where consensus cannot be > reached. IMO committocracy is not in contradiction with consensus > building as long as its use is restricted to special circumstances > (where consensus building has failed repeatedly). If you have 1 with 200 commit points, and 3 with 30 each, then the one is the leader/ruler. If it is to the leaders liking, then a consens can be found. If not, then the leader makes a decision. This is no consens for people on a same level. But this "same level" is what I like on the ASF. I am on the same level as everybody else in this project even when others have done so much more. The answer is, fellows trust me. If I vote somebody in, because of his merits, then the merit is not code, it is trust. You cannot measure trust and respect in codelines or commit messages. Why commitocracy? Just because I could block a decision of my fellow? If people are afraid that I could block decisions, then they should not vote me into their project. There is one difference between Commitocracy and Meritocracy (as the ASF understands it). The ASF model is around community success, the Commitocracy model is around software success. > Governance models are not cast in stone. The apache model will need to > improve over time or eventually become obsolete. As everything else in this world. At the moment I can see a huge number of projects coming to the ASF; a lots of new people coming through the incubator. I cannot say how many leave or unsatisfied. We would need to do an empiristic research to know that. But at the moment my feeling is, it works very well. I have read the blog post in question several times; I simply cannot like it, i have tried to understand everything. Committocracy is not the answer, at least not for me. I would like to add that I have full respect to your (Cekis) ideas and if something on my post is offending then it is because I am not very good with english. I simply don't like the model, thats all :-) Cheers, Christian > > > >> Hen > > -- > Ceki > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- http://www.grobmeier.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [general] Apache + Meritocracy [Was: [logging] logging vs slf4j]
On 10/08/2011 8:02 AM, Henri Yandell wrote: On Tue, Aug 9, 2011 at 10:16 AM, Ceki Gulcu wrote: * On the ASF model In a nutshell, while the ASF is a great organization in many ways, it is not a meritocracy mainly because merit is not measured at all and at the project level no responsiblity is accrued on merit beyond committership. BTW, the BDFL model is not a meritocracy either. Finding a good model for running organisations is no simple matter. The Apache model may even be better than some but it bothers me that the ASF misrepresents itself as a meritocracy. Yup. Damn... should probably say more. It tries to be meritocratic for adding committers. It's damn hard to track how much someone is contributing sometimes. I wrote a JIRA Contributions report that I like a lot - with each release I look and see who was involved in the release and whether anyone who is a non-committer stands out as having done a chunk. Beyond that it's mostly peer/respect driven. Getting to be a member is based on respect of peers; leading to new groups having low members while the culture overlaps with the new group. Discussions are still meritocratic, in that they favour those prepared to do the work, but that's only at the meme level and not in any of the actual methods; meaning you have to be pretty obstinate to push past that inactive committer -1. The loose meme is that inactive should only be casting -0 and +0. Getting your way (per se) in discussions is also peer/respect driven; meaning you have to expend energy on convincing others rather than coding. An annoying drag on your time to code. There are culture memes that can lessen that, but they're not well communicated. Rules for Revolutionaries is definitely the best, though I rarely seem to see it actually documented for a project. We don't have a rule for revolutionary change for example. I spent lots of time trying to convince people that we should do a JDK 1.5 Lang; then realized I should just start on a branch (or trunk; I forget which). So here's our Commons Rules for Revolutionaries: * Give heads up. Make a branch and JFDI. Then discuss. ** Subnote. If not a Commons committer; then discuss making a sandbox branch, make a branch and JFDI. *** Subsubnote. If not an Apache committer; make a github fork or svn copy, JFDI and discuss. Maybe that will help someone in the future :) I always wonder if that would have helped in log4j. End of ramble :) It does worry me, the balance between innovation and stability (rules for revs), and the interaction of lots of skilled people. On the latter the meme is "Go to ApacheCon". Meet someone face to face and much of the irritation that can build up fades away. Thank you for posting this summary of the Apache way. Yes, it is damn hard to track contributions, especially if one wishes to do it accurately and fairly. However, it is possible and even easy to keep *approximate* track of contributions, e.g. via "commit points" as described in my committocracy post. I quite like the consensual approach you describe. Treating others with respect goes a long way in convincing your audience. Yes, meeting people face to face create bonds which then help to ease tensions. However, while the consensual approach works nicely under many circumstances it does not always work. Take for example the logging issue recently discussed on this list. Some argue in favor of adopting SLF4J, some in favor of j.u.l, some in favor of log4j v2 and yet others wish to keep using commons-logging. I don't see a way to reach consensus on this topic regardless of the time and effort put into it. Creating a branch of commons-digester using SLF4J/jul/log4jv2 will not convince anyone. In the current system, I would expect commons-logging to be retained because it's the path of least action/no decision. I should mention that not deciding can sometimes be the best decision yielding the best results. In other words, being conservative is often OK. The alternative system I propose, namely committocracy, is merit-based and where decisions can be reached in an orderly and timely fashion. It specifically caters for cases where consensus cannot be reached. IMO committocracy is not in contradiction with consensus building as long as its use is restricted to special circumstances (where consensus building has failed repeatedly). Governance models are not cast in stone. The apache model will need to improve over time or eventually become obsolete. Hen -- Ceki - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
+1 as well. That's the path I advocated for Configuration 2.0, combined with the log4j bridge from Paul Smith [1] Maybe we should stop spending our energy on alternative logging frameworks and try to improve the standard one in the JDK instead. I have been told that Java was open source now, so let's contribute ! Emmanuel Bourg [1] http://people.apache.org/~psmith/logging.apache.org/sandbox/jul-log4j-bridge/examples.html Le 07/08/2011 10:31, Jochen Wiedmann a écrit : On Wed, Aug 3, 2011 at 3:02 PM, Gary Gregory wrote: Or maybe Log4j 2 could replace [logging]. If we really have to reconsider this stuff, then I'd propose to a) Use java.util.logging, because it doesn't require any additional dependencies and is guaranteed to work anywhere. b) Carefully document how to bridge jul to log4j, because that's exactly what's required in almost any application container I am aware of. (The exception being Tomcat, which uses jul anyways.) c) If the slf4j fans insist, add similar documentation for bridging jul to slf4j. Jochen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[general] Apache + Meritocracy [Was: [logging] logging vs slf4j]
On Tue, Aug 9, 2011 at 10:16 AM, Ceki Gulcu wrote: > * On the ASF model > > In a nutshell, while the ASF is a great organization in many ways, it > is not a meritocracy mainly because merit is not measured at all and > at the project level no responsiblity is accrued on merit beyond > committership. BTW, the BDFL model is not a meritocracy > either. Finding a good model for running organisations is no simple > matter. The Apache model may even be better than some but it bothers > me that the ASF misrepresents itself as a meritocracy. Yup. Damn... should probably say more. It tries to be meritocratic for adding committers. It's damn hard to track how much someone is contributing sometimes. I wrote a JIRA Contributions report that I like a lot - with each release I look and see who was involved in the release and whether anyone who is a non-committer stands out as having done a chunk. Beyond that it's mostly peer/respect driven. Getting to be a member is based on respect of peers; leading to new groups having low members while the culture overlaps with the new group. Discussions are still meritocratic, in that they favour those prepared to do the work, but that's only at the meme level and not in any of the actual methods; meaning you have to be pretty obstinate to push past that inactive committer -1. The loose meme is that inactive should only be casting -0 and +0. Getting your way (per se) in discussions is also peer/respect driven; meaning you have to expend energy on convincing others rather than coding. An annoying drag on your time to code. There are culture memes that can lessen that, but they're not well communicated. Rules for Revolutionaries is definitely the best, though I rarely seem to see it actually documented for a project. We don't have a rule for revolutionary change for example. I spent lots of time trying to convince people that we should do a JDK 1.5 Lang; then realized I should just start on a branch (or trunk; I forget which). So here's our Commons Rules for Revolutionaries: * Give heads up. Make a branch and JFDI. Then discuss. ** Subnote. If not a Commons committer; then discuss making a sandbox branch, make a branch and JFDI. *** Subsubnote. If not an Apache committer; make a github fork or svn copy, JFDI and discuss. Maybe that will help someone in the future :) I always wonder if that would have helped in log4j. End of ramble :) It does worry me, the balance between innovation and stability (rules for revs), and the interaction of lots of skilled people. On the latter the meme is "Go to ApacheCon". Meet someone face to face and much of the irritation that can build up fades away. Looking forward to meeting many of you at ApacheCon Vancouver :) Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
Hi all guys!!! sorry for joining so late the discussion (working on some stuff as bricklayer at home!!! didn't know it is fun!) * I don't understand why JULI should be so "complicated" to be adopted... if in trouble, please take a look at juli-to-log4j[1] bride written by our ASF mate Paul Smith. I'm a big fan on Google Guice and I tend to write my tasks on work on top of JSR330 using it - it relies 100% on JULI for logging, when/if something goes wrong, I just hijack the logging to log4j or logback. done. And believe me, if I can do it, everybody can. * given the previous fact, the proposed facade by slf4j reminds me what we could already do using JULI and related bridges - please correct me if I'm wrong, I'm sure there are missing features I'm not aware, but I could bridge JULI to logback as well - and if omitting the -Djava.util.logging.manager=org.apache.logging.julbridge.JULBridgeLogManager is a so huge difference, I missed something * Ceki, you can't immagine how much I have to be thankful to you!!! :) I strongly respect you, your POV and what you've been doing, but I hope there will be the chance to bring you back to the ASF :) Have a nice day, all the best!!! Simo [1] http://people.apache.org/~psmith/logging.apache.org/sandbox/jul-log4j-bridge/ http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Aug 9, 2011 at 7:16 PM, Ceki Gulcu wrote: > On 09.08.2011 11:57, Christian Grobmeier wrote: Another option is to try to work with Ceki to address some of the concerns of the commons community with regards to using slf4j. * There is a hassle with too many jars for dependencies with slf4j. * Every time Ceki goes on vacation everything stops. * Some have a preference for Apache driven projects. * Figuring out the dependencies that are needed can be difficult. >>> >>> Another option would be to try to convince Ceki to move his project to >>> the ASF? He is an ASF member, right? What were his concerns about >>> the ASF that made him start his project elsewhere? >> >> Ceki is an ASF member and even a Logging PMC. >> You can read most about his concerns on his blog, for example: >> http://ceki.blogspot.com/2010/05/forces-and-vulnerabilites-of-apache.html >> http://ceki.blogspot.com/2010/05/committocracy-as-alternative-for.html >> >> He seems to be very opposed to the ASF model; there was much bad >> feelings in the "log4j case" before I started with logging and >> therefore I doubt that Ceki is willing to go back to the ASF. At least >> his blogposts reflect that he is not satisfied with the "Apache Way" >> itself instead of personal trouble, which we might be able to solve. >> Ceki is reading this list, so maybe he wants to elaborate a bit more. > > * On the ASF model > > In a nutshell, while the ASF is a great organization in many ways, it > is not a meritocracy mainly because merit is not measured at all and > at the project level no responsiblity is accrued on merit beyond > committership. BTW, the BDFL model is not a meritocracy > either. Finding a good model for running organisations is no simple > matter. The Apache model may even be better than some but it bothers > me that the ASF misrepresents itself as a meritocracy. > > * On logging > > One of the disadvantages of a relatively large and open ecosystem such > as Java is that you get several competing libraries solving common > problems. Logging is a rather devisive case in point. > > SLF4J has deficiences with regards to modularity are imho testimony to > the lack of a widely accepted solution to modularity in Java. In any > case, I am unaware of a satisfactory solution. OSGi is of course one > possible approach but OSGi is a complex beast and not that widely > accepted (yet). > > As for deficiences in SLF4J API, varargs support [1] and event data > support come to mind. Varargs support is very likely to be added in > SLF4J 2.0. As for event data support mentioned by Ralph, the idea was > initially proposed by Joern Huxhorn. I am not entirely convinced by > it. > > However, Ralph is right to observe that had SLF4J been developped at > the ASF and that Ralph, Joern and me were the only SLF4J > developpers, event data support would probably be part of the SLF4J > API. Having said that, since event data support is a little > controversial, it might have been turned down at the ASF as well > (assuming the involvement of more developpers who shared my lack of > enthusiams for event data). > > Anyway, Ralph made some very valuable contributiuons to the logback > project and I am sorry to see him stop. Given what I have seen of his > work, he will surely do an excellent job with log4j v2. > > [1] http://bugzilla.slf4j.org/show_bug.cgi?id=31 > > -- > Ceki > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > ---
Re: [logging] logging vs slf4j
On 09.08.2011 11:57, Christian Grobmeier wrote: Another option is to try to work with Ceki to address some of the concerns of the commons community with regards to using slf4j. * There is a hassle with too many jars for dependencies with slf4j. * Every time Ceki goes on vacation everything stops. * Some have a preference for Apache driven projects. * Figuring out the dependencies that are needed can be difficult. Another option would be to try to convince Ceki to move his project to the ASF? He is an ASF member, right? What were his concerns about the ASF that made him start his project elsewhere? Ceki is an ASF member and even a Logging PMC. You can read most about his concerns on his blog, for example: http://ceki.blogspot.com/2010/05/forces-and-vulnerabilites-of-apache.html http://ceki.blogspot.com/2010/05/committocracy-as-alternative-for.html He seems to be very opposed to the ASF model; there was much bad feelings in the "log4j case" before I started with logging and therefore I doubt that Ceki is willing to go back to the ASF. At least his blogposts reflect that he is not satisfied with the "Apache Way" itself instead of personal trouble, which we might be able to solve. Ceki is reading this list, so maybe he wants to elaborate a bit more. * On the ASF model In a nutshell, while the ASF is a great organization in many ways, it is not a meritocracy mainly because merit is not measured at all and at the project level no responsiblity is accrued on merit beyond committership. BTW, the BDFL model is not a meritocracy either. Finding a good model for running organisations is no simple matter. The Apache model may even be better than some but it bothers me that the ASF misrepresents itself as a meritocracy. * On logging One of the disadvantages of a relatively large and open ecosystem such as Java is that you get several competing libraries solving common problems. Logging is a rather devisive case in point. SLF4J has deficiences with regards to modularity are imho testimony to the lack of a widely accepted solution to modularity in Java. In any case, I am unaware of a satisfactory solution. OSGi is of course one possible approach but OSGi is a complex beast and not that widely accepted (yet). As for deficiences in SLF4J API, varargs support [1] and event data support come to mind. Varargs support is very likely to be added in SLF4J 2.0. As for event data support mentioned by Ralph, the idea was initially proposed by Joern Huxhorn. I am not entirely convinced by it. However, Ralph is right to observe that had SLF4J been developped at the ASF and that Ralph, Joern and me were the only SLF4J developpers, event data support would probably be part of the SLF4J API. Having said that, since event data support is a little controversial, it might have been turned down at the ASF as well (assuming the involvement of more developpers who shared my lack of enthusiams for event data). Anyway, Ralph made some very valuable contributiuons to the logback project and I am sorry to see him stop. Given what I have seen of his work, he will surely do an excellent job with log4j v2. [1] http://bugzilla.slf4j.org/show_bug.cgi?id=31 -- Ceki - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On Tue, Aug 9, 2011 at 5:57 AM, Christian Grobmeier wrote: >>> Another option is to try to work with Ceki to address some of the >>> concerns of the commons community with regards to using slf4j. >>> >>> * There is a hassle with too many jars for dependencies with slf4j. >>> * Every time Ceki goes on vacation everything stops. >>> * Some have a preference for Apache driven projects. >>> * Figuring out the dependencies that are needed can be difficult. >> >> Another option would be to try to convince Ceki to move his project to >> the ASF? He is an ASF member, right? What were his concerns about >> the ASF that made him start his project elsewhere? > > Ceki is an ASF member and even a Logging PMC. > You can read most about his concerns on his blog, for example: > http://ceki.blogspot.com/2010/05/forces-and-vulnerabilites-of-apache.html > http://ceki.blogspot.com/2010/05/committocracy-as-alternative-for.html > > He seems to be very opposed to the ASF model; there was much bad > feelings in the "log4j case" before I started with logging and > therefore I doubt that Ceki is willing to go back to the ASF. At least > his blogposts reflect that he is not satisfied with the "Apache Way" > itself instead of personal trouble, which we might be able to solve. > Ceki is reading this list, so maybe he wants to elaborate a bit more. > > The logback project is not satisfying me as a developer. I am at the > ASF because I like the way it is. I like the software. And of course I > like the way the work is done here and finally I like the license. > > logback/slf4j is going another way. It does not have the license, and > holidays seem to be very important to the project. > > We, the ASF, have really good software in our repositories. We have > very competent people around. Why do we discuss to move to > slf4j/logback - now? The last time we discussed this there was less > activity on logging. Now there is activity on the logging project at > apache. There is Ralph and some other people doing lots of work for > log4j2. > We have learned there are some people who want commons-logging. We > have learned in Tomcat are some people who created classloader > workarounds and know about the case and could help with it. > > It feels wrong to me to move away to slf4j/logback with Commons at > this point of time. We would kill the new growing dynamics of logging. > Instead we should use the new interest and try to work together on the > new log4j/commons-logging. Over at logging we welcome new fresh blood. > > After all, even log4j 1.2.x is not bad software. I use it daily; i > have not missed the features of logback (parametrized messages, > Markers etc.) so far. I put log4j in my class path, copy over one of > my fave configuration, ready. No need to waste any more time to this. > log4j is still good and at the moment I don't see a reason to move on. > > In the commons-logging case, if the commons-* projects stop using > commons-logging, then commons-logging feels pretty dead. > > So my preference is: > > - Help Ralph to make log4j 2.0 become truth > - Update commons-logging, make it work with log4j 2.0 > - Try to make log4j 2.0 become compatible with slf4j +1 > > If one of you is interested in helping with log4j, please subscribe to > log4j-...@logging.apache.org Done. Nice message Christian. Gary > > Cheers > Christian > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
>> Another option is to try to work with Ceki to address some of the >> concerns of the commons community with regards to using slf4j. >> >> * There is a hassle with too many jars for dependencies with slf4j. >> * Every time Ceki goes on vacation everything stops. >> * Some have a preference for Apache driven projects. >> * Figuring out the dependencies that are needed can be difficult. > > Another option would be to try to convince Ceki to move his project to > the ASF? He is an ASF member, right? What were his concerns about > the ASF that made him start his project elsewhere? Ceki is an ASF member and even a Logging PMC. You can read most about his concerns on his blog, for example: http://ceki.blogspot.com/2010/05/forces-and-vulnerabilites-of-apache.html http://ceki.blogspot.com/2010/05/committocracy-as-alternative-for.html He seems to be very opposed to the ASF model; there was much bad feelings in the "log4j case" before I started with logging and therefore I doubt that Ceki is willing to go back to the ASF. At least his blogposts reflect that he is not satisfied with the "Apache Way" itself instead of personal trouble, which we might be able to solve. Ceki is reading this list, so maybe he wants to elaborate a bit more. The logback project is not satisfying me as a developer. I am at the ASF because I like the way it is. I like the software. And of course I like the way the work is done here and finally I like the license. logback/slf4j is going another way. It does not have the license, and holidays seem to be very important to the project. We, the ASF, have really good software in our repositories. We have very competent people around. Why do we discuss to move to slf4j/logback - now? The last time we discussed this there was less activity on logging. Now there is activity on the logging project at apache. There is Ralph and some other people doing lots of work for log4j2. We have learned there are some people who want commons-logging. We have learned in Tomcat are some people who created classloader workarounds and know about the case and could help with it. It feels wrong to me to move away to slf4j/logback with Commons at this point of time. We would kill the new growing dynamics of logging. Instead we should use the new interest and try to work together on the new log4j/commons-logging. Over at logging we welcome new fresh blood. After all, even log4j 1.2.x is not bad software. I use it daily; i have not missed the features of logback (parametrized messages, Markers etc.) so far. I put log4j in my class path, copy over one of my fave configuration, ready. No need to waste any more time to this. log4j is still good and at the moment I don't see a reason to move on. In the commons-logging case, if the commons-* projects stop using commons-logging, then commons-logging feels pretty dead. So my preference is: - Help Ralph to make log4j 2.0 become truth - Update commons-logging, make it work with log4j 2.0 - Try to make log4j 2.0 become compatible with slf4j If one of you is interested in helping with log4j, please subscribe to log4j-...@logging.apache.org Cheers Christian - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
A few comments on the list of points against slf4j below... On 08/08/2011 05:58 PM, Elijah Zupancic wrote: > From what I can tell from the thread, here are the following points > against SLF4J: > > * Log4j developer V2 would like to see the Apache community support > the project rather than putting resources into slf4j. Keep in mind that slf4j is not a logging framework -- it is only a facade that provides: 1) an API 2) (optional) bridges from jul, jcl, log4j to a target framework of choice I think there may be some confusion with Logback. Logback is the logging framework created by Ceki that *implements* the slf4j API, but is a separate project and using slf4j creates no dependency on Logback. > * Slf4j apparently has some deficiencies in its API such as: "SLF4J > has to convert the EventData object to XML since SLF4J/Logback don't > provide a good way of handling this." If this is truly an API deficiency (i.e. SLF4J, not logback), then AFAICT every other current logging API has the same deficiency, including log4j, jul and jcl -- since they are all pretty similar. IOW, very few users will care. > * Log4j V2 also implements support for the Slf4j API. Great. This is an advantage of coding commons components against slf4j since both logback and log4j v2 can both be used out of the box with a native implementation of the slf4j api. > * There is a hassle with too many jars for dependencies with slf4j. I addressed this previously. There is no alternative solution that is simpler. If jul had been implemented as an API (like slf4j) then we'd only need one jar. Alas... > * Every time Ceki goes on vacation everything stops. Again, we are talking about an API. It rarely changes. There is little reason for it too change, and many reasons for it not to change. > * Some have a preference for Apache driven projects. OK. > * Figuring out the dependencies that are needed can be difficult. It's actually really simple. Far and away simpler than commons-logging. For writing a library, you need one jar: slf4j-api.jar. That's it. For developing an application, here are the dependencies in a nutshell. This should cover every common situation. Pick your desired situation, and put the jars specified on your classpath - done. 1) I want all log statements to go to log4j v1: slf4j-log4j12.jar log4j.jar 2) I want all log statements to go to log4j v2: log4jv2.jar (the above is a guess based on your statement that log4j v2 implements the slf4j-api) 3) I want all log statements to go to logback: logback-core.jar logback-classic.jar (optional) logback-access.jar (if logging web access logs) 4) I want all log statements to go to jul: slf4j-jdk14.jar 5) I want all log statements to go to jcl: slf4j-jcl.jar For *all* of the above, add: slf4j-api.jar (optional) jul-to-slf4j.jar (if using libs that call jul) (optional) jcl-over-slf4j.jar (if using libs that call jcl) JCL only supports option #1 and #4 (I think) and uses one less jar in those cases. > If we can come to some consensus regarding this issues, then I think > there will be more traction toward Slf4j. Cool. Given the above list, I don't really see any issue with coding commons projects against the slf4j api. Except perhaps the "it's not made here" thing. If that is a problem, then as I said JCL is fine and easily bridged to slf4j and thence to any desired framework. Cheers, Raman - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On Mon, Aug 8, 2011 at 5:58 PM, Elijah Zupancic wrote: > > Another option is to try to work with Ceki to address some of the > concerns of the commons community with regards to using slf4j. > > * There is a hassle with too many jars for dependencies with slf4j. > * Every time Ceki goes on vacation everything stops. > * Some have a preference for Apache driven projects. > * Figuring out the dependencies that are needed can be difficult. Another option would be to try to convince Ceki to move his project to the ASF? He is an ASF member, right? What were his concerns about the ASF that made him start his project elsewhere? - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
OK. Note that -- in a similar vein to what you proposed -- I'm also fine with simply keeping commons-logging as is. The really nice thing about commons-logging is that it is based on an API (like SLF4j but unlike jul!). Therefore, it is really easy for people to do whatever they want -- e.g. for people who use slf4j, we simply ignore commons-logging.jar and drop in jcl-over-slf4j.jar instead which implements the same jcl API. The main annoyance is with dependency managers that don't understand the equivalency and therefore resolve commons-logging.jar, requiring explicit excludes. This is a manageable problem though. Cheers, Raman On 08/08/2011 05:58 PM, Elijah Zupancic wrote: > Raman, > > You may have proposed this earlier in the thread and I didn't catch > it. I actually like your suggestion the best, but it seems like it is > a difficult sell for a lot of people to compile against the slf4j API > for a variety of reasons that are not strictly code related. > > My suggestion was intended to bridge the gap between the concerns > toward compiling directly against slf4j. > > Another option is to try to work with Ceki to address some of the > concerns of the commons community with regards to using slf4j. > > From what I can tell from the thread, here are the following points > against SLF4J: > > * Log4j developer V2 would like to see the Apache community support > the project rather than putting resources into slf4j. > * Slf4j apparently has some deficiencies in its API such as: "SLF4J > has to convert the EventData object to XML since SLF4J/Logback don't > provide a good way of handling this." > * Log4j V2 also implements support for the Slf4j API. > * There is a hassle with too many jars for dependencies with slf4j. > * Every time Ceki goes on vacation everything stops. > * Some have a preference for Apache driven projects. > * Figuring out the dependencies that are needed can be difficult. > > If we can come to some consensus regarding this issues, then I think > there will be more traction toward Slf4j. > > Thanks, > -Elijah > > On Mon, Aug 8, 2011 at 2:13 PM, Raman Gupta wrote: >> On 08/08/2011 04:56 PM, Elijah Zupancic wrote: >>> This could be done by choosing (dynamically or by configuration) the >>> logger implementation log4j / commons / slf4j / jul and then loading >>> the LoggerFactory into a wrapper class that is then called used by the >>> Commons project. >>> >>> We would then make the logger implementations a compile-time >>> dependency only and relay upon the consumer to provide them. >>> >>> I do realize that this is essentially doing a Facade on top of a >>> Facade, but it solves the problem for consumers of the library by >>> providing many options. >>> >>> So, am I crazy? >> >> If I understand you correctly, you would have this dependency chain: >> >> random-commons-project -> >> commons-logging-wrapper -> >>API like slf4j or logging implementation (at runtime) >> >> Plus commons-logging-wrapper requires compile-time knowledge of all >> possible target frameworks, since it is not coding to an API. >> >> Can you explain the advantage over simply coding >> random-commons-project against slf4j-api.jar? Then, you have this >> dependency chain: >> >> random-commons-project -> >> slf4j-api -> >>logging implementation (at runtime) >> >> And anyone can create their own slf4j compatible logging >> implementation simply by implementing the slf4j api and dropping their >> jar into their environment. >> >> Cheers, >> Raman >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
Raman, You may have proposed this earlier in the thread and I didn't catch it. I actually like your suggestion the best, but it seems like it is a difficult sell for a lot of people to compile against the slf4j API for a variety of reasons that are not strictly code related. My suggestion was intended to bridge the gap between the concerns toward compiling directly against slf4j. Another option is to try to work with Ceki to address some of the concerns of the commons community with regards to using slf4j. >From what I can tell from the thread, here are the following points against SLF4J: * Log4j developer V2 would like to see the Apache community support the project rather than putting resources into slf4j. * Slf4j apparently has some deficiencies in its API such as: "SLF4J has to convert the EventData object to XML since SLF4J/Logback don't provide a good way of handling this." * Log4j V2 also implements support for the Slf4j API. * There is a hassle with too many jars for dependencies with slf4j. * Every time Ceki goes on vacation everything stops. * Some have a preference for Apache driven projects. * Figuring out the dependencies that are needed can be difficult. If we can come to some consensus regarding this issues, then I think there will be more traction toward Slf4j. Thanks, -Elijah On Mon, Aug 8, 2011 at 2:13 PM, Raman Gupta wrote: > On 08/08/2011 04:56 PM, Elijah Zupancic wrote: >> This could be done by choosing (dynamically or by configuration) the >> logger implementation log4j / commons / slf4j / jul and then loading >> the LoggerFactory into a wrapper class that is then called used by the >> Commons project. >> >> We would then make the logger implementations a compile-time >> dependency only and relay upon the consumer to provide them. >> >> I do realize that this is essentially doing a Facade on top of a >> Facade, but it solves the problem for consumers of the library by >> providing many options. >> >> So, am I crazy? > > If I understand you correctly, you would have this dependency chain: > > random-commons-project -> > commons-logging-wrapper -> > API like slf4j or logging implementation (at runtime) > > Plus commons-logging-wrapper requires compile-time knowledge of all > possible target frameworks, since it is not coding to an API. > > Can you explain the advantage over simply coding > random-commons-project against slf4j-api.jar? Then, you have this > dependency chain: > > random-commons-project -> > slf4j-api -> > logging implementation (at runtime) > > And anyone can create their own slf4j compatible logging > implementation simply by implementing the slf4j api and dropping their > jar into their environment. > > Cheers, > Raman > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On 08/08/2011 04:56 PM, Elijah Zupancic wrote: > This could be done by choosing (dynamically or by configuration) the > logger implementation log4j / commons / slf4j / jul and then loading > the LoggerFactory into a wrapper class that is then called used by the > Commons project. > > We would then make the logger implementations a compile-time > dependency only and relay upon the consumer to provide them. > > I do realize that this is essentially doing a Facade on top of a > Facade, but it solves the problem for consumers of the library by > providing many options. > > So, am I crazy? If I understand you correctly, you would have this dependency chain: random-commons-project -> commons-logging-wrapper -> API like slf4j or logging implementation (at runtime) Plus commons-logging-wrapper requires compile-time knowledge of all possible target frameworks, since it is not coding to an API. Can you explain the advantage over simply coding random-commons-project against slf4j-api.jar? Then, you have this dependency chain: random-commons-project -> slf4j-api -> logging implementation (at runtime) And anyone can create their own slf4j compatible logging implementation simply by implementing the slf4j api and dropping their jar into their environment. Cheers, Raman - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
> The biggest issue I have with SLF4J is figuring out the dependencies > that I need. I really detest having an API jar and then an > implementation/bridge jar. I find that too annoying. I cannot see how that is annoying. It's simple and it works. What's annoying you about this? - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
I agree with this sentiment. In the last 3 years all of the large commercial projects that I have worked on used slf4j just for the very reason that I needed to bridge the logging implementations in multiple third-party libraries. While reading this thread, one approach occurs to me that hasn't been mentioned. Why not abstract the abstraction? My gut reaction to this approach is negative, but I do feel that it is quite pragmatic. This could be done by choosing (dynamically or by configuration) the logger implementation log4j / commons / slf4j / jul and then loading the LoggerFactory into a wrapper class that is then called used by the Commons project. We would then make the logger implementations a compile-time dependency only and relay upon the consumer to provide them. I do realize that this is essentially doing a Facade on top of a Facade, but it solves the problem for consumers of the library by providing many options. So, am I crazy? -Elijah > Yes, the reality is large applications need to support multiple source > frameworks and will therefore require a bunch of logging jars. Slf4j > provides a relatively simple path to consolidating logs from jcl, jul, > and log4j into one's chosen target framework (except for jul). > > With the current landscape, you are dreaming if you think one magical > jar is going to support all use cases. This would have been simple if > jul had been designed properly, but it wasn't. > > Cheers, > Raman - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On 08/08/2011 03:28 PM, Matt Benson wrote: > On Mon, Aug 8, 2011 at 2:23 PM, Paul Benedict wrote: >> On Mon, Aug 8, 2011 at 2:03 PM, Raman Gupta wrote: >>> Perhaps I'm missing something, but what exactly is wrong with simply >>> using slf4j? It is an extremely simple, widely used library that >>> provides out of the box hooks for many logging frameworks including >>> log4j and logback, simple to configure (i.e. drop the appropriate jars >>> in and thats it), and works out of the box in an OSGi environment? The >>> only downside appears to be that it is not an Apache project. So what. >> >> The biggest issue I have with SLF4J is figuring out the dependencies >> that I need. I really detest having an API jar and then an >> implementation/bridge jar. I find that too annoying. This is nothing new -- commons-logging requires the commons-logging.jar for library creators, and users need commons-logging.jar plus an implementation jar. Slf4j requires the same: slf4j-api.jar for library creators and an implementation jar for users. The bridging jars are *optional* and only required by users to bridge from jcl, jul, or log4j. > In fairness, using a dependency manager with support for transitive > dependencies you should only have to specify the implementation jar. > In the case of slf4j you may have to provide multiple jars (impl + > bridge X n logging frameworks in use throughout your application), > however. Of course, log4j v2 will have to support this paradigm in > some fashion or lose runtime "market share" due to slf4j's ability to > cater to the "lowest common denominator." Yes, the reality is large applications need to support multiple source frameworks and will therefore require a bunch of logging jars. Slf4j provides a relatively simple path to consolidating logs from jcl, jul, and log4j into one's chosen target framework (except for jul). With the current landscape, you are dreaming if you think one magical jar is going to support all use cases. This would have been simple if jul had been designed properly, but it wasn't. Cheers, Raman - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On Mon, Aug 8, 2011 at 3:28 PM, Matt Benson wrote: > On Mon, Aug 8, 2011 at 2:23 PM, Paul Benedict wrote: >> On Mon, Aug 8, 2011 at 2:03 PM, Raman Gupta wrote: >>> Perhaps I'm missing something, but what exactly is wrong with simply >>> using slf4j? It is an extremely simple, widely used library that >>> provides out of the box hooks for many logging frameworks including >>> log4j and logback, simple to configure (i.e. drop the appropriate jars >>> in and thats it), and works out of the box in an OSGi environment? The >>> only downside appears to be that it is not an Apache project. So what. >> >> The biggest issue I have with SLF4J is figuring out the dependencies >> that I need. I really detest having an API jar and then an >> implementation/bridge jar. I find that too annoying. >> > > In fairness, using a dependency manager with support for transitive > dependencies you should only have to specify the implementation jar. > In the case of slf4j you may have to provide multiple jars (impl + > bridge X n logging frameworks in use throughout your application), > however. Of course, log4j v2 will have to support this paradigm in > some fashion or lose runtime "market share" due to slf4j's ability to > cater to the "lowest common denominator." Even if I Iived in OSGi-land, I'd want one jar/bundle/file. Slicing and dicing in such a minute way seems like a lot of noise. If I were programming for a light bulb, I might care about how big my jars get, but I do not, so I won't ;) Gary > > Matt > >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On Mon, Aug 8, 2011 at 3:23 PM, Paul Benedict wrote: > On Mon, Aug 8, 2011 at 2:03 PM, Raman Gupta wrote: >> Perhaps I'm missing something, but what exactly is wrong with simply >> using slf4j? It is an extremely simple, widely used library that >> provides out of the box hooks for many logging frameworks including >> log4j and logback, simple to configure (i.e. drop the appropriate jars >> in and thats it), and works out of the box in an OSGi environment? The >> only downside appears to be that it is not an Apache project. So what. > > The biggest issue I have with SLF4J is figuring out the dependencies > that I need. I really detest having an API jar and then an > implementation/bridge jar. I find that too annoying. +1 on that. Give me one jar. Convenience please. Gary > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On Mon, Aug 8, 2011 at 2:23 PM, Paul Benedict wrote: > On Mon, Aug 8, 2011 at 2:03 PM, Raman Gupta wrote: >> Perhaps I'm missing something, but what exactly is wrong with simply >> using slf4j? It is an extremely simple, widely used library that >> provides out of the box hooks for many logging frameworks including >> log4j and logback, simple to configure (i.e. drop the appropriate jars >> in and thats it), and works out of the box in an OSGi environment? The >> only downside appears to be that it is not an Apache project. So what. > > The biggest issue I have with SLF4J is figuring out the dependencies > that I need. I really detest having an API jar and then an > implementation/bridge jar. I find that too annoying. > In fairness, using a dependency manager with support for transitive dependencies you should only have to specify the implementation jar. In the case of slf4j you may have to provide multiple jars (impl + bridge X n logging frameworks in use throughout your application), however. Of course, log4j v2 will have to support this paradigm in some fashion or lose runtime "market share" due to slf4j's ability to cater to the "lowest common denominator." Matt > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On Mon, Aug 8, 2011 at 2:03 PM, Raman Gupta wrote: > Perhaps I'm missing something, but what exactly is wrong with simply > using slf4j? It is an extremely simple, widely used library that > provides out of the box hooks for many logging frameworks including > log4j and logback, simple to configure (i.e. drop the appropriate jars > in and thats it), and works out of the box in an OSGi environment? The > only downside appears to be that it is not an Apache project. So what. The biggest issue I have with SLF4J is figuring out the dependencies that I need. I really detest having an API jar and then an implementation/bridge jar. I find that too annoying. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On 08/08/2011 02:00 PM, ralph.goers @dslextreme.com wrote: > On Mon, Aug 8, 2011 at 8:06 AM, Simone Tripodi > wrote: If we really have to reconsider this stuff, then I'd propose to a) Use java.util.logging, because it doesn't require any additional dependencies and is guaranteed to work anywhere. b) Carefully document how to bridge jul to log4j, because that's exactly what's required in almost any application container I am aware of. (The exception being Tomcat, which uses jul anyways.) c) If the slf4j fans insist, add similar documentation for bridging jul to slf4j. >>> >>> +1. I like this plan. >>> >> >> +1 I like this plan too. it sounds *very* reasonable: unified, >> standard (?) way to log, easy to bridge to everything needed. >> can we ask more? >> have a nice day, all the best!!! >> Simo > > I'm not a fan of this plan. Have you actually tried to "bridge" jul to > anything? While it will work anywhere that doesn't imply it will work > properly. > > Ralph I'm not a fan of this plan either. Jul bridging is not simple because JUL doesn't provide the necessary hooks, and packages under the java.* namespace can't be replaced. For example, see this slf4j page: http://www.slf4j.org/legacy.html To quote one relevant sentence: "...Consequently, j.u.l. to SLF4J translation can seriously impact on the cost of disabled logging statements (60 fold increase) and a measurable impact on enabled log statements (20% overall increase)." Logging to Logback via slf4j does provide a work-around to the above performance problem (LevelChangePropagator) but other frameworks may not (log4j?), and in general configuring the JUL bridge is much harder than it should be, and many users will get it wrong. Other frameworks may have similar issues bridging JUL as well. Perhaps I'm missing something, but what exactly is wrong with simply using slf4j? It is an extremely simple, widely used library that provides out of the box hooks for many logging frameworks including log4j and logback, simple to configure (i.e. drop the appropriate jars in and thats it), and works out of the box in an OSGi environment? The only downside appears to be that it is not an Apache project. So what. Cheers, Raman - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
I'm not a fan of this plan. Have you actually tried to "bridge" jul to anything? While it will work anywhere that doesn't imply it will work properly. Ralph On Mon, Aug 8, 2011 at 8:06 AM, Simone Tripodi wrote: > Hi all, > > >> > >> If we really have to reconsider this stuff, then I'd propose to > >> > >> a) Use java.util.logging, because it doesn't require any additional > >> dependencies and is guaranteed to work anywhere. > >> b) Carefully document how to bridge jul to log4j, because that's > >> exactly what's required in almost any application container I am aware > >> of. (The exception being Tomcat, which uses jul anyways.) > >> c) If the slf4j fans insist, add similar documentation for bridging > >> jul to slf4j. > > > > +1. I like this plan. > > > > +1 I like this plan too. it sounds *very* reasonable: unified, > standard (?) way to log, easy to bridge to everything needed. > can we ask more? > have a nice day, all the best!!! > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [logging] logging vs slf4j
Hi all, >> >> If we really have to reconsider this stuff, then I'd propose to >> >> a) Use java.util.logging, because it doesn't require any additional >> dependencies and is guaranteed to work anywhere. >> b) Carefully document how to bridge jul to log4j, because that's >> exactly what's required in almost any application container I am aware >> of. (The exception being Tomcat, which uses jul anyways.) >> c) If the slf4j fans insist, add similar documentation for bridging >> jul to slf4j. > > +1. I like this plan. > +1 I like this plan too. it sounds *very* reasonable: unified, standard (?) way to log, easy to bridge to everything needed. can we ask more? have a nice day, all the best!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
Hi Mark! Exactly the classloader problem is what we try to solve in log4j-2.0. Tomcat is by far not the only project which suffers a lot from this shortcoming. OpenWebBeans, MyFaces, OpenJPA, etc - all projects which are usually in a shared classpath have the problem that they cannot cleanly use static Loggers in their classes. Plus jul is _not_ Serializable. With jul, you have to add 20++ lines of code to every class just to fix the most fundamental functionality fixed. In this terms jul is a single big mess... LieGrue, strub --- On Sun, 8/7/11, Mark Thomas wrote: > From: Mark Thomas > Subject: Re: [logging] logging vs slf4j > To: "Commons Developers List" > Date: Sunday, August 7, 2011, 9:57 AM > On 07/08/2011 09:31, Jochen Wiedmann > wrote: > > On Wed, Aug 3, 2011 at 3:02 PM, Gary Gregory > wrote: > > > >> Or maybe Log4j 2 could replace [logging]. > > > > If we really have to reconsider this stuff, then I'd > propose to > > > > a) Use java.util.logging, because it doesn't require > any additional > > dependencies and is guaranteed to work anywhere. > > b) Carefully document how to bridge jul to log4j, > because that's > > exactly what's required in almost any application > container I am aware > > of. (The exception being Tomcat, which uses jul > anyways.) > > c) If the slf4j fans insist, add similar documentation > for bridging > > jul to slf4j. > > +1. I like this plan. > > As an aside, Tomcat doesn't use jul, it uses JULI which is > a modified > commons logging implementation hard coded to output to jul > by default > with an alternative Jar that is hard-coded for log4j. Why > the > complexity? jul is not class loader aware which is a > problem as soon as > web applications start declaring loggers with the same > name. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
2011/8/7 Mark Thomas : > On 07/08/2011 09:31, Jochen Wiedmann wrote: >> On Wed, Aug 3, 2011 at 3:02 PM, Gary Gregory wrote: >> >>> Or maybe Log4j 2 could replace [logging]. >> >> If we really have to reconsider this stuff, then I'd propose to >> >> a) Use java.util.logging, because it doesn't require any additional >> dependencies and is guaranteed to work anywhere. >> b) Carefully document how to bridge jul to log4j, because that's >> exactly what's required in almost any application container I am aware >> of. (The exception being Tomcat, which uses jul anyways.) >> c) If the slf4j fans insist, add similar documentation for bridging >> jul to slf4j. > > +1. I like this plan. > > As an aside, Tomcat doesn't use jul, it uses JULI which is a modified > commons logging implementation hard coded to output to jul by default > with an alternative Jar that is hard-coded for log4j. Why the > complexity? jul is not class loader aware which is a problem as soon as > web applications start declaring loggers with the same name. > > Mark Regarding Tomcat, I want to correct Mark. Tomcat JULI != commons-logging. It is just that two components are packed in the same jar. (E.g. in Tomcat 5.5 they were separate). Tomcat logging (the "bin/tomcat-juli.jar:" file) contains the following: 1. Tomcat JULI which are additional components to java.util.logging. There are two main components: a) a custom implementation of java.util.logging.LogManager that is classloader-aware, allows to have separate logging configuration per webapp, and also to have more rich configurations than the default LogManager b) a custom FileHandler, that is better suited to our needs than the standard one. Tomcat JULI is enabled by setting certain java properties on the command line. 2. A copy of commons-logging renamed to a different package to avoid conflicts with webapp-provided copies of the library. The "tomcat-juli.jar:" can come in two flavors. Default one: The default one uses stripped down copy of commons-logging that has its discovery process removed and is hardcoded to use java.util.logging. Extras one: This includes full copy of commons-logging. It is *not* hard-coded for log4j. It is just that its discovery process is kept intact, so it can choose whatever logging framework it finds. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On 07/08/2011 09:31, Jochen Wiedmann wrote: > On Wed, Aug 3, 2011 at 3:02 PM, Gary Gregory wrote: > >> Or maybe Log4j 2 could replace [logging]. > > If we really have to reconsider this stuff, then I'd propose to > > a) Use java.util.logging, because it doesn't require any additional > dependencies and is guaranteed to work anywhere. > b) Carefully document how to bridge jul to log4j, because that's > exactly what's required in almost any application container I am aware > of. (The exception being Tomcat, which uses jul anyways.) > c) If the slf4j fans insist, add similar documentation for bridging > jul to slf4j. +1. I like this plan. As an aside, Tomcat doesn't use jul, it uses JULI which is a modified commons logging implementation hard coded to output to jul by default with an alternative Jar that is hard-coded for log4j. Why the complexity? jul is not class loader aware which is a problem as soon as web applications start declaring loggers with the same name. Mark - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On Wed, Aug 3, 2011 at 3:02 PM, Gary Gregory wrote: > Or maybe Log4j 2 could replace [logging]. If we really have to reconsider this stuff, then I'd propose to a) Use java.util.logging, because it doesn't require any additional dependencies and is guaranteed to work anywhere. b) Carefully document how to bridge jul to log4j, because that's exactly what's required in almost any application container I am aware of. (The exception being Tomcat, which uses jul anyways.) c) If the slf4j fans insist, add similar documentation for bridging jul to slf4j. Jochen -- Capitalism is the astounding belief that the most wickedest of men will do the most wickedest of things for the greatest good of everyone. John Maynard Keynes (http://en.wikiquote.org/wiki/Keynes) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On Fri, Aug 5, 2011 at 4:07 PM, Gary Gregory wrote: > On Aug 5, 2011, at 16:27, Phil Steitz wrote: > >> On 8/5/11 12:53 PM, Henri Yandell wrote: >>> HttpComponents would be SFL4j in my structure. They definitely need >>> debugging. >>> >>> Lang or Codec don't. >>> >>> If I had to generalize, I'd say it's because HttpComponents is not at >>> the bottom of its stack. You need to know what the communication is >>> between HttpComponents and the API below it (ie) a http connection to >>> a server). >>> >>> Digester and DBCP are two other areas in which logging is very >>> attractive (how is it talking to the XML or a DB). >>> >>> Pool less so imo - what you really want is status information on the >>> state of the pool. Ideally we're talking event-based systems and >>> querying rather than just simple logging [not that I've looked at Pool >>> in eons]. >> >> I see [pool] and [dbcp] as having similar needs. Could be good JMX >> instrumentation can do it all. Needs from the client perspective >> are to be able to query the state of the pool and be notified or >> provide a log of events of interest. In the case of [pool], most >> events of interest involve the factory, so the workaround up to now >> has been to add needed capabilities to the factory. >> >> I don't get why we should abandon [logging] in favor of a non-ASF, >> BDFL-esque thingy if [logging] works as a bridge. > > +1 Looking forward to Logging 1.1.2 being released :) Hen [Grim Reaper, Janitor, Mr Attic etc etc] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On Aug 5, 2011, at 16:27, Phil Steitz wrote: > On 8/5/11 12:53 PM, Henri Yandell wrote: >> HttpComponents would be SFL4j in my structure. They definitely need >> debugging. >> >> Lang or Codec don't. >> >> If I had to generalize, I'd say it's because HttpComponents is not at >> the bottom of its stack. You need to know what the communication is >> between HttpComponents and the API below it (ie) a http connection to >> a server). >> >> Digester and DBCP are two other areas in which logging is very >> attractive (how is it talking to the XML or a DB). >> >> Pool less so imo - what you really want is status information on the >> state of the pool. Ideally we're talking event-based systems and >> querying rather than just simple logging [not that I've looked at Pool >> in eons]. > > I see [pool] and [dbcp] as having similar needs. Could be good JMX > instrumentation can do it all. Needs from the client perspective > are to be able to query the state of the pool and be notified or > provide a log of events of interest. In the case of [pool], most > events of interest involve the factory, so the workaround up to now > has been to add needed capabilities to the factory. > > I don't get why we should abandon [logging] in favor of a non-ASF, > BDFL-esque thingy if [logging] works as a bridge. +1 Gary > What I am not > sure about for [pool] and [dbcp] is if JMX instrumentation and some > other API improvements might just meet the need without introducing > logging at all. > > I think we are conflating two different topics on this thread - 1) > future of [logging] 2) what commons components should use for > logging. Unless [logging] has terrible flaws that somehow fixed in > the SF thing, we should use it, IMO. > > Phil >> >> It's a set of decisions you have to make - what I'm advocating (with >> 'if you can help it') is to ask yourself "do I need logging?" rather >> than "how can I add logging?". I think a lot is added due to the >> latter approach. >> >> Hen >> >> On Fri, Aug 5, 2011 at 5:23 AM, Bill Speirs wrote: >>> IMO, saying "Don't do logging in a library" seems like a bad rule. >>> >>> The HTTPComponents client has logging and it has been VERY helpful to be >>> able to turn on debug logging and see what requests and responses are going >>> over the wire. Yes, I could fire up Wireshark and get the same info, but >>> turning on logging is so much easier... I only wish they had this for the >>> HttpCore stuff. >>> >>> Why do you suggest no logging for libraries? >>> >>> Bill- >>> >>> On Aug 5, 2011 2:19 AM, "Henri Yandell" wrote: On Wed, Aug 3, 2011 at 7:51 AM, Gary Gregory >>> wrote: > On Wed, Aug 3, 2011 at 10:33 AM, Paul Benedict >>> wrote: >> I prefer Apache driven projects when possible. If LOG4J2 takes off, >> feature requests would be implemented quicker, I hope. > I like Log4J just fine thank you very much :) > > I'm looking forward to 2.0. That's generally where I am thought-wise. A) If you're a generic reusble library; don't do logging if you can help >>> it. B) If you are an app, use log4j. C) If you truly need a bridge, use SLF4j. Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On 05/08/2011 9:53 PM, Henri Yandell wrote: It's a set of decisions you have to make - what I'm advocating (with 'if you can help it') is to ask yourself "do I need logging?" rather than "how can I add logging?". I think a lot is added due to the latter approach. +1 Hen -- Ceki - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On 8/5/11 12:53 PM, Henri Yandell wrote: > HttpComponents would be SFL4j in my structure. They definitely need debugging. > > Lang or Codec don't. > > If I had to generalize, I'd say it's because HttpComponents is not at > the bottom of its stack. You need to know what the communication is > between HttpComponents and the API below it (ie) a http connection to > a server). > > Digester and DBCP are two other areas in which logging is very > attractive (how is it talking to the XML or a DB). > > Pool less so imo - what you really want is status information on the > state of the pool. Ideally we're talking event-based systems and > querying rather than just simple logging [not that I've looked at Pool > in eons]. I see [pool] and [dbcp] as having similar needs. Could be good JMX instrumentation can do it all. Needs from the client perspective are to be able to query the state of the pool and be notified or provide a log of events of interest. In the case of [pool], most events of interest involve the factory, so the workaround up to now has been to add needed capabilities to the factory. I don't get why we should abandon [logging] in favor of a non-ASF, BDFL-esque thingy if [logging] works as a bridge. What I am not sure about for [pool] and [dbcp] is if JMX instrumentation and some other API improvements might just meet the need without introducing logging at all. I think we are conflating two different topics on this thread - 1) future of [logging] 2) what commons components should use for logging. Unless [logging] has terrible flaws that somehow fixed in the SF thing, we should use it, IMO. Phil > > It's a set of decisions you have to make - what I'm advocating (with > 'if you can help it') is to ask yourself "do I need logging?" rather > than "how can I add logging?". I think a lot is added due to the > latter approach. > > Hen > > On Fri, Aug 5, 2011 at 5:23 AM, Bill Speirs wrote: >> IMO, saying "Don't do logging in a library" seems like a bad rule. >> >> The HTTPComponents client has logging and it has been VERY helpful to be >> able to turn on debug logging and see what requests and responses are going >> over the wire. Yes, I could fire up Wireshark and get the same info, but >> turning on logging is so much easier... I only wish they had this for the >> HttpCore stuff. >> >> Why do you suggest no logging for libraries? >> >> Bill- >> >> On Aug 5, 2011 2:19 AM, "Henri Yandell" wrote: >>> On Wed, Aug 3, 2011 at 7:51 AM, Gary Gregory >> wrote: On Wed, Aug 3, 2011 at 10:33 AM, Paul Benedict >> wrote: > I prefer Apache driven projects when possible. If LOG4J2 takes off, > feature requests would be implemented quicker, I hope. I like Log4J just fine thank you very much :) I'm looking forward to 2.0. >>> That's generally where I am thought-wise. >>> >>> A) If you're a generic reusble library; don't do logging if you can help >> it. >>> B) If you are an app, use log4j. >>> C) If you truly need a bridge, use SLF4j. >>> >>> Hen >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
HttpComponents would be SFL4j in my structure. They definitely need debugging. Lang or Codec don't. If I had to generalize, I'd say it's because HttpComponents is not at the bottom of its stack. You need to know what the communication is between HttpComponents and the API below it (ie) a http connection to a server). Digester and DBCP are two other areas in which logging is very attractive (how is it talking to the XML or a DB). Pool less so imo - what you really want is status information on the state of the pool. Ideally we're talking event-based systems and querying rather than just simple logging [not that I've looked at Pool in eons]. It's a set of decisions you have to make - what I'm advocating (with 'if you can help it') is to ask yourself "do I need logging?" rather than "how can I add logging?". I think a lot is added due to the latter approach. Hen On Fri, Aug 5, 2011 at 5:23 AM, Bill Speirs wrote: > IMO, saying "Don't do logging in a library" seems like a bad rule. > > The HTTPComponents client has logging and it has been VERY helpful to be > able to turn on debug logging and see what requests and responses are going > over the wire. Yes, I could fire up Wireshark and get the same info, but > turning on logging is so much easier... I only wish they had this for the > HttpCore stuff. > > Why do you suggest no logging for libraries? > > Bill- > > On Aug 5, 2011 2:19 AM, "Henri Yandell" wrote: >> On Wed, Aug 3, 2011 at 7:51 AM, Gary Gregory > wrote: >>> On Wed, Aug 3, 2011 at 10:33 AM, Paul Benedict > wrote: I prefer Apache driven projects when possible. If LOG4J2 takes off, feature requests would be implemented quicker, I hope. >>> >>> I like Log4J just fine thank you very much :) >>> >>> I'm looking forward to 2.0. >> >> That's generally where I am thought-wise. >> >> A) If you're a generic reusble library; don't do logging if you can help > it. >> B) If you are an app, use log4j. >> C) If you truly need a bridge, use SLF4j. >> >> Hen >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On Fri, Aug 5, 2011 at 8:59 AM, Gary Gregory wrote: > On Fri, Aug 5, 2011 at 8:23 AM, Bill Speirs wrote: >> IMO, saying "Don't do logging in a library" seems like a bad rule. >> >> The HTTPComponents client has logging and it has been VERY helpful to be >> able to turn on debug logging and see what requests and responses are going >> over the wire. Yes, I could fire up Wireshark and get the same info, but >> turning on logging is so much easier... I only wish they had this for the >> HttpCore stuff. >> >> Why do you suggest no logging for libraries? > > Yes, IMO the question should be: How and when do you do logging in a library? > > - if () System.out... > - // System.out... > - A logging lib > - ... For example, in [codec] trunk, the new BM encoder uses "// System.out" (yuck), which then causes PMD warnings because some blocks are empty. Gary > > Gary > >> >> Bill- >> >> On Aug 5, 2011 2:19 AM, "Henri Yandell" wrote: >>> On Wed, Aug 3, 2011 at 7:51 AM, Gary Gregory >> wrote: On Wed, Aug 3, 2011 at 10:33 AM, Paul Benedict >> wrote: > I prefer Apache driven projects when possible. If LOG4J2 takes off, > feature requests would be implemented quicker, I hope. I like Log4J just fine thank you very much :) I'm looking forward to 2.0. >>> >>> That's generally where I am thought-wise. >>> >>> A) If you're a generic reusble library; don't do logging if you can help >> it. >>> B) If you are an app, use log4j. >>> C) If you truly need a bridge, use SLF4j. >>> >>> Hen >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> > > > > -- > Thank you, > Gary > > http://garygregory.wordpress.com/ > http://garygregory.com/ > http://people.apache.org/~ggregory/ > http://twitter.com/GaryGregory > -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On Fri, Aug 5, 2011 at 8:23 AM, Bill Speirs wrote: > IMO, saying "Don't do logging in a library" seems like a bad rule. > > The HTTPComponents client has logging and it has been VERY helpful to be > able to turn on debug logging and see what requests and responses are going > over the wire. Yes, I could fire up Wireshark and get the same info, but > turning on logging is so much easier... I only wish they had this for the > HttpCore stuff. > > Why do you suggest no logging for libraries? Yes, IMO the question should be: How and when do you do logging in a library? - if () System.out... - // System.out... - A logging lib - ... Gary > > Bill- > > On Aug 5, 2011 2:19 AM, "Henri Yandell" wrote: >> On Wed, Aug 3, 2011 at 7:51 AM, Gary Gregory > wrote: >>> On Wed, Aug 3, 2011 at 10:33 AM, Paul Benedict > wrote: I prefer Apache driven projects when possible. If LOG4J2 takes off, feature requests would be implemented quicker, I hope. >>> >>> I like Log4J just fine thank you very much :) >>> >>> I'm looking forward to 2.0. >> >> That's generally where I am thought-wise. >> >> A) If you're a generic reusble library; don't do logging if you can help > it. >> B) If you are an app, use log4j. >> C) If you truly need a bridge, use SLF4j. >> >> Hen >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
IMO, saying "Don't do logging in a library" seems like a bad rule. The HTTPComponents client has logging and it has been VERY helpful to be able to turn on debug logging and see what requests and responses are going over the wire. Yes, I could fire up Wireshark and get the same info, but turning on logging is so much easier... I only wish they had this for the HttpCore stuff. Why do you suggest no logging for libraries? Bill- On Aug 5, 2011 2:19 AM, "Henri Yandell" wrote: > On Wed, Aug 3, 2011 at 7:51 AM, Gary Gregory wrote: >> On Wed, Aug 3, 2011 at 10:33 AM, Paul Benedict wrote: >>> I prefer Apache driven projects when possible. If LOG4J2 takes off, >>> feature requests would be implemented quicker, I hope. >> >> I like Log4J just fine thank you very much :) >> >> I'm looking forward to 2.0. > > That's generally where I am thought-wise. > > A) If you're a generic reusble library; don't do logging if you can help it. > B) If you are an app, use log4j. > C) If you truly need a bridge, use SLF4j. > > Hen > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org >
Re: [logging] logging vs slf4j
Well said Hen, big +1 :) > > B) If you are an app, use log4j. or logback, depending on the cases, IMHO > Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Fri, Aug 5, 2011 at 8:18 AM, Henri Yandell wrote: > On Wed, Aug 3, 2011 at 7:51 AM, Gary Gregory wrote: >> On Wed, Aug 3, 2011 at 10:33 AM, Paul Benedict wrote: >>> I prefer Apache driven projects when possible. If LOG4J2 takes off, >>> feature requests would be implemented quicker, I hope. >> >> I like Log4J just fine thank you very much :) >> >> I'm looking forward to 2.0. > > That's generally where I am thought-wise. > > A) If you're a generic reusble library; don't do logging if you can help it. > B) If you are an app, use log4j. > C) If you truly need a bridge, use SLF4j. > > Hen > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On Wed, Aug 3, 2011 at 7:51 AM, Gary Gregory wrote: > On Wed, Aug 3, 2011 at 10:33 AM, Paul Benedict wrote: >> I prefer Apache driven projects when possible. If LOG4J2 takes off, >> feature requests would be implemented quicker, I hope. > > I like Log4J just fine thank you very much :) > > I'm looking forward to 2.0. That's generally where I am thought-wise. A) If you're a generic reusble library; don't do logging if you can help it. B) If you are an app, use log4j. C) If you truly need a bridge, use SLF4j. Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
2011/8/4 Ralph Goers > The flaw would be in JBoss Portal, not the portlet spec. The spec doesn't > have anything to do with logging. > In fact I would have said "a library in general" that is referenced both in the portal application and in portlets. Anyway you're right, if JBPortal would have shaded the logging framework, the problem would disappear. Antonio
Re: [logging] logging vs slf4j
The flaw would be in JBoss Portal, not the portlet spec. The spec doesn't have anything to do with logging. Ralph On Aug 3, 2011, at 11:18 AM, Antonio Petrelli wrote: > 2011/8/3 Antonio Petrelli > >> However in my experience SLF4J has a big drawback: when used in a shared >> classloader (JBoss Portal anyone?) it is needed to have the same stinky old >> version of SLF4J in all applications during compile time, and the library >> should be excluded from the package. >> > > Correcting myself, this is a flaw in JBoss Portal and/or the portlet > specification, because they need a shared classloader to work, the same > problem would happen using commons-logging. > > Antonio - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
2011/8/3 Antonio Petrelli > However in my experience SLF4J has a big drawback: when used in a shared > classloader (JBoss Portal anyone?) it is needed to have the same stinky old > version of SLF4J in all applications during compile time, and the library > should be excluded from the package. > Correcting myself, this is a flaw in JBoss Portal and/or the portlet specification, because they need a shared classloader to work, the same problem would happen using commons-logging. Antonio
Re: [logging] logging vs slf4j
Hi Ceki 2011/8/3 Ceki Gülcü > Antonio Petrelli wrote: > On the other hand, the version of slf4j binding that you select at > runtime needs to match the slf4j-api. For example, if you have > slf4j-api-1.6.1.jar on your classpath and you wish to use log4j, then > you need slf4j-log4j12-1.6.1.jar on your class path, > slf4j-log4j12-1.4.3.jar will not work. > I think this is the JBoss Portal case, in which slf4j 1.4.3 (both api and binding) is installed and all the portlets are forced to use it. So I think it is a problem with JBoss and JBoss Portal, or even portlet specification itself that are flawed. However the main difference between SLF4J and JCL is that JCL is stuck to 1.1.1 so there is less opportunity for a version mismatch :-D Thanks, I will reply to my own email in the Commons ML about it. Antonio
Re: [logging] logging vs slf4j
Antonio Petrelli wrote: > However in my experience SLF4J has a big drawback: when used in a > shared classloader (JBoss Portal anyone?) it is needed to have the > same stinky old version of SLF4J in all applications during compile > time, and the library should be excluded from the package. Hello Antonio, Since version 1.0 released about 5 years ago, all versions of SLF4J are compile-time compatible. For example, you can compile code with slf4j-api version 1.4.3 and run it just fine with any other version of slf4j-api, including 1.0.x, 1.1.x, 1.2.x, 1.3.x, 1.4.x., 1.5.x and 1.6.x. On the other hand, the version of slf4j binding that you select at runtime needs to match the slf4j-api. For example, if you have slf4j-api-1.6.1.jar on your classpath and you wish to use log4j, then you need slf4j-log4j12-1.6.1.jar on your class path, slf4j-log4j12-1.4.3.jar will not work. HTH, -- QOS.ch, main sponsor of cal10n, logback and slf4j open source projects, is looking to hire talented software developers. For further details, see http://logback.qos.ch/job.html - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
Paul, > BTW, in terms of swelling community development, if LOG4J+JCL were to > merge and just become JCL2, it could have the visibility of all > Commons committers. Isn't it much more of a common component than a > separate project? I think the logging project is dysfunctional anyway > -- make it a common component if possible. in logging.apache.org are other sub projects doing similar stuff, like log4php, log4c and such. In addition there is the companions subproject. And there is some activity in the logging project. We have had a new addition to the PMC recently and log4php has released a new version before a short while. Together with the log4j2 efforts and the efforts put from time to time into cmpanions and chainsaw, I would say the project is a bit silent, but not dead. If you take out log4j, everything else in logging would become instable. > > Paul > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- http://www.grobmeier.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
First of all, sorry to jump in at this point of the discussion. 2011/7/28 Simone Tripodi > Hi all guys, > I remember I raw a thread - not sure if I did it here at commons or > somewhere else here at apache - where specified we prefer adding > [logging] as components dependency instead of slf4j... > Did I just get crazy or someone can point me to the right direction please? > :) > I think that we should start from the fact that many application developers use Log4j 1.2 for their purposes, simply because it is *enough* configurable and *enough* useful. Sincerely I think that we don't need anything more than what Log4j 1.2 already provides. And I don't think that j.u.logging is useful enough, the configuration is simply not there. Stated this, obviously it is out of the question to adopt Log4j, simply because Commons is made of libraries, and other libraries use other logging frameworks. So we need a wrapper. I would choose SLF4J for a simple consideration: there is a Commons Logging substitute in SLF4J (jcl-over-slf4j) but not a SLF4J substitute in Commons Logging. >From a Maven perspective, If Commons Logging is chosen, when a common library is included, SLF4J users must exclude commons-logging dependency to add jcl-over-slf4j, for all libraries. However in my experience SLF4J has a big drawback: when used in a shared classloader (JBoss Portal anyone?) it is needed to have the same stinky old version of SLF4J in all applications during compile time, and the library should be excluded from the package. Antonio P.S. The world was better when there was only Log4j :-D
Re: [logging] logging vs slf4j
On Wed, Aug 3, 2011 at 9:51 AM, Gary Gregory wrote: > > I like Log4J just fine thank you very much :) > > I'm looking forward to 2.0. > > Gary > I concur with Gary. All my apps use LOG4J, not JCL or SLF4J. My dependencies do, however, but LOG4J works great minus a few enhancements I'd like to see. BTW, in terms of swelling community development, if LOG4J+JCL were to merge and just become JCL2, it could have the visibility of all Commons committers. Isn't it much more of a common component than a separate project? I think the logging project is dysfunctional anyway -- make it a common component if possible. Paul - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On Wed, Aug 3, 2011 at 10:33 AM, Paul Benedict wrote: > I prefer Apache driven projects when possible. If LOG4J2 takes off, > feature requests would be implemented quicker, I hope. I like Log4J just fine thank you very much :) I'm looking forward to 2.0. Gary > > On Wed, Aug 3, 2011 at 9:27 AM, Ralph Goers > wrote: >> >> On Aug 3, 2011, at 6:07 AM, David Karlsen wrote: >> >>> Hasn't the time for both CL and log4j passed by? The trend nowadays seems to >>> be slf4j/logback. >> >> If you read further back in this thread you will see where I highlighted the >> problems in Logback as well as difficulties with SLF4J. Plus, every time >> Ceki goes on vacation everything stops. >> >> Ralph >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
I prefer Apache driven projects when possible. If LOG4J2 takes off, feature requests would be implemented quicker, I hope. On Wed, Aug 3, 2011 at 9:27 AM, Ralph Goers wrote: > > On Aug 3, 2011, at 6:07 AM, David Karlsen wrote: > >> Hasn't the time for both CL and log4j passed by? The trend nowadays seems to >> be slf4j/logback. > > If you read further back in this thread you will see where I highlighted the > problems in Logback as well as difficulties with SLF4J. Plus, every time Ceki > goes on vacation everything stops. > > Ralph > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On Aug 3, 2011, at 6:07 AM, David Karlsen wrote: > Hasn't the time for both CL and log4j passed by? The trend nowadays seems to > be slf4j/logback. If you read further back in this thread you will see where I highlighted the problems in Logback as well as difficulties with SLF4J. Plus, every time Ceki goes on vacation everything stops. Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
Hasn't the time for both CL and log4j passed by? The trend nowadays seems to be slf4j/logback. Den 3. aug. 2011 15:03 skrev "Gary Gregory" følgende: > Or maybe Log4j 2 could replace [logging]. > > Gary > > On Wed, Aug 3, 2011 at 5:33 AM, Stephen Colebourne wrote: >> My thought is that there might be some java.util.logging helpers that >> could be written, and perhaps they might go in [lang] if there are 5 >> or fewer classes. >> >> I assume that slf4j and log4j have their own j.u.logging connections, >> so that end is dealt with. >> >> The time of [logging] has probably passed. >> >> Stephen >> >> >> On 3 August 2011 06:50, Henri Yandell wrote: >>> On Tue, Aug 2, 2011 at 1:59 AM, Emmanuel Bourg wrote: Le 28/07/2011 22:01, Henri Yandell a écrit : > > Personally I'm happy for commons-logging to die. :) Yeah let's use java.util.logging instead :) >>> >>> Primarily that I don't get the feeling we have a major community of >>> developers on c-logging. We implemented it because we needed something >>> for our other components (though many simply chose not to log), but it >>> was never the passion of anybody here (hopefully not an incorrect >>> statement). Robert, Simon and others put in tons of good work, but I >>> feel that was duty not passion. >>> >>> So happy to see it die because it's something that's headed to >>> dormancy (be it stable or not). >>> >>> Hen >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > > -- > Thank you, > Gary > > http://garygregory.wordpress.com/ > http://garygregory.com/ > http://people.apache.org/~ggregory/ > http://twitter.com/GaryGregory > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org >
Re: [logging] logging vs slf4j
Or maybe Log4j 2 could replace [logging]. Gary On Wed, Aug 3, 2011 at 5:33 AM, Stephen Colebourne wrote: > My thought is that there might be some java.util.logging helpers that > could be written, and perhaps they might go in [lang] if there are 5 > or fewer classes. > > I assume that slf4j and log4j have their own j.u.logging connections, > so that end is dealt with. > > The time of [logging] has probably passed. > > Stephen > > > On 3 August 2011 06:50, Henri Yandell wrote: >> On Tue, Aug 2, 2011 at 1:59 AM, Emmanuel Bourg wrote: >>> Le 28/07/2011 22:01, Henri Yandell a écrit : Personally I'm happy for commons-logging to die. :) >>> >>> Yeah let's use java.util.logging instead :) >> >> Primarily that I don't get the feeling we have a major community of >> developers on c-logging. We implemented it because we needed something >> for our other components (though many simply chose not to log), but it >> was never the passion of anybody here (hopefully not an incorrect >> statement). Robert, Simon and others put in tons of good work, but I >> feel that was duty not passion. >> >> So happy to see it die because it's something that's headed to >> dormancy (be it stable or not). >> >> Hen >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
My thought is that there might be some java.util.logging helpers that could be written, and perhaps they might go in [lang] if there are 5 or fewer classes. I assume that slf4j and log4j have their own j.u.logging connections, so that end is dealt with. The time of [logging] has probably passed. Stephen On 3 August 2011 06:50, Henri Yandell wrote: > On Tue, Aug 2, 2011 at 1:59 AM, Emmanuel Bourg wrote: >> Le 28/07/2011 22:01, Henri Yandell a écrit : >>> >>> Personally I'm happy for commons-logging to die. :) >> >> Yeah let's use java.util.logging instead :) > > Primarily that I don't get the feeling we have a major community of > developers on c-logging. We implemented it because we needed something > for our other components (though many simply chose not to log), but it > was never the passion of anybody here (hopefully not an incorrect > statement). Robert, Simon and others put in tons of good work, but I > feel that was duty not passion. > > So happy to see it die because it's something that's headed to > dormancy (be it stable or not). > > Hen > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On Tue, Aug 2, 2011 at 1:59 AM, Emmanuel Bourg wrote: > Le 28/07/2011 22:01, Henri Yandell a écrit : >> >> Personally I'm happy for commons-logging to die. :) > > Yeah let's use java.util.logging instead :) Primarily that I don't get the feeling we have a major community of developers on c-logging. We implemented it because we needed something for our other components (though many simply chose not to log), but it was never the passion of anybody here (hopefully not an incorrect statement). Robert, Simon and others put in tons of good work, but I feel that was duty not passion. So happy to see it die because it's something that's headed to dormancy (be it stable or not). Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
Le 28/07/2011 22:01, Henri Yandell a écrit : Personally I'm happy for commons-logging to die. :) Yeah let's use java.util.logging instead :) Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
Folks, I' suggest the following: 1.) create single JARs which exactly do what they should. 2.) use the maven-shade-plugin [1] to package 'bundles' containing some fitting jars of your project just for convenience. LieGrue, strub [1] http://maven.apache.org/plugins/maven-shade-plugin/ --- On Fri, 7/29/11, Ralph Goers wrote: > From: Ralph Goers > Subject: Re: [logging] logging vs slf4j > To: "Commons Developers List" > Date: Friday, July 29, 2011, 5:39 PM > Unfortunately, you are in the > minority on this one. Technically, you could just use the > Log4J 2.0 Impl jar, but then you would be coding to a > private API. > > Ralph > > On Jul 29, 2011, at 8:15 AM, Gary Gregory wrote: > > > One thing that is a hassle to me with modularized > projects, even > > slf4j, is that you end up with a bunch of tiny jars. > IOW & IMO: a > > mess. Personally, I want one jar to rule them all. If > I want to switch > > logging implementer or a client wants another impl I > have to fiddle > > with my builds and explain what each jar does. It's a > hassle. > > > > Gary > > > > On Fri, Jul 29, 2011 at 4:33 AM, Torsten Curdt > wrote: > >> At some stage I started to refactor commons > logging into a multi > >> module maven project and got rid of the discovery > part. So you would > >> have the commons-logging-api jar plus exactly one > of the > >> implementation bridges. So you pick the logging > target by putting the > >> correct bridge into your classpath. Similar to > slf4j. > >> > >> Didn't think there is still interest in commons > logging. Not sure I > >> still have the code. I lost interest after yet > another logging > >> discussion :) ...but it shouldn't be hard to > re-create. Not sure there > >> is still enough interest in this. > >> > >>>>> Seems to me you should focus on making > Log4J the impl > >>>>> excellent > >> > >> That sounds like work ;) > >> > >>> Unfortunately, SLF4J and Logback are run under > the BDFL model, not a collaboration as is done at the ASF. > >> > >> Which is one of the reasons I have always been > very reluctant to use it. > >> > >> cheers, > >> Torsten > >> > >> > - > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> > > > > > > > > -- > > Thank you, > > Gary > > > > http://garygregory.wordpress.com/ > > http://garygregory.com/ > > http://people.apache.org/~ggregory/ > > http://twitter.com/GaryGregory > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
The major issue I had was https://issues.apache.org/jira/browse/LOG4J2-31. We currently use SLF4J for audit logging via the SLF4J extension's EventLogger and EventData. Unfortunately, SLF4J has to convert the EventData object to XML since SLF4J/Logback don't provide a good way of handling this. To use this I had to create a Layout "wrapper" to convert the XML back to an EventData object so it could be used in various components. Needless to say this is cumbersome, slow and error prone. The Log4J 2.0 API uses a Message interface for everything. This allows the caller to have much more control over the formatting of the objects without having to write complex layouts that check for the presence of certain types of objects as parameters (which they can still do of course). Ralph On Jul 29, 2011, at 2:51 AM, Gilles Sadowski wrote: > Hello. > >> I would have done that but some of the deficiencies are in the API and I >> couldn't get Ceki to incorporate them. > > Do you have a pointer to a listing of those deficiencies? > >> [...] > > > Thanks, > Gilles > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org >
Re: [logging] logging vs slf4j
Commons Logging takes a least common denominator approach, which makes it useful for only fairly simple use cases. The goals for Log4J 2 are much more extensive than just a simple API that wraps other logging frameworks. Ralph On Jul 29, 2011, at 6:19 AM, Paul Benedict wrote: > Would there be any merit in combining the log4j and commons logging > code? Given a hypothetical Log4j 2 and JCL 2, how much different could > they really be in terms of their goals and add-ins? > > On Fri, Jul 29, 2011 at 4:51 AM, Gilles Sadowski > wrote: >> Hello. >> >>> I would have done that but some of the deficiencies are in the API and I >>> couldn't get Ceki to incorporate them. >> >> Do you have a pointer to a listing of those deficiencies? >> >>> [...] >> >> >> Thanks, >> Gilles >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
Unfortunately, you are in the minority on this one. Technically, you could just use the Log4J 2.0 Impl jar, but then you would be coding to a private API. Ralph On Jul 29, 2011, at 8:15 AM, Gary Gregory wrote: > One thing that is a hassle to me with modularized projects, even > slf4j, is that you end up with a bunch of tiny jars. IOW & IMO: a > mess. Personally, I want one jar to rule them all. If I want to switch > logging implementer or a client wants another impl I have to fiddle > with my builds and explain what each jar does. It's a hassle. > > Gary > > On Fri, Jul 29, 2011 at 4:33 AM, Torsten Curdt wrote: >> At some stage I started to refactor commons logging into a multi >> module maven project and got rid of the discovery part. So you would >> have the commons-logging-api jar plus exactly one of the >> implementation bridges. So you pick the logging target by putting the >> correct bridge into your classpath. Similar to slf4j. >> >> Didn't think there is still interest in commons logging. Not sure I >> still have the code. I lost interest after yet another logging >> discussion :) ...but it shouldn't be hard to re-create. Not sure there >> is still enough interest in this. >> > Seems to me you should focus on making Log4J the impl > excellent >> >> That sounds like work ;) >> >>> Unfortunately, SLF4J and Logback are run under the BDFL model, not a >>> collaboration as is done at the ASF. >> >> Which is one of the reasons I have always been very reluctant to use it. >> >> cheers, >> Torsten >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > > -- > Thank you, > Gary > > http://garygregory.wordpress.com/ > http://garygregory.com/ > http://people.apache.org/~ggregory/ > http://twitter.com/GaryGregory > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
One thing that is a hassle to me with modularized projects, even slf4j, is that you end up with a bunch of tiny jars. IOW & IMO: a mess. Personally, I want one jar to rule them all. If I want to switch logging implementer or a client wants another impl I have to fiddle with my builds and explain what each jar does. It's a hassle. Gary On Fri, Jul 29, 2011 at 4:33 AM, Torsten Curdt wrote: > At some stage I started to refactor commons logging into a multi > module maven project and got rid of the discovery part. So you would > have the commons-logging-api jar plus exactly one of the > implementation bridges. So you pick the logging target by putting the > correct bridge into your classpath. Similar to slf4j. > > Didn't think there is still interest in commons logging. Not sure I > still have the code. I lost interest after yet another logging > discussion :) ...but it shouldn't be hard to re-create. Not sure there > is still enough interest in this. > Seems to me you should focus on making Log4J the impl excellent > > That sounds like work ;) > >> Unfortunately, SLF4J and Logback are run under the BDFL model, not a >> collaboration as is done at the ASF. > > Which is one of the reasons I have always been very reluctant to use it. > > cheers, > Torsten > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
Would there be any merit in combining the log4j and commons logging code? Given a hypothetical Log4j 2 and JCL 2, how much different could they really be in terms of their goals and add-ins? On Fri, Jul 29, 2011 at 4:51 AM, Gilles Sadowski wrote: > Hello. > >> I would have done that but some of the deficiencies are in the API and I >> couldn't get Ceki to incorporate them. > > Do you have a pointer to a listing of those deficiencies? > >> [...] > > > Thanks, > Gilles > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
Hello. > I would have done that but some of the deficiencies are in the API and I > couldn't get Ceki to incorporate them. Do you have a pointer to a listing of those deficiencies? > [...] Thanks, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
On Fri, Jul 29, 2011 at 10:33 AM, Torsten Curdt wrote: > At some stage I started to refactor commons logging into a multi > module maven project and got rid of the discovery part. So you would > have the commons-logging-api jar plus exactly one of the > implementation bridges. So you pick the logging target by putting the > correct bridge into your classpath. Similar to slf4j. > > Didn't think there is still interest in commons logging. Not sure I > still have the code. I lost interest after yet another logging > discussion :) ...but it shouldn't be hard to re-create. Not sure there > is still enough interest in this. To be honest, I would love to see this. I like log4j/commons-logging very much, but there has been decreasing development effort the past years and slf4j/logback grew strong. Finally I though at least commons-logging is dead. I prefer asf libs, and so I would love to see your changes. This surely would help to revive the loggings project, which already is resurrecting due to Ralphs efforts with Log4j 2. So my interest is here, but I am not sure if I have enough time left to give the support it deserves :-) Cheers Christian Seems to me you should focus on making Log4J the impl excellent > > That sounds like work ;) > >> Unfortunately, SLF4J and Logback are run under the BDFL model, not a >> collaboration as is done at the ASF. > > Which is one of the reasons I have always been very reluctant to use it. > > cheers, > Torsten > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- http://www.grobmeier.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
At some stage I started to refactor commons logging into a multi module maven project and got rid of the discovery part. So you would have the commons-logging-api jar plus exactly one of the implementation bridges. So you pick the logging target by putting the correct bridge into your classpath. Similar to slf4j. Didn't think there is still interest in commons logging. Not sure I still have the code. I lost interest after yet another logging discussion :) ...but it shouldn't be hard to re-create. Not sure there is still enough interest in this. >>> Seems to me you should focus on making Log4J the impl >>> excellent That sounds like work ;) > Unfortunately, SLF4J and Logback are run under the BDFL model, not a > collaboration as is done at the ASF. Which is one of the reasons I have always been very reluctant to use it. cheers, Torsten - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
great news Ralph, and kudos for your hard work! looking forward to hear more from log4j soon! have a nice day, all the best, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Fri, Jul 29, 2011 at 5:53 AM, Ralph Goers wrote: > Oh - I should have also mentioned that I implemented support for the SLF4J > API and commons logging as well as the new Log4J API. > > Ralph > > On Jul 28, 2011, at 7:30 PM, Henri Yandell wrote: > >> Random input. Seems to me you should focus on making Log4J the impl >> excellent and not trying to create yet.another.facade. ie) Don't >> compete with SLF4J, compete with Logback (given its licensing). >> >> Hen >> >> On Thu, Jul 28, 2011 at 5:25 PM, Ralph Goers >> wrote: >>> FWIW, I have been working heavily on Log4J version 2 and would hope you'd >>> help with that before going to SLF4J [1]. I have separated the API and Impl >>> in a manner similar to SLF4J/Logback but am working to correct some >>> problems I've encountered using each of those where I work. >>> >>> Ralph >>> >>> [1] >>> https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/ >>> >>> >>> On Jul 28, 2011, at 1:01 PM, Henri Yandell wrote: >>> Personally I'm happy for commons-logging to die. :) On Thu, Jul 28, 2011 at 12:19 PM, Simone Tripodi wrote: > Hi all guys, > I remember I raw a thread - not sure if I did it here at commons orI > somewhere else here at apache - where specified we prefer adding > [logging] as components dependency instead of slf4j... > Did I just get crazy or someone can point me to the right direction > please? :) > Many thanks in advance, all the best!!! > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
Oh - I should have also mentioned that I implemented support for the SLF4J API and commons logging as well as the new Log4J API. Ralph On Jul 28, 2011, at 7:30 PM, Henri Yandell wrote: > Random input. Seems to me you should focus on making Log4J the impl > excellent and not trying to create yet.another.facade. ie) Don't > compete with SLF4J, compete with Logback (given its licensing). > > Hen > > On Thu, Jul 28, 2011 at 5:25 PM, Ralph Goers > wrote: >> FWIW, I have been working heavily on Log4J version 2 and would hope you'd >> help with that before going to SLF4J [1]. I have separated the API and Impl >> in a manner similar to SLF4J/Logback but am working to correct some problems >> I've encountered using each of those where I work. >> >> Ralph >> >> [1] >> https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/ >> >> >> On Jul 28, 2011, at 1:01 PM, Henri Yandell wrote: >> >>> Personally I'm happy for commons-logging to die. :) >>> >>> On Thu, Jul 28, 2011 at 12:19 PM, Simone Tripodi >>> wrote: Hi all guys, I remember I raw a thread - not sure if I did it here at commons orI somewhere else here at apache - where specified we prefer adding [logging] as components dependency instead of slf4j... Did I just get crazy or someone can point me to the right direction please? :) Many thanks in advance, all the best!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
I would have done that but some of the deficiencies are in the API and I couldn't get Ceki to incorporate them. Unfortunately, SLF4J and Logback are run under the BDFL model, not a collaboration as is done at the ASF. Ralph On Jul 28, 2011, at 7:30 PM, Henri Yandell wrote: > Random input. Seems to me you should focus on making Log4J the impl > excellent and not trying to create yet.another.facade. ie) Don't > compete with SLF4J, compete with Logback (given its licensing). > > Hen > > On Thu, Jul 28, 2011 at 5:25 PM, Ralph Goers > wrote: >> FWIW, I have been working heavily on Log4J version 2 and would hope you'd >> help with that before going to SLF4J [1]. I have separated the API and Impl >> in a manner similar to SLF4J/Logback but am working to correct some problems >> I've encountered using each of those where I work. >> >> Ralph >> >> [1] >> https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/ >> >> >> On Jul 28, 2011, at 1:01 PM, Henri Yandell wrote: >> >>> Personally I'm happy for commons-logging to die. :) >>> >>> On Thu, Jul 28, 2011 at 12:19 PM, Simone Tripodi >>> wrote: Hi all guys, I remember I raw a thread - not sure if I did it here at commons orI somewhere else here at apache - where specified we prefer adding [logging] as components dependency instead of slf4j... Did I just get crazy or someone can point me to the right direction please? :) Many thanks in advance, all the best!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
Random input. Seems to me you should focus on making Log4J the impl excellent and not trying to create yet.another.facade. ie) Don't compete with SLF4J, compete with Logback (given its licensing). Hen On Thu, Jul 28, 2011 at 5:25 PM, Ralph Goers wrote: > FWIW, I have been working heavily on Log4J version 2 and would hope you'd > help with that before going to SLF4J [1]. I have separated the API and Impl > in a manner similar to SLF4J/Logback but am working to correct some problems > I've encountered using each of those where I work. > > Ralph > > [1] > https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/ > > > On Jul 28, 2011, at 1:01 PM, Henri Yandell wrote: > >> Personally I'm happy for commons-logging to die. :) >> >> On Thu, Jul 28, 2011 at 12:19 PM, Simone Tripodi >> wrote: >>> Hi all guys, >>> I remember I raw a thread - not sure if I did it here at commons orI >>> somewhere else here at apache - where specified we prefer adding >>> [logging] as components dependency instead of slf4j... >>> Did I just get crazy or someone can point me to the right direction please? >>> :) >>> Many thanks in advance, all the best!!! >>> Simo >>> >>> http://people.apache.org/~simonetripodi/ >>> http://www.99soft.org/ >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
Yes, Ceki created SLF4J and Logback based on his experience with 1.2 and 1.3. The logging community is pretty small and really could use more people involved. I've had quite a bit of experience with logging for my employer as our needs are a bit different than what most people use a logging framework for. As a consequence, one of my primary focuses has been to make sure those use cases are supported, in addition to what SLF4J, Logback and Log4j do. https://issues.apache.org/jira/browse/LOG4J2 is where all the feature requests currently reside. Log4j 1.x is in bugzilla. Ralph On Jul 28, 2011, at 5:39 PM, Paul Benedict wrote: > Good deal Ralph! Didn't the creator of Log4j abandon the 1.2/1.3 > branch to make SLF4J? Anyways, I have no idea why all the creativity > for logging went outside of Apache, but I would definitely like to see > a version 2.0. > > You taking feature requests yet in JIRA? :-) > > Paul > > On Thu, Jul 28, 2011 at 7:25 PM, Ralph Goers > wrote: >> FWIW, I have been working heavily on Log4J version 2 and would hope you'd >> help with that before going to SLF4J [1]. I have separated the API and Impl >> in a manner similar to SLF4J/Logback but am working to correct some problems >> I've encountered using each of those where I work. >> >> Ralph >> >> [1] >> https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/ >> >> >> On Jul 28, 2011, at 1:01 PM, Henri Yandell wrote: >> >>> Personally I'm happy for commons-logging to die. :) >>> >>> On Thu, Jul 28, 2011 at 12:19 PM, Simone Tripodi >>> wrote: Hi all guys, I remember I raw a thread - not sure if I did it here at commons orI somewhere else here at apache - where specified we prefer adding [logging] as components dependency instead of slf4j... Did I just get crazy or someone can point me to the right direction please? :) Many thanks in advance, all the best!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org >
Re: [logging] logging vs slf4j
Great news Ralph. I look forward to the new version. Gary On Jul 28, 2011, at 20:26, Ralph Goers wrote: > FWIW, I have been working heavily on Log4J version 2 and would hope you'd > help with that before going to SLF4J [1]. I have separated the API and Impl > in a manner similar to SLF4J/Logback but am working to correct some problems > I've encountered using each of those where I work. > > Ralph > > [1] > https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/ > > > On Jul 28, 2011, at 1:01 PM, Henri Yandell wrote: > >> Personally I'm happy for commons-logging to die. :) >> >> On Thu, Jul 28, 2011 at 12:19 PM, Simone Tripodi >> wrote: >>> Hi all guys, >>> I remember I raw a thread - not sure if I did it here at commons orI >>> somewhere else here at apache - where specified we prefer adding >>> [logging] as components dependency instead of slf4j... >>> Did I just get crazy or someone can point me to the right direction please? >>> :) >>> Many thanks in advance, all the best!!! >>> Simo >>> >>> http://people.apache.org/~simonetripodi/ >>> http://www.99soft.org/ >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
Good deal Ralph! Didn't the creator of Log4j abandon the 1.2/1.3 branch to make SLF4J? Anyways, I have no idea why all the creativity for logging went outside of Apache, but I would definitely like to see a version 2.0. You taking feature requests yet in JIRA? :-) Paul On Thu, Jul 28, 2011 at 7:25 PM, Ralph Goers wrote: > FWIW, I have been working heavily on Log4J version 2 and would hope you'd > help with that before going to SLF4J [1]. I have separated the API and Impl > in a manner similar to SLF4J/Logback but am working to correct some problems > I've encountered using each of those where I work. > > Ralph > > [1] > https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/ > > > On Jul 28, 2011, at 1:01 PM, Henri Yandell wrote: > >> Personally I'm happy for commons-logging to die. :) >> >> On Thu, Jul 28, 2011 at 12:19 PM, Simone Tripodi >> wrote: >>> Hi all guys, >>> I remember I raw a thread - not sure if I did it here at commons orI >>> somewhere else here at apache - where specified we prefer adding >>> [logging] as components dependency instead of slf4j... >>> Did I just get crazy or someone can point me to the right direction please? >>> :) >>> Many thanks in advance, all the best!!! >>> Simo >>> >>> http://people.apache.org/~simonetripodi/ >>> http://www.99soft.org/ >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
FWIW, I have been working heavily on Log4J version 2 and would hope you'd help with that before going to SLF4J [1]. I have separated the API and Impl in a manner similar to SLF4J/Logback but am working to correct some problems I've encountered using each of those where I work. Ralph [1] https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/ On Jul 28, 2011, at 1:01 PM, Henri Yandell wrote: > Personally I'm happy for commons-logging to die. :) > > On Thu, Jul 28, 2011 at 12:19 PM, Simone Tripodi > wrote: >> Hi all guys, >> I remember I raw a thread - not sure if I did it here at commons orI >> somewhere else here at apache - where specified we prefer adding >> [logging] as components dependency instead of slf4j... >> Did I just get crazy or someone can point me to the right direction please? >> :) >> Many thanks in advance, all the best!!! >> Simo >> >> http://people.apache.org/~simonetripodi/ >> http://www.99soft.org/ >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org >
Re: [logging] logging vs slf4j
hahahaha :D I asked because there's one user that proposed a [chain] evolution, and one of suggested improvements is migrating over slf4j - I (wrongly, maybe) suggested to keep [logging] because here at commons we continue using it but, as said, I maybe reported a wrong fact. Do we encourage such kind of migrations or we are more conservative? Many thanks in advance, all the best!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Thu, Jul 28, 2011 at 10:01 PM, Henri Yandell wrote: > Personally I'm happy for commons-logging to die. :) > > On Thu, Jul 28, 2011 at 12:19 PM, Simone Tripodi > wrote: >> Hi all guys, >> I remember I raw a thread - not sure if I did it here at commons or >> somewhere else here at apache - where specified we prefer adding >> [logging] as components dependency instead of slf4j... >> Did I just get crazy or someone can point me to the right direction please? >> :) >> Many thanks in advance, all the best!!! >> Simo >> >> http://people.apache.org/~simonetripodi/ >> http://www.99soft.org/ >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] logging vs slf4j
Personally I'm happy for commons-logging to die. :) On Thu, Jul 28, 2011 at 12:19 PM, Simone Tripodi wrote: > Hi all guys, > I remember I raw a thread - not sure if I did it here at commons or > somewhere else here at apache - where specified we prefer adding > [logging] as components dependency instead of slf4j... > Did I just get crazy or someone can point me to the right direction please? :) > Many thanks in advance, all the best!!! > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[logging] logging vs slf4j
Hi all guys, I remember I raw a thread - not sure if I did it here at commons or somewhere else here at apache - where specified we prefer adding [logging] as components dependency instead of slf4j... Did I just get crazy or someone can point me to the right direction please? :) Many thanks in advance, all the best!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
