Hi,
I have very recently transitioned from Embedded Jetty (single WAR) to
Java EE 6 and EAR-based deployment (Glassfish v3.1). I started being
able to see actual Wicket pages with EJB beans late last week and I only
tried deploying my application on Glassfish.
Since this is a new project, I'm working against Wicket 1.5 snapshots to
get the latest improvements.
I found the actual source of the problem in Glassfish sources and will
open a ticket with them :
========== begin details, skip if not interested ============
In com.sun.enterprise.loader.ASURLClassLoader (Glassfish code):
private java.net.URL
findResource0(com.sun.enterprise.loader.ASURLClassLoader.URLEntry res,
java.lang.String name)
creates URLs with host == null.
Line 468: URL ret = new URL("jar", null /* host */, -1 /* port */,
res.source + "!/" + name, handler);
Whereas
java.net.URLClassLoader#findResources(final java.lang.String)
returns an Enumeration<URL> with URLs having host == "" (empty string).
Comparing URLs returned from these 2 methods does not work because the
host property does not follow the same convention.
============ end details =============
I'll post back the ticket reference for anybody having the same issue.
Thanks for your help,
Bertrand
On 03/07/2011 1:04 PM, Martin Grigorov wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
