I've come across this before when wrapping commons-logging but never come up with a satisfactory fix. commons-logging works because it passes a Fully Qualified Class Name (FQCN) in to every call to the log4j library (check out the Log4JLogger in commons-logging). The log4j library then uses this as the "entry" point into the logging system and takes the line/method/file of the entry just below it in the stack frame (it uses nasty string searching because StackTraceElement is 1.4+). This obviously goes wrong when something adds another wrapping layer round the commons-logging. The only "fix" I have come up with, but never implemented, is to plugin a different commons-logging LogFactory implementation, trap the case where it detects log4j as the logging type and return a custom log4j wrapper rather than the one provided by commons-logging. The wrapper would then pass in it's own FQCN that would allow log4j to get the line numbers right. Another fix would be to use log4j directly in Seam which would make passing in the correct FQCN trivial. Of course doing this may not be viable if commons-logging must be used to support the other log implementations. If I can spare some time I may look into bodging the first solution together to at least see if it works. Cheers. Mike. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991814#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...