[ http://issues.apache.org/struts/browse/SHALE-281?page=comments#action_39139 ] Craig McClanahan commented on SHALE-281: ----------------------------------------
Alas, an attempted workaround for this that I tried with Shale Remoting, with the goal to make the Commons Logging dependency optional, is not going to work out easily. It's not problem to create an adapter class that uses either Commons Logging or JDK Logging, depending on whether C-L is present. The problem is that the presence of this adapter class messes up the way that both logging environments determine the name of the calling class and method. Both of them go up only one level on the stack, where the presence of the adapter class would want them to go up two levels. I do not see any current way to break the required dependency on C-L without biting the bullet and switching to JDK logging unconditionally. > Eliminate direct dependencies on Commons Logging > ------------------------------------------------ > > Key: SHALE-281 > URL: http://issues.apache.org/struts/browse/SHALE-281 > Project: Shale > Issue Type: Task > Components: Core, Clay, Remoting, Tiger, Test, Dialog, Tiles, > Sandbox, Spring > 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
