Re: (Un-)deployment woes on Tomcat (and JBoss)
I can kind of see what is going on, the YourApplication class is
loaded using a different classloader then the wicket jar. and tomcat
cleans it up. fair enough. but, YourApplication class extends
Application which is inside the jar, so tomcat should not be cleaning
it up...makes no sense. How can the entire jar be gone if one of the
classes that was loaded from it is still being used. It may be an
optimization they do but its may be backfiring in this particular
case. You may have to use your jar protector as a permanent
workaround.
-igor
On Sun, Mar 21, 2010 at 2:57 AM, Alexandros Karypidis wrote:
> Ok, I've pinpointed the underlying cause. Indeed, the file is simply removed
> before the destroy() method has a chance to clean up. I verified this by
> using this ugly hack:
>
> 1. Adding a field:
> private InputStream wicketJarProtector;
>
> 2. In WicketFilter.init() I open the wicket jar to "protect" it from
> deletion:
> wicketJarProtector =
> filterConfig.getServletContext().getResourceAsStream("/WEB-INF/lib/wicket.jar");
>
> 3. In WicketFilter.destroy() I close the file handle:
> wicketJarProtector.close();
>
> This prevents the file from being deleted, undeployment completes
> successfully.
>
> I'm not sure how to "properly" fix this... Any ideas?
>
> On 21/3/2010 11:38 πμ, Alexandros Karypidis wrote:
>>
>> Well, if I force the class to be loaded early this way, destroy() simply
>> fails a little bit further down, when trying to load a nested class.
>>
>> java.lang.NoClassDefFoundError:
>> org/apache/wicket/util/lang/PropertyResolver$IClassCache
>> at org.apache.wicket.Application.internalDestroy(Application.java:952)
>> at
>> org.apache.wicket.protocol.http.WebApplication.internalDestroy(WebApplication.java:527)
>> at
>> org.apache.wicket.protocol.http.WicketFilter.destroy(WicketFilter.java:180)
>> ...
>>
>> I could keep going by adding references to such classes until every class
>> needed to complete destroy() is pre-loaded, but the fact is that for some
>> reason, there is no more access to "wicket.jar" in "WEB-INF/lib". I added
>> debugged through the code and the weird thing is that it's the same
>> class-loader AND the same thread (JBoss' [HDScanner] thread). So it should
>> be able to load these classes. A look at the bottom of the stack trace
>> reveals this (notice that there is a "DelegatingHandler" to "wicket.jar" and
>> all packages for wicket are listed; so it's as if "wicket.jar" is simply no
>> longer in its place (i.e. the OS removes it before the class loader has a
>> chance to load the classes needed for destroy):
>>
>> Caused by: java.lang.ClassNotFoundException:
>> org.apache.wicket.util.lang.PropertyResolver$IClassCache from
>> baseclassloa...@10496f0{vfsclassloaderpolicy@517ead{name=vfsfile:/F:/ade_ws/.metadata/.plugins/org.jboss.ide.eclipse.as.core/JBoss_5.1_(default)/deploy/wicket-cl-test.war/
>> domain=classloaderdom...@1e351a2{name=vfsfile:/F:/ade_ws/.metadata/.plugins/org.jboss.ide.eclipse.as.core/JBoss_5.1_(default)/deploy/wicket-cl-test.war/
>> parentPolicy=AFTER_BUT_JAVA_BEFORE
>> parent=classloaderdom...@4d41e2{defaultdomain}} roots=[..,
>> delegatinghand...@8305721[path=wicket-cl-test.war/WEB-INF/lib/wicket.jar
>> context=file:/F:/ade_ws/.metadata/.plugins/org.jboss.ide.eclipse.as.core/JBoss_5.1_(default)/deploy/
>> real=file:/F:/ade_ws/.metadata/.plugins/org.jboss.ide.eclipse.as.core/JBoss_5.1_(default)/deploy/wicket-cl-test.war/WEB-INF/lib/wicket.jar]]
>> delegates=null exported=[, org.apache.wicket.util.diff.myers,
>> org.apache.wicket.markup.transformer,
>> org.apache.wicket.authorization.strategies.page,
>> org.apache.wicket.ajax.form, org.apache.log4j,
>> org.apache.wicket.util.convert, org.apache.wicket.util.resource,
>> org.apache.wicket.authorization.strategies, org.apache.log4j.lf5.config,
>> org.apache.log4j.spi, org.apache.wicket.protocol.http.servlet,
>> org.apache.wicket.markup.resolver,
>> org.apache.wicket.request.target.resource,
>> org.apache.wicket.util.parse.metapattern, ]
>> NON_EMPTY}}
>> at
>> org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:448)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
>> ... 72 more
>>
>>
>> On 20/3/2010 10:25 μμ, Igor Vaynberg wrote:
>>>
>>> interesting, wonder why the class would be unloaded *before* the
>>> application classloader.
>>>
>>> try this, add a field private PropertyClassResolver resolver=null; to
>>> your application subclass, see if the field is enough to stop the
>>> class from unloading.
>>>
>>> -igor
>>>
>>> On Sat, Mar 20, 2010 at 9:06 AM, Alexandros Karypidis
>>> wrote:
Hi,
I'm having problems with deployment/undeployment of Wicket apps on
Tomcat
(and also JBoss, though I think it's related to the fact that it embeds
Tomcat). Basically, in both cases undeployment comes back with an
Exception,
leaving the server in a "dirty" state and I have to restart the server
>
Re: (Un-)deployment woes on Tomcat (and JBoss)
Ok, I've pinpointed the underlying cause. Indeed, the file is simply
removed before the destroy() method has a chance to clean up. I verified
this by using this ugly hack:
1. Adding a field:
private InputStream wicketJarProtector;
2. In WicketFilter.init() I open the wicket jar to "protect" it from
deletion:
wicketJarProtector =
filterConfig.getServletContext().getResourceAsStream("/WEB-INF/lib/wicket.jar");
3. In WicketFilter.destroy() I close the file handle:
wicketJarProtector.close();
This prevents the file from being deleted, undeployment completes
successfully.
I'm not sure how to "properly" fix this... Any ideas?
On 21/3/2010 11:38 πμ, Alexandros Karypidis wrote:
Well, if I force the class to be loaded early this way, destroy()
simply fails a little bit further down, when trying to load a nested
class.
java.lang.NoClassDefFoundError:
org/apache/wicket/util/lang/PropertyResolver$IClassCache
at org.apache.wicket.Application.internalDestroy(Application.java:952)
at
org.apache.wicket.protocol.http.WebApplication.internalDestroy(WebApplication.java:527)
at
org.apache.wicket.protocol.http.WicketFilter.destroy(WicketFilter.java:180)
...
I could keep going by adding references to such classes until every
class needed to complete destroy() is pre-loaded, but the fact is that
for some reason, there is no more access to "wicket.jar" in
"WEB-INF/lib". I added debugged through the code and the weird thing
is that it's the same class-loader AND the same thread (JBoss'
[HDScanner] thread). So it should be able to load these classes. A
look at the bottom of the stack trace reveals this (notice that there
is a "DelegatingHandler" to "wicket.jar" and all packages for wicket
are listed; so it's as if "wicket.jar" is simply no longer in its
place (i.e. the OS removes it before the class loader has a chance to
load the classes needed for destroy):
Caused by: java.lang.ClassNotFoundException:
org.apache.wicket.util.lang.PropertyResolver$IClassCache from
baseclassloa...@10496f0{vfsclassloaderpolicy@517ead{name=vfsfile:/F:/ade_ws/.metadata/.plugins/org.jboss.ide.eclipse.as.core/JBoss_5.1_(default)/deploy/wicket-cl-test.war/
domain=classloaderdom...@1e351a2{name=vfsfile:/F:/ade_ws/.metadata/.plugins/org.jboss.ide.eclipse.as.core/JBoss_5.1_(default)/deploy/wicket-cl-test.war/
parentPolicy=AFTER_BUT_JAVA_BEFORE
parent=classloaderdom...@4d41e2{defaultdomain}} roots=[..,
delegatinghand...@8305721[path=wicket-cl-test.war/WEB-INF/lib/wicket.jar
context=file:/F:/ade_ws/.metadata/.plugins/org.jboss.ide.eclipse.as.core/JBoss_5.1_(default)/deploy/
real=file:/F:/ade_ws/.metadata/.plugins/org.jboss.ide.eclipse.as.core/JBoss_5.1_(default)/deploy/wicket-cl-test.war/WEB-INF/lib/wicket.jar]]
delegates=null exported=[, org.apache.wicket.util.diff.myers,
org.apache.wicket.markup.transformer,
org.apache.wicket.authorization.strategies.page,
org.apache.wicket.ajax.form, org.apache.log4j,
org.apache.wicket.util.convert, org.apache.wicket.util.resource,
org.apache.wicket.authorization.strategies,
org.apache.log4j.lf5.config, org.apache.log4j.spi,
org.apache.wicket.protocol.http.servlet,
org.apache.wicket.markup.resolver,
org.apache.wicket.request.target.resource,
org.apache.wicket.util.parse.metapattern,
] NON_EMPTY}}
at
org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:448)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
... 72 more
On 20/3/2010 10:25 μμ, Igor Vaynberg wrote:
interesting, wonder why the class would be unloaded *before* the
application classloader.
try this, add a field private PropertyClassResolver resolver=null; to
your application subclass, see if the field is enough to stop the
class from unloading.
-igor
On Sat, Mar 20, 2010 at 9:06 AM, Alexandros
Karypidis wrote:
Hi,
I'm having problems with deployment/undeployment of Wicket apps on
Tomcat
(and also JBoss, though I think it's related to the fact that it embeds
Tomcat). Basically, in both cases undeployment comes back with an
Exception,
leaving the server in a "dirty" state and I have to restart the
server every
time. This has been mentioned in both the user and developer lists,
but with
no reply:
http://old.nabble.com/java.lang.NoClassDefFoundError:-org-apache-wicket-util-lang-PropertyResolver-tc26191924.html
http://old.nabble.com/Weird-error-on-shutdown...-td18907685.html
The problem manifests only when deploying EXPLODED wars (with a single
packaged WAR file, the problem goes away). It can be easily
reproduced as
follows:
1) Create an instance of the quickstart archetype
(http://wicket.apache.org/quickstart.html). Let's say you used the
default
values so the artifact id is "myproject" from here on. Use the
latest 1.4.7
version of Wicket (though I've tried with all previous versions up
to 1.4.4
and the result is the same; the reference above uses version 1.4-m2,
so it
must be surprisingly old
Re: (Un-)deployment woes on Tomcat (and JBoss)
Well, if I force the class to be loaded early this way, destroy() simply
fails a little bit further down, when trying to load a nested class.
java.lang.NoClassDefFoundError:
org/apache/wicket/util/lang/PropertyResolver$IClassCache
at org.apache.wicket.Application.internalDestroy(Application.java:952)
at
org.apache.wicket.protocol.http.WebApplication.internalDestroy(WebApplication.java:527)
at
org.apache.wicket.protocol.http.WicketFilter.destroy(WicketFilter.java:180)
...
I could keep going by adding references to such classes until every
class needed to complete destroy() is pre-loaded, but the fact is that
for some reason, there is no more access to "wicket.jar" in
"WEB-INF/lib". I added debugged through the code and the weird thing is
that it's the same class-loader AND the same thread (JBoss' [HDScanner]
thread). So it should be able to load these classes. A look at the
bottom of the stack trace reveals this (notice that there is a
"DelegatingHandler" to "wicket.jar" and all packages for wicket are
listed; so it's as if "wicket.jar" is simply no longer in its place
(i.e. the OS removes it before the class loader has a chance to load the
classes needed for destroy):
Caused by: java.lang.ClassNotFoundException:
org.apache.wicket.util.lang.PropertyResolver$IClassCache from
baseclassloa...@10496f0{vfsclassloaderpolicy@517ead{name=vfsfile:/F:/ade_ws/.metadata/.plugins/org.jboss.ide.eclipse.as.core/JBoss_5.1_(default)/deploy/wicket-cl-test.war/
domain=classloaderdom...@1e351a2{name=vfsfile:/F:/ade_ws/.metadata/.plugins/org.jboss.ide.eclipse.as.core/JBoss_5.1_(default)/deploy/wicket-cl-test.war/
parentPolicy=AFTER_BUT_JAVA_BEFORE
parent=classloaderdom...@4d41e2{defaultdomain}} roots=[..,
delegatinghand...@8305721[path=wicket-cl-test.war/WEB-INF/lib/wicket.jar
context=file:/F:/ade_ws/.metadata/.plugins/org.jboss.ide.eclipse.as.core/JBoss_5.1_(default)/deploy/
real=file:/F:/ade_ws/.metadata/.plugins/org.jboss.ide.eclipse.as.core/JBoss_5.1_(default)/deploy/wicket-cl-test.war/WEB-INF/lib/wicket.jar]]
delegates=null exported=[, org.apache.wicket.util.diff.myers,
org.apache.wicket.markup.transformer,
org.apache.wicket.authorization.strategies.page,
org.apache.wicket.ajax.form, org.apache.log4j,
org.apache.wicket.util.convert, org.apache.wicket.util.resource,
org.apache.wicket.authorization.strategies, org.apache.log4j.lf5.config,
org.apache.log4j.spi, org.apache.wicket.protocol.http.servlet,
org.apache.wicket.markup.resolver,
org.apache.wicket.request.target.resource,
org.apache.wicket.util.parse.metapattern,
] NON_EMPTY}}
at
org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:448)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
... 72 more
On 20/3/2010 10:25 μμ, Igor Vaynberg wrote:
interesting, wonder why the class would be unloaded *before* the
application classloader.
try this, add a field private PropertyClassResolver resolver=null; to
your application subclass, see if the field is enough to stop the
class from unloading.
-igor
On Sat, Mar 20, 2010 at 9:06 AM, Alexandros Karypidis wrote:
Hi,
I'm having problems with deployment/undeployment of Wicket apps on Tomcat
(and also JBoss, though I think it's related to the fact that it embeds
Tomcat). Basically, in both cases undeployment comes back with an Exception,
leaving the server in a "dirty" state and I have to restart the server every
time. This has been mentioned in both the user and developer lists, but with
no reply:
http://old.nabble.com/java.lang.NoClassDefFoundError:-org-apache-wicket-util-lang-PropertyResolver-tc26191924.html
http://old.nabble.com/Weird-error-on-shutdown...-td18907685.html
The problem manifests only when deploying EXPLODED wars (with a single
packaged WAR file, the problem goes away). It can be easily reproduced as
follows:
1) Create an instance of the quickstart archetype
(http://wicket.apache.org/quickstart.html). Let's say you used the default
values so the artifact id is "myproject" from here on. Use the latest 1.4.7
version of Wicket (though I've tried with all previous versions up to 1.4.4
and the result is the same; the reference above uses version 1.4-m2, so it
must be surprisingly old).
2) Create an EXPLODED web archive (war) with "mvn war:exploded"
3) Move the exploded war folder (myproject-1.0-SNAPSHOT) to the deployment
folder ("server/xxx/deploy" for JBoss or "webapps")
4) Undeploy by moving the exploded war folder (myproject-1.0-SNAPSHOT), OUT
of the deployment folder
You will get a stack trace that basically ends up in a ClassNotFound
exception when the Wicket filter is cleaning up:
java.lang.NoClassDefFoundError: org/apache/wicket/util/lang/PropertyResolver
at org.apache.wicket.Application.internalDestroy(Application.java:952)
at
org.apache.wicket.protocol.http.WebApplication.internalDestroy(WebApplication.java:527)
at
org.apache.wicket.protocol.http.WicketFilter.destroy(Wicke
Re: (Un-)deployment woes on Tomcat (and JBoss)
interesting, wonder why the class would be unloaded *before* the
application classloader.
try this, add a field private PropertyClassResolver resolver=null; to
your application subclass, see if the field is enough to stop the
class from unloading.
-igor
On Sat, Mar 20, 2010 at 9:06 AM, Alexandros Karypidis wrote:
> Hi,
>
> I'm having problems with deployment/undeployment of Wicket apps on Tomcat
> (and also JBoss, though I think it's related to the fact that it embeds
> Tomcat). Basically, in both cases undeployment comes back with an Exception,
> leaving the server in a "dirty" state and I have to restart the server every
> time. This has been mentioned in both the user and developer lists, but with
> no reply:
>
> http://old.nabble.com/java.lang.NoClassDefFoundError:-org-apache-wicket-util-lang-PropertyResolver-tc26191924.html
> http://old.nabble.com/Weird-error-on-shutdown...-td18907685.html
>
> The problem manifests only when deploying EXPLODED wars (with a single
> packaged WAR file, the problem goes away). It can be easily reproduced as
> follows:
>
> 1) Create an instance of the quickstart archetype
> (http://wicket.apache.org/quickstart.html). Let's say you used the default
> values so the artifact id is "myproject" from here on. Use the latest 1.4.7
> version of Wicket (though I've tried with all previous versions up to 1.4.4
> and the result is the same; the reference above uses version 1.4-m2, so it
> must be surprisingly old).
> 2) Create an EXPLODED web archive (war) with "mvn war:exploded"
> 3) Move the exploded war folder (myproject-1.0-SNAPSHOT) to the deployment
> folder ("server/xxx/deploy" for JBoss or "webapps")
> 4) Undeploy by moving the exploded war folder (myproject-1.0-SNAPSHOT), OUT
> of the deployment folder
>
> You will get a stack trace that basically ends up in a ClassNotFound
> exception when the Wicket filter is cleaning up:
>
> java.lang.NoClassDefFoundError: org/apache/wicket/util/lang/PropertyResolver
> at org.apache.wicket.Application.internalDestroy(Application.java:952)
> at
> org.apache.wicket.protocol.http.WebApplication.internalDestroy(WebApplication.java:527)
> at
> org.apache.wicket.protocol.http.WicketFilter.destroy(WicketFilter.java:179)
> at
> org.apache.catalina.core.ApplicationFilterConfig.release(ApplicationFilterConfig.java:267)
>
>
> This is a huge annoyance, because re-deployment of the application does not
> work; if you try to deploy it again, JBoss fails with:
>
> org.jboss.deployers.spi.DeploymentException: Web mapping already exists for
> deployment URL
> file:/F:/ade_ws/.metadata/.plugins/org.jboss.ide.eclipse.as.core/JBoss_5.1_(default)/deploy/myproject-1.0-SNAPSHOT/
> at
> org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:187)
>
> Basically, you must restart the entire JBoss server. In a production
> environment it means you can't upgrade your wicket applications without
> affecting other applications (though you can get away if you don't use an
> exploded WAR folder). In a developer environment it's totally
> counter-productive: you need the exploded format and restaring JBoss every
> time is quite irritating. The Eclipse WTP adapter runs in "exploded" mode
> which basically makes working with Eclipse a nightmare.
>
> I am using JDK1.6 (I use 1.6.0_18) and either JBoss5.1 or Tomcat 6.0.26 (or
> 6.0.18 or 5.5.28 which I also tried). My system is running Windows 7 and
> NTFS (it may be relevant to the way the file-system handles moving folders).
>
> Last notes:
>
> 1) I had a look at the code. It seems that Wicket tries to use weak
> references to facilitate a thorough clean-up of the JVM by garbage
> collection after the application is undeployed. This may be related, as it
> appears to me as if the class loader used by the application is no longer
> available during clean-up. I think there's some class-loading magic going
> on, probably the thread's context class loader is being switched, which ends
> up in the destroy() method not having access to wicket.
>
> 2) Jetty does not seem to have any problems, so it must be something in the
> way Tomcat works.
>
> 3) The complete stack trace in my case (Win7, JDK1.6.0_18-win32, JBoss5.1,
> Wicket1.4.7) is:
> java.lang.NoClassDefFoundError: org/apache/wicket/util/lang/PropertyResolver
> at org.apache.wicket.Application.internalDestroy(Application.java:952)
> at
> org.apache.wicket.protocol.http.WebApplication.internalDestroy(WebApplication.java:527)
> at
> org.apache.wicket.protocol.http.WicketFilter.destroy(WicketFilter.java:179)
> at
> org.apache.catalina.core.ApplicationFilterConfig.release(ApplicationFilterConfig.java:267)
> at
> org.apache.catalina.core.StandardContext.filterStop(StandardContext.java:3818)
> at
> org.apache.catalina.core.StandardContext.stop(StandardContext.java:4605)
> at
> org.apache.catalina.core.ContainerBase.destroy(ContainerBase.java:1175)
> at
> org.apache.catalina.core.Standard
Re: (Un-)deployment woes on Tomcat (and JBoss)
I often have the same problem and symptom in my dev Tomcat, forcing me te
restart it.
On Sat, Mar 20, 2010 at 5:06 PM, Alexandros Karypidis wrote:
> Hi,
>
> I'm having problems with deployment/undeployment of Wicket apps on Tomcat
> (and also JBoss, though I think it's related to the fact that it embeds
> Tomcat). Basically, in both cases undeployment comes back with an Exception,
> leaving the server in a "dirty" state and I have to restart the server every
> time. This has been mentioned in both the user and developer lists, but with
> no reply:
>
>
> http://old.nabble.com/java.lang.NoClassDefFoundError:-org-apache-wicket-util-lang-PropertyResolver-tc26191924.html
> http://old.nabble.com/Weird-error-on-shutdown...-td18907685.html
>
> The problem manifests only when deploying EXPLODED wars (with a single
> packaged WAR file, the problem goes away). It can be easily reproduced as
> follows:
>
> 1) Create an instance of the quickstart archetype (
> http://wicket.apache.org/quickstart.html). Let's say you used the default
> values so the artifact id is "myproject" from here on. Use the latest 1.4.7
> version of Wicket (though I've tried with all previous versions up to 1.4.4
> and the result is the same; the reference above uses version 1.4-m2, so it
> must be surprisingly old).
> 2) Create an EXPLODED web archive (war) with "mvn war:exploded"
> 3) Move the exploded war folder (myproject-1.0-SNAPSHOT) to the deployment
> folder ("server/xxx/deploy" for JBoss or "webapps")
> 4) Undeploy by moving the exploded war folder (myproject-1.0-SNAPSHOT), OUT
> of the deployment folder
>
> You will get a stack trace that basically ends up in a ClassNotFound
> exception when the Wicket filter is cleaning up:
>
> java.lang.NoClassDefFoundError:
> org/apache/wicket/util/lang/PropertyResolver
>at org.apache.wicket.Application.internalDestroy(Application.java:952)
>at
> org.apache.wicket.protocol.http.WebApplication.internalDestroy(WebApplication.java:527)
>at
> org.apache.wicket.protocol.http.WicketFilter.destroy(WicketFilter.java:179)
>at
> org.apache.catalina.core.ApplicationFilterConfig.release(ApplicationFilterConfig.java:267)
>
>
> This is a huge annoyance, because re-deployment of the application does not
> work; if you try to deploy it again, JBoss fails with:
>
> org.jboss.deployers.spi.DeploymentException: Web mapping already exists for
> deployment URL
> file:/F:/ade_ws/.metadata/.plugins/org.jboss.ide.eclipse.as.core/JBoss_5.1_(default)/deploy/myproject-1.0-SNAPSHOT/
>at
> org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:187)
>
> Basically, you must restart the entire JBoss server. In a production
> environment it means you can't upgrade your wicket applications without
> affecting other applications (though you can get away if you don't use an
> exploded WAR folder). In a developer environment it's totally
> counter-productive: you need the exploded format and restaring JBoss every
> time is quite irritating. The Eclipse WTP adapter runs in "exploded" mode
> which basically makes working with Eclipse a nightmare.
>
> I am using JDK1.6 (I use 1.6.0_18) and either JBoss5.1 or Tomcat 6.0.26 (or
> 6.0.18 or 5.5.28 which I also tried). My system is running Windows 7 and
> NTFS (it may be relevant to the way the file-system handles moving folders).
>
> Last notes:
>
> 1) I had a look at the code. It seems that Wicket tries to use weak
> references to facilitate a thorough clean-up of the JVM by garbage
> collection after the application is undeployed. This may be related, as it
> appears to me as if the class loader used by the application is no longer
> available during clean-up. I think there's some class-loading magic going
> on, probably the thread's context class loader is being switched, which ends
> up in the destroy() method not having access to wicket.
>
> 2) Jetty does not seem to have any problems, so it must be something in the
> way Tomcat works.
>
> 3) The complete stack trace in my case (Win7, JDK1.6.0_18-win32, JBoss5.1,
> Wicket1.4.7) is:
> java.lang.NoClassDefFoundError:
> org/apache/wicket/util/lang/PropertyResolver
>at org.apache.wicket.Application.internalDestroy(Application.java:952)
>at
> org.apache.wicket.protocol.http.WebApplication.internalDestroy(WebApplication.java:527)
>at
> org.apache.wicket.protocol.http.WicketFilter.destroy(WicketFilter.java:179)
>at
> org.apache.catalina.core.ApplicationFilterConfig.release(ApplicationFilterConfig.java:267)
>at
> org.apache.catalina.core.StandardContext.filterStop(StandardContext.java:3818)
>at
> org.apache.catalina.core.StandardContext.stop(StandardContext.java:4605)
>at
> org.apache.catalina.core.ContainerBase.destroy(ContainerBase.java:1175)
>at
> org.apache.catalina.core.StandardContext.destroy(StandardContext.java:4705)
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>at
> sun.reflect.NativeMethodAccessorImpl.inv
