Great question, and I wish more people spent time on this. In the end, your project will be better off for it. Also, keep in mind, there are many good answers to this question. Not everyone will agree, you have to make your own decision based on the reasons people supply.
Here's how I would handle it in my systems, and why.
If B encounters an exceptional condition it cannot handle, it should throw an exception that contains a very clear message as to what occurred. No logging occurs at B, as the message and the stack trace should be (make it so) enough for backtracking the problem. If you have determined that A is the place to handle such an exception, then it should be logged at that point, and that point only at the level that you deem appropriate. However, if A is then going to fail with it's own exception, wrap the original from B and pass it along, don't log.
Generally speaking in my systems, logging of exceptions *only* occurs at the point they are caught and dealt with. The point of exception creation is logged indirectly by including a solid message and stack trace in the log where it is handled.
This practice means that things get logged only one time, and usually there is enough information in that single log message and stack trace to fully locate an issue. If you find that it is not enough information, then there are two possible solutions. One, create a better error message or Two fail sooner with a different exception that is the actual cause of the problem.
Good luck
[Message sent by forum member 'rfeak' (rfeak)]
http://forums.java.net/jive/thread.jspa?messageID=258424