That looks related to the detection mechanism for log4j-web (probably in the lookup plugin stuff; I remember that using an odd bastardisation of the PluginManager). I think that log message is irrelevant now. It was supposed to be more of a "hey, if you want to use log4j in a web context, you should probably include log4j-web", not how it actually looks.
On 21 May 2014 14:38, Gary Gregory <[email protected]> wrote: > I see a lot of the same stack trace in the Maven build: > > 2014-05-21 15:36:31,466 WARN ServletContext is available, but log4j-web is > not. java.lang.ClassNotFoundException: > org.apache.logging.log4j.web.WebLookup > at java.net.URLClassLoader$1.run(URLClassLoader.java:202) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:190) > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) > at java.lang.ClassLoader.loadClass(ClassLoader.java:247) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:171) > at > org.apache.logging.log4j.core.util.Loader.loadClassWithDefaultClassLoader(Loader.java:259) > at > org.apache.logging.log4j.core.util.Loader.loadClass(Loader.java:254) > at > org.apache.logging.log4j.core.util.Loader.newInstanceOf(Loader.java:309) > at > org.apache.logging.log4j.core.util.Loader.newCheckedInstanceOf(Loader.java:339) > at > org.apache.logging.log4j.core.lookup.Interpolator.<init>(Interpolator.java:80) > at > org.apache.logging.log4j.core.config.AbstractConfiguration.<init>(AbstractConfiguration.java:104) > at > org.apache.logging.log4j.core.config.DefaultConfiguration.<init>(DefaultConfiguration.java:52) > at > org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:438) > at > org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:397) > at > org.apache.logging.log4j.taglib.IfEnabledTagTest.cleanUpClass(IfEnabledTagTest.java:53) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at > org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) > at > org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200) > at > org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) > at > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) > > Is that normal? > > Do we really want to log a warning? It sure seems alarming for a user. > > Gary > -- > E-Mail: [email protected] | [email protected] > Java Persistence with Hibernate, Second > Edition<http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > -- Matt Sicker <[email protected]>
