I like the example. I'm not sure if it's something which we can use in Extensions themselfs (because of the bootstrap constraint - needs to be evaluated), but for applications for sure.
We just have to make sure that it's not a performance killer. LieGrue, strub ----- Original Message ----- > From: Dan Allen <[email protected]> > To: [email protected] > Cc: > Sent: Tuesday, January 24, 2012 6:40 PM > Subject: Re: [DISCUSS] Logging > > 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 >
