Jason, I fully appreciate that we've reach the end of what slf4j-simple can, and should, do. I'm just saying that I would have preferred us to use slf4j-simple for the first release. But you, and a few others, are doing the work and should decide. I'm just expression a by-stander's thoughts.
However, I would like to suggest the option of releasing with slf4j-simple and one, or two, known limitations (the bug(s) found with embedded). I don't have the insight to tell if it's possible but let those of you investigating do the decision. I'm thinking that in embedded scenarios the host might already be using a different implementation (like m2e is) so it might not be a problem. /Anders On Sun, Dec 9, 2012 at 11:30 PM, Jason van Zyl <ja...@tesla.io> wrote: > Anders, > > My take is that this will be the 5th change that I've asked for to get the > SLF4J Simple implementation to work. Initially I had your position and I > tried to keep it as simple as possible the provide the same behaviour, but > for embedded environments and concurrent operations I think we're just > going to run into more of the same. We can continue patching the simple > implementation and make it do things it wasn't designed to or just switch > to Logback. I think I gave it a best effort but I don't want to patch SLF4J > Simple anymore. > > On Dec 9, 2012, at 4:53 PM, Anders Hammar <and...@hammar.net> wrote: > > > Not sure where to get into this thread, but I'd just like to add my > > perspective on this topic. > > > > For this first release I would prefer it to not include any of the more > > advanced slf4j implementations, like a few others have already also > stated. > > Using simple would give us a good start on this new path while we > > investigate what we and the community want feature wise and then select > an > > implementation based on these requirements. However, if slf4-simple can't > > do the job of the old behavior when we might not have that option > > unfortunately. Or, possibly we could live with these deficiencies? I'll > > leave that to others working with that to decide. > > > > But if we have to decide on a more advanced implementation my choice > would > > be logback. My choice is based on two things where one being a past > > experience where I developed an audit logging solution based on logback, > > where my research showed that log4j had so many deficiencies when it came > > to more advanced cases. log4j2 might be a different story with this fixed > > though, but I don't see any reason trying something else when there is > > proven option. Secondly, I have good confidence in Ceki and that he will > > help us out should we need that. I'm not saying those working with log4j2 > > will not, it's just that I don't know their track record as I know > Ceki's. > > > > But to repeat myself, going simple in the first release would be so much > > better. Then we could get our requirements after this first release and > do > > a selection based on them rather than just a gut feeling. Although using > > slf4j as the API gives us the technical possibility of switching impl > later > > on, I don't think we want that as we can probably expect some people do > > solutions expecting a specific impl (as we've seen in the Sonar plugin > for > > example). > > > > /Anders > > > > > > On Sun, Dec 9, 2012 at 1:51 PM, Stephen Connolly < > > stephen.alan.conno...@gmail.com> wrote: > > > >> On Sunday, 9 December 2012, Kristian Rosenvold wrote: > >> > >>> 2012/12/9 Olivier Lamy <ol...@apache.org <javascript:;>>: > >>>> Perso I'm fine using log4j2. > >>>> I use the branch I pushed for some weeks now and I'm happy. > >>>> Log4j2 has quickly added a feature I needed and release it. > >>>> Furthermore I'm fine working with an Apache community in case of any > >>>> issue we could have. > >>> > >>> I'm not entirely sure I follow where this discussion is actually > >>> going, but I'm firmly opposed > >>> to including a brand new logging framework as default in m3. > >>> > >>> > >> +1 > >> > >> > >>> Kristian > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org<javascript:;> > >>> For additional commands, e-mail: dev-h...@maven.apache.org > <javascript:;> > >>> > >>> > >> > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder & CTO, Sonatype > Founder, Apache Maven > http://twitter.com/jvanzyl > --------------------------------------------------------- > > In short, man creates for himself a new religion of a rational > and technical order to justify his work and to be justified in it. > > -- Jacques Ellul, The Technological Society > > > > > >
