+1 to everything Dan mentioned in his mails (he beat me to a response!) I could have made it clearer in my original message, that while all goals of logging I described could be used internally within DeltaSpike, it was also aimed at providing that functionality for application developers.
Yes an application developer could do type safe logging, or any of the other features for logging, on their own. But, as we found with Solder, it's much nicer if you can provide that functionality to an application developer without making them understand how to write a CDI extension to make it work. Providing this feature OOTB I believe is important for all the reasons Dan mentioned, and I'm sure there are more. A big one is that logging is easy to mess up, so if we can provide an easy type safe way to remove error prone logging, why wouldn't we do it? Ken On Tue, Jan 24, 2012 at 12:54 PM, Dan Allen <[email protected]> wrote: > Oh yeah, it also opens the door for easy mocking in tests. We can, of > course, provide it as a utility out of the box so that it's just not a > headache. > > -Dan > > On Tue, Jan 24, 2012 at 12:40, Dan Allen <[email protected]> wrote: > > > Putting i18n aside, I want to defend the logging abstraction and the > > typesafe logging. > > > > Abstraction Layer: > > > > I believe very strongly that a logging abstraction is important in an > > extension framework. > > > > It's not about an unwillingness to commit to any one logging framework at > > all, really. The point has more to do with application server > integration. > > We've learned that it's crucial to be able to allow the application > server > > to take over control of the logging for both centralized configuration > and > > performance. That's why JBoss committed so much time to creating the > JBoss > > Logging API (don't confuse that name for something specific to JBoss AS. > > It's a logging abstraction layer). > > > > Granted, slf4j provides this abstraction in addition to a basic logger, > > but where it falls short (from what I understand) is it's ability to be > > extended to support things like supporting declarative behavior and my > next > > point, typesafe logging. > > > > Type-safe logging: > > > > It's important to understand that typesafe logging is first and foremost > > for the application developer, not necessarily for extensions (though the > > choice is open). While it's an extra step to setup, it doesn't several > > things that are very important for development: > > > > * minimizes the work to logging a routine message (it's DRY and concise) > > * makes the code where the log message is issued easy to read and > > understand (it communicates intent) > > * centralizes the log strings so that you can easily fix typos and see > > where they are used (eases maintenance) > > > > And one critical benefit for production: > > > > * totally eliminates the need of building & formatting a debug message > > when the level is disable, or the verbose code to wrap that log statement > > with a level check > > > > if (logger.isDebugEnabled()) { > > logger.debug("Processing payment of item {0} from customer {1}", > > item.toString(), customer.getUsername()); > > } > > > > vs. > > > > paymentLogger.processPayment(item, customer); > > > > Having said all that, you don't have to use it. The benefit of this > > proposal is that it's a layered approach. You get injectable loggers, but > > you can look them up with a static call too. You can use type-safe > logging, > > or you can use the flexible API underneath that allows them to work > > (message formatting, named parameters, etc. etc). > > > > -Dan > > > > -- > > Dan Allen > > Principal Software Engineer, Red Hat | Author of Seam in Action > > Registered Linux User #231597 > > > > http://google.com/profiles/dan.j.allen > > http://mojavelinux.com > > http://mojavelinux.com/seaminaction > > > > > > > -- > Dan Allen > Principal Software Engineer, Red Hat | Author of Seam in Action > Registered Linux User #231597 > > http://google.com/profiles/dan.j.allen > http://mojavelinux.com > http://mojavelinux.com/seaminaction >
