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.
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.
DefaultClassResolver.getResources(String) returns a list of resources
that 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:
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
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.
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?
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]
