Hi, This behavior explains the problem. Since when you face this problem ? I remember tickets from you since at least Wicket 1.5-RC1. Did you upgrade to newer version of Glassfish or did you introduce .ear/lib recently ?
On Sun, Jul 3, 2011 at 6:47 PM, Bertrand Guay-Paquet <[email protected]> wrote: > Hi Martin, > > I wanted to make my message shorter, but I should have posted the whole > thing to avoid the confusion. You are right that a set is returned and not a > list of course. However, here is what is actually returned by the method: > > 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-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 > 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 > > When I said "second set", I meant that the same URLs are added, which is > indeed strange considering that they are added to a HashSet! > > After more digging, I found that the URLs are not in fact equal as > determined by URL.equals(). The URLs with the same string value differ in > their "host" property which is used by URL.equals(). One "set" of URLs has a > host == null and the other has host == "". The actual host comparison is > done in URLStreamHandler.hostsEqual(). > > In DefaultClassResolver.getResources(), the first classloader is > EarLibClassLoader and the second one is WebappClassLoader (with parent == > EarClassLoader) > > All this seems to rule out my first hypothesis that the class loader > hierarchy handling is the problem. Now I need to find out why one loader > sets the host to null and the other sets it to ""... > > > On 03/07/2011 8:35 AM, Martin Grigorov wrote: >> >> 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]
