subject:"RE\: WicketFilter.init\(\) called twice with Glassfish"

RE: WicketFilter.init() called twice with Glassfish

2011-07-11 Thread Wilhelmsen Tor Iver

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

2011-07-04 Thread Bertrand Guay-Paquet


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-Paquetber...@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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: WicketFilter.init() called twice with Glassfish

2011-07-03 Thread Martin Grigorov

Hi,

On Sun, Jul 3, 2011 at 12:35 AM, Bertrand Guay-Paquet
ber...@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
EnumerationURL 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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: WicketFilter.init() called twice with Glassfish

2011-07-03 Thread Bertrand Guay-Paquet

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
ber...@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.

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.

Here is the set of unique URLs:

Yes, a set.

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.

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

Re: WicketFilter.init() called twice with Glassfish

2011-07-03 Thread Martin Grigorov

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
ber...@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:

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
ber...@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.

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.

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.

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

Re: WicketFilter.init() called twice with Glassfish

2011-07-03 Thread Bertrand Guay-Paquet

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 EnumerationURL 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,

On Sun, Jul 3, 2011 at 6:47 PM, Bertrand Guay-Paquet
ber...@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:

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
ber...@step.polymtl.cawrote:

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.

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
EnumerationURLresources =
Application.class.getClassLoader().getResources(name);
loadResources(resources, loadedFiles);

Here is the set of

Re: WicketFilter.init() called twice with Glassfish

2011-07-03 Thread Bertrand Guay-Paquet


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 IteratorURL getResources(String a_name) {
IteratorURL resourcesIter = classResolver.getResources(a_name);
ListURL URLList = new ArrayListURL();
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 EnumerationURL 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
ber...@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
ber...@step.polymtl.cawrote:
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

Re: WicketFilter.init() called twice with Glassfish

2011-07-03 Thread Attila Király

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 ber...@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

2011-07-02 Thread Bertrand Guay-Paquet

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.

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
EnumerationURL 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.

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.

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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: WicketFilter.init() called twice with Glassfish

2011-07-01 Thread Harald Wellmann


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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

RE: WicketFilter.init() called twice with Glassfish

Re: WicketFilter.init() called twice with Glassfish

Re: WicketFilter.init() called twice with Glassfish

Re: WicketFilter.init() called twice with Glassfish

Re: WicketFilter.init() called twice with Glassfish

Re: WicketFilter.init() called twice with Glassfish

Re: WicketFilter.init() called twice with Glassfish

Re: WicketFilter.init() called twice with Glassfish

Re: WicketFilter.init() called twice with Glassfish

Re: WicketFilter.init() called twice with Glassfish

10 matches

Site Navigation

Mail list logo

Footer information