Steven Schlansker <[email protected]> writes: >> On Apr 27, 2016, at 1:00 AM, Phillip Lord <[email protected]> wrote: >> >> >> >> The currently implementation of SLF4J prints a message on usage of the >> NOP implementation. This is not very friendly at all, as it means that >> if any dependency of my project includes a a dependency on SLF4J, I >> suddenly get an error message whether I wish it or not. > > Wow, you run Java apps without wanting slf4j logging? Who even does that > nowadays? ;)
Not wishing to be rude, but I'd never heard of slf4j till it started print messages out to me. Not the greatest introduction, although it seems like a nice thing otherwise! Actually, I'm using the JVM rather than Java per se. I'm also writing a piece of software that is an "end-user" tool (so, should include a slf4j binding) and is usable as a library (so, should not include a slf4j binding). >> This could be implemented in a number of ways -- you could make a >> slf4j-api-with-noisy dependency, you could look for an environment >> variable, or a system property. Users who need the warning would get it, >> and end-users who are not using slf4j explicitly would be untroubled by >> its presence, > > I suspect that changing the default behavior is out of the question, at > least until a 2.x.x major release. Additionally, some of the pushback > I received with the earlier approach was about the difficulty of managing > and lack of visibility associated with system properties. System properties are, indeed, a disaster. And using them to specify a binding never works well. That's why I suggested several options. You'd probably need all of them. None of this is for defining the binding -- it's simple to enable the "you've got no bindings" message (and probably the "you've got >1 bindings" message also). > So how about this: > > slf4j-api retains current behavior. Log if nop / duplicate > implementation. It doesn't "log" -- it dumps a message to standard error. If it was logging, I could turn it off! > -> Introduce a "slf4j-silent" jar which modifies the slf4j logger binding > process to be silent > > -> Introduce a "slf4j-strict" jar which modifies the slf4j logger binding > process to fail explosively on any trivial misconfiguration > > This probably only requires a single hook inside of the LoggerFactory, > same way you hook StaticLoggerBinder there could be a > StaticLoggerBindingConfiguration which is provided by one of these jars > (or silently absent, in the "default" case) This would seem reasonable -- assuming these are maven dependencies as well as jars. Another possibility would which works like -nop (i.e. shuts up the "no bindings" message), but does not cause the multiple bindings error message (i.e. it gives way silently). > Then, assuming the end user has good control of their build process, they > can elect to introduce one or the other (Personally, I would include > "slf4j-strict" in our default Maven parent POM globally) I don't understand the idea of the "end user" in this sense. Some one has to make the decision about what to do for an implementation. In fact, slf4j-api DOES make this decision (i.e. it nops), if no one else does. Should I make the decision for my library? Or should I leave it downstream project? Some of them are mine, but some are not. > The biggest downside is you wanted a "no additional configuration necessary" > solution, but I don't think that is possible -- the default case is already > defined and likely won't change. I think I could easily convince the upstream project which has introduced the slf4j-api dependency to switch to an slf4j-api-and-silent-nop. At the moment, they are not so happy about adding a slf4j-nop dependency directly, because it trades the certainty of one error message, for the risk of another. I think this is a good trade, but a solution which does not have this risk would be nicer. > Would this approach be welcome by the developers? Would it solve your > problem satisfactorily, even though it's not 100% what you wanted? If I have understood your suggestion correctly, yes, I think it would help. Thanks for the reply. Phil _______________________________________________ slf4j-user mailing list [email protected] http://mailman.qos.ch/mailman/listinfo/slf4j-user
