Hi, On Sun, Jul 3, 2011 at 12:35 AM, Bertrand Guay-Paquet <[email protected]> wrote: > Thanks for your answer Harald. I had taken a look at that bug as well, but > this is not my case. I don't even have to access a web page to see the > initialization problem. Filter.init() is called at deploy time. Not at request time. > > Wicket logs show the following on startup: > INFO: init: DevUtils DebugBar Initializer > INFO: init: DevUtils DebugBar Initializer > INFO: init: Wicket extensions initializer > INFO: init: Wicket core library initializer > INFO: init: Wicket extensions initializer > INFO: init: Wicket core library initializer > > After more investigation, it seems I was wrong and WicketFilter.init() is > only called once. Therefore the problem seems to lie inside Wicket. So far so good :-) > > DefaultClassResolver.getResources(String) returns a list of resources that Correction: returns a *set*! > has each resource twice. This is the root cause of the double initialization > of some resources. > > The first set of resource URLs is returned by: > // Try the classloader for the wicket jar/bundle > Enumeration<URL> resources = > Application.class.getClassLoader().getResources(name); > loadResources(resources, loadedFiles); > > The second identical set of resource URLs is returned by: > // Try the classloader for the user's application jar/bundle > resources = > Application.get().getClass().getClassLoader().getResources(name); > loadResources(resources, loadedFiles); > > Here is the set of unique URLs: Yes, a set. > jar:file:/C:/glassfish3/glassfish/domains/domain1/applications/MyEAR/lib/wicket-devutils-1.5-SNAPSHOT.jar!/wicket.properties > jar:file:/C:/glassfish3/glassfish/domains/domain1/applications/MyEAR/lib/wicket-extensions-1.5-SNAPSHOT.jar!/wicket.properties > jar:file:/C:/glassfish3/glassfish/domains/domain1/applications/MyEAR/lib/wicket-core-1.5-SNAPSHOT.jar!/wicket.properties > Earlier you said the list have each of these resources twice. Where are the seconds ? > My EAR archive is the one containing the Wicket libraries in its lib/ > folder. My WAR archive inside the EAR is a "skinny" WAR without 3rd party > libs. > > I strongly suspect that the class loader hierarchy of an EAR deployment is > not appropriate for the way DefaultClassResolver.getResources() operates, > but I haven't dug deep enough into it yet to understand it fully. You can easily check it by putting a breakpoint in org.apache.wicket.application.DefaultClassResolver.getResources(String) and see what kind of class loaders are involved. > > If anybody could shed more light on this that would be great. Also, maybe a > Wicket dev could give more explanation as to why DefaultClassResolver tries > multiple class loaders to load resources? They are tried to be able to collect all IInitializers from all involved classloaders (.ear/lib, .war, ...) as in your case. The catch here is (as I already mentioned above) - the URLs are collected in a Set, so there shouldn't be any duplicates. > > I guess I could override DefaultClassResolver.getResources() for my case and > only load from one location, but there might be other similar issues > elsewhere. > > Bertrand > > On 01/07/2011 12:54 PM, Harald Wellmann wrote: >> >> Am 01.07.2011 18:30, schrieb Bertrand Guay-Paquet: >>> >>> Hello, >>> >>> I am deploying a Wicket 1.5 application inside an EAR on Glassfish 3.1. >>> >>> I noticed that the debug bar was "doubled" at the top of the browser >>> window (2 full debug bars). After investigation, the problem is that >>> WicketFIlter.init() is being called twice each time I start the server. >>> This causes the debug bar contributors to register twice. >>> >>> My web.xml contains only Wicket and only once. Roughly the same code did >>> not behave like this when I used an embedded jetty server and no EJBs or >>> EAR (single WAR). >>> >>> I'm trying to set up an environment to step inside Glassfish and see why >>> the filter is initialized twice. In the meantime, I ask has anybody seen >>> this double-init behavior before? >> >> Yes, I've seen this on Glassfish 3.0, and the problem was reported as >> fixed: >> http://java.net/jira/browse/GLASSFISH-11979 >> >> Maybe there's a regression? >> >> Regards, >> Harald >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
-- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
