It is not neccessarily so though, that the package structure of the system maps to a good logger hierarchy structure.
If the FQCN is used, you will get a very fine grained hierarchy. A more simple hierarchy at the top, can make it easier to understand which parts to change levels on, to get the output you want.
As an example, consider the application named "SuperApp". SuperApp" is a webapp, with a services and a dao layer. We could define only a few top-level logger names like this:
Actually, I have few more top-level names, for example "superapp.security", which represents something that is cross-cutting to a lot of the application. Also, I sometimes have an extra naming level after "superapp.xxx", which is kind of "in the middle", just before the leaves.
What is good about this?
Often, when I debug, I find myself looking around in the hierarchy of loggers, turning something on here and there, to get the collected picture of the complete flow, that I want to follow. When using the naming strategy outlined below, I find it much easier to simply turn on a complete area of the system.
Also, when systems management are debugging, they have no or very little knowledge of the package structure of the application. They can better relate to the names, that are targeted the application, as above.