[ http://issues.apache.org/struts/browse/SHALE-281?page=comments#action_39201 ] Craig McClanahan commented on SHALE-281: ----------------------------------------
Thank you for the suggestion, Andres ... but as far as I can tell, the approach POI takes will have the same problem as the one I identified if you actually do route your log messages through the CommonsLogger implementation of POILogger. The adapter approach works fine for actually getting the logging output piped through, and you can indeed make Commons Logging not required if you're really using JDK 1.4 logging instead. The problem, though, is in how the logging systems display the name of the class and method from which the message was logged -- they go up one level on the call stack, and extract the class and method names from that. The problem is, when you use an adapter, that *all* messages appear to come from the log() method of the adapter class, not from the method that called the adapter. To get the display right, we'd need to teach the logging implementation to go one level further up the call stack than it normally would. For the purposes that the POI website claims you would ever use logging in POI (just for debugging POI itself, not for production tracing) this is probably not a big deal ... you're probably staring directly at the source code, or using the system out logger (which doesn't do this at all) anyway. It matters more for a webapp where you want the INFO and WARN type messages to be logged to the same place as all the other messages from your webapp, with correct descriptions of where the logged messages come from. > Eliminate direct dependencies on Commons Logging > ------------------------------------------------ > > Key: SHALE-281 > URL: http://issues.apache.org/struts/browse/SHALE-281 > Project: Shale > Issue Type: Task > Components: Clay, Core, Dialog, Remoting, Sandbox, Spring, Test, > Tiger, Tiles > Reporter: Craig McClanahan > Fix For: TBD > > > Since we depend on JDK 1.4 or later anyway, and since the logging > requirements of the framework itself are minial, update the framework classes > from dependency on Commons Logging to use JDK 1.4 logging instead. This does > not necessarily need to apply to example applications. The focus is on > minimizing dependencies for the framework itself. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
