You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Bertrand Guay-Paquet <be...@step.polymtl.ca> on 2011/07/01 18:30:41 UTC
WicketFilter.init() called twice with Glassfish
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?
Thanks,
Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: WicketFilter.init() called twice with Glassfish
Posted by Bertrand Guay-Paquet <be...@step.polymtl.ca>.
Thanks for sharing this information Attila!
The folks at Glassfish suggested I use URIs as well.
I created WICKET-3867 to change URLs to URIs.
On 04/07/2011 1:48 AM, Attila Király wrote:
> Using java.net.URL in Set-s and Map-s is a no-no. Wicket should use
> java.net.URI instead. See [1] for an example.
>
> Attila
>
> [1] "More Joy of Sets" example with URL from Google Tech Talks:
> http://www.youtube.com/watch?v=wDN_EYUvUq0#t=9m58s
>
> 2011/7/3 Bertrand Guay-Paquet<be...@step.polymtl.ca>
>>
>> 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().
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: WicketFilter.init() called twice with Glassfish
Posted by Attila Király <ki...@gmail.com>.
Using java.net.URL in Set-s and Map-s is a no-no. Wicket should use
java.net.URI instead. See [1] for an example.
Attila
[1] "More Joy of Sets" example with URL from Google Tech Talks:
http://www.youtube.com/watch?v=wDN_EYUvUq0#t=9m58s
2011/7/3 Bertrand Guay-Paquet <be...@step.polymtl.ca>
>
>
> 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().
>
>
RE: WicketFilter.init() called twice with Glassfish
Posted by Wilhelmsen Tor Iver <To...@arrive.no>.
The first workaround we ended up using was something like:
public class SafeWicketFilter extends WicketFilter {
private boolean initWasAlreadyCalledSoYouShouldNotDoThisYouStupidGlassfish = false;
@Override
public void init(FilterConfig filterConfig) throws ServletException
{
synchronized(this)
{
if ( ! initWasAlreadyCalledSoYouShouldNotDoThisYouStupidGlassfish) {
super.init(filterConfig);
initWasAlreadyCalledSoYouShouldNotDoThisYouStupidGlassfish = true;
}
}
}
}
The second workaround was to stop using Glassfish. :)
- Tor Iver
Re: WicketFilter.init() called twice with Glassfish
Posted by Bertrand Guay-Paquet <be...@step.polymtl.ca>.
I created an issue with Glassfish:
http://java.net/jira/browse/GLASSFISH-16942
Here is a workaround I use in the meantime :
public class CustomClassResolver implements IClassResolver {
private DefaultClassResolver classResolver = new
DefaultClassResolver();
@Override
public Class<?> resolveClass(String a_classname) throws
ClassNotFoundException {
return classResolver.resolveClass(a_classname);
}
@Override
public Iterator<URL> getResources(String a_name) {
Iterator<URL> resourcesIter = classResolver.getResources(a_name);
List<URL> URLList = new ArrayList<URL>();
while (resourcesIter.hasNext()) {
URL next = resourcesIter.next();
// check for duplicate URL (see bug GLASSFISH-16942)
boolean dupe = false;
String nextString = next.toExternalForm();
for (URL url : URLList) {
if (url.toExternalForm().equals(nextString)) {
dupe = true;
break;
}
}
if (!dupe)
URLList.add(next);
}
return URLList.iterator();
}
}
In MyApplication.init() :
getApplicationSettings().setClassResolver(new CustomClassResolver());
On 03/07/2011 2:40 PM, Bertrand Guay-Paquet wrote:
> 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
>> <be...@step.polymtl.ca> 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
>>>> <be...@step.polymtl.ca> 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: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: WicketFilter.init() called twice with Glassfish
Posted by Bertrand Guay-Paquet <be...@step.polymtl.ca>.
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
> <be...@step.polymtl.ca> 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
>>> <be...@step.polymtl.ca> 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: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: WicketFilter.init() called twice with Glassfish
Posted by Martin Grigorov <mg...@apache.org>.
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
<be...@step.polymtl.ca> 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
>> <be...@step.polymtl.ca> 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: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: WicketFilter.init() called twice with Glassfish
Posted by Bertrand Guay-Paquet <be...@step.polymtl.ca>.
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
> <be...@step.polymtl.ca> 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: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: WicketFilter.init() called twice with Glassfish
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
On Sun, Jul 3, 2011 at 12:35 AM, Bertrand Guay-Paquet
<be...@step.polymtl.ca> 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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: WicketFilter.init() called twice with Glassfish
Posted by Bertrand Guay-Paquet <be...@step.polymtl.ca>.
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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: WicketFilter.init() called twice with Glassfish
Posted by Harald Wellmann <ha...@gmx.de>.
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org