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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
