From jonathan...@gmail.com on October 31, 2013 08:26:45

This looks like the right place to comment this? though I see no ESAPI dev comments here, so not sure it is?

This class casting error is caused by the log4j.xml file being parsed and creating an entry into the org.apache.log4j.Hierarchy HashTable of logger definitions (ht) for all the keys:

But no class is defined in this xml definition so the default factory in org.apache.log4j.Hierarchy is used to create the logger (org.apache.log4j.DefaultCategoryFactory). Hence the logger created is a org.apache.log4j.Logger and this is added to the HashTable of logger definitions.

Then when the ESAPI.getLogger() is initialised in MyClass, the Heirarchy.getLogger() method returns the one in the HashTable, hence the class cast exception.

The workaround is to specify the class for each of the loggers defined in log4j.xml:

Could this be defaulted by the ESAPI code somehow?

From const.cr...@gmail.com on June 12, 2014 08:04:24

My problem is worse than the scenarios described above: the server I deploy to has a log4j jar in the Tomcat lib directory, so this jar is shared among all applications. One of the applications doesn't use ESAPI and it starts first, so it creates a logger with the standard Log4j logger which can't be then cast to ESAPI logger.

From const.cr...@gmail.com on June 12, 2014 09:59:17

One option to fix the problem would be to create a RepositorySelector, so each application would use its own repository, but this would require configuration in the application server (see http://articles.qos.ch/sc.html ).

Another option would be to have Log4JLogger as a wrapper of the Log4j Logger, so only classes using ESAPI.getLogger would in fact log using its logger.

I find solution to this This is class loading issue. You can put you ESAPI 2.0GA jar in TOMCAT_HOME/lib and mark in tomcat's context.xml which will be TOMCAT_HOME/conf.

2.0GA has some nasty CVEs attached to it. That said, this is a config issue and not an ESAPI bug. Closing.