Yep - I am seeing destroying and unloading of classes there - which probably also get the log4j classes down (static methods, not used by anyone else or being forcebly unloaded) - which causes the class to look unloaded. That's exactly the kind of log I expected to see.
and that explain why this is an error - the call is coming from the spring, not from log4j itself.
1.2.16 is new enough - so you cannot get any more logging out of it even if you try to go up in the versions.
PS:
http://logging.apache.org/log4j/1.2/xref/org/apache/log4j/LogManager.html might actually be a better explanation than anything I can say - see how the method getLoggerRepository works - this is what causes all these error messages.
technically you might want to see if the advices here:
http://logging.apache.org/log4j/1.2/faq.html#unload are helping in your case - org.apache.catalina.loader
.WebappCla
ssLoader.E
NABLE_CLEA
R_REFERENC
ES could probably stop the spring from unloading the ones that do not need to be unloaded but I suspect that it is not this class that causes the issues here anyway but worth a check.
There might be a setting in glassfish or in spring (or in both) to get them to play nicely together - but the problem as it seems is that something that would have been logged as debug if it was called internally, is logged as error because it comes externally.
As these are static members and as I mentioned before the message is written, the offending element IS initialized properly, the log4j is again properly initialized and can be used.