I've been having some fun today tracing back a ClassNotFoundException. Original problem was that for some reason, the spring context didn't come up when launching Jetty, but failing on SLF4J. Which is strange, since I dropped them in Jetty's lib directory. One thing I did though was configuring the webAppContext to ParentLoaderPriortiy = true, which lets the server libs have precedence over the webapp libs (like JBoss would behave, for example).
So why couldn't they be found? After a while, I recognized that the application context got started twice. First one worked, second one broke. Huh? After finding nothing useful on the web on that, I started reducing web.xml and spring's configuration, but even when totally stripped, this still happened. It happened in Eclipse/WTP as well as when starting outside eclipse. Hm.
Finally, found the solution when examining the deployers in Jetty's config file. Obviously, by default there are two deployers active, a webAppDeployer and a contextDeployer. The contextDeployer takes the configuration from /contexts and deploys them. The webAppDeployer takes whatever WAR it finds in /webapps and deploys it.
Now when these two use the same context, Jetty seems to be smart enough to figure out not to deploy them twice. But I changed the context path in my configuration, since I never got around why to have a webapp under /webappname if there's only one all over my server. So I set the contextPath to "/", effectively making that single webapp the root context.
And then came the webAppDeployer, picked up the war, and started deploying it. Since ParentLoaderPriortiy defaults to false, and wasn't obviously configured for the webAppDeployer (how in any case?), it only looked inside the WAR, didn't find SLF4J, and blew up. Doh.
Now why did I drop SLF4J in Jetty's lib anyway? I want it for both Jetty AND my webapp, and SLF4J can't be having with itself twice on the classpath.
Subscribe to:
Post Comments (Atom)

No comments:
Post a Comment