On Wed, Jul 13, 2011 at 12:00 PM, Jason Pyeron <[email protected]> wrote:
> > -----Original Message----- > > From: Michael Dick [mailto:[email protected]] > > Sent: Wednesday, July 13, 2011 12:53 > > To: [email protected] > > Subject: Re: Logging questions > > > > It looks like you have the log4j-over-slf4j bridge on your > > classpath. Or some combination of the different logging facilities. > > It is possible. But my test case does not have it. I will check deeper on > this. FWIW, I created a maven project with just commons-logging and log4j-over-slf4j on the classpath, and got a very similar error. It sounds like you have a standalone testcase too, is that something you can send us? > > > > So commons-logging detects log4j and tries to use it. Log4j > > tries to delegate to slf4j, but that fails due to the missing > > implementation class. > > > > Do other parts of your application use log4j or slf4j? If > > not, can you remove them from the classpath and try 'just' > > with commons-logging? > > > > There are legacy parts of the system that were designed for other logging > frameworks, I do not have permission to modify those. I will need to find a > way > to force java.util.logging. I think this is more of a commons-logging behavior than OpenJPA. From looking at the commons-logging documentation<http://commons.apache.org/logging/commons-logging-1.1.1/guide.html#Configuration>it will look for log4j on the classpath before trying java.util.logging. The doc doesn't spell it out, or at least I couldn't find it, but you can add a commons-logging.properties file to the classpath. The properties file should have this entry : org.apache.commons.logging.Log=org.apache.commons.logging.impl.Jdk14Logger In my simple test it looks like it used Jdk4Logging. I don't know whether it will play well with the legacy parts of your system, but it's worth a try. Hope this helps, -mike <snip>
