I've been having a frustrating time trying to sort out the logging in my project. In particular, one of the 3rd party libraries we use had one class, com.foo.bar.baz.java, that ignored any configuration in the properties file for the com.foo.bar package, instead following the application-wide properties.
Eventually using %c in the pattern layout I learned that Log4J was logging it as Windows rather than its package.
What could be causing this? It's proving remarkably Google-proof.
There could be a lot of things causing it. Can you post your log configuration file? Do you have a gui project? Are you (or the 3rd party library) attempting to log to gui components?
Are you able to view the log4j configuration files of your 3rd party library?
For example, our application at work runs on Tomcat and there's a <logging> section in the server-config.xml file that allows one to specify a custom logging target for the server.
As another example, I've been bitten dozens of times by rogue commons-logging.properties files which can change the entire functionality of all logging, application wide, just by modifying a few properties. Further, those files specify a priority flag and if any property file is found on the classpath with a higher priority than the one in your project, it takes precedence!
Don't forget that while the use of the fully qualified name of the class is the usual convention, it's not a requirement!
The author's quite at liberty to use whatever string they want as the Logger name and it sounds as if in this case, they've gone for a component based name.