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 <akary...@yahoo.gr> 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.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:297) > at > org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164) > at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668) > at > org.jboss.web.tomcat.service.deployers.TomcatDeployment.performUndeployInternal(TomcatDeployment.java:596) > at > org.jboss.web.tomcat.service.deployers.TomcatDeployment.performUndeploy(TomcatDeployment.java:570) > at > org.jboss.web.deployers.AbstractWarDeployment.stop(AbstractWarDeployment.java:480) > at org.jboss.web.deployers.WebModule.stopModule(WebModule.java:133) > at org.jboss.web.deployers.WebModule.stop(WebModule.java:102) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) > at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) > at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) > at > org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) > at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668) > at > org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206) > at $Proxy38.stop(Unknown Source) > at > org.jboss.system.microcontainer.StartStopLifecycleAction.uninstallAction(StartStopLifecycleAction.java:56) > at > org.jboss.system.microcontainer.StartStopLifecycleAction.uninstallAction(StartStopLifecycleAction.java:37) > at > org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleUninstallAction(SimpleControllerContextAction.java:79) > at > org.jboss.dependency.plugins.action.AccessControllerContextAction.uninstall(AccessControllerContextAction.java:131) > at > org.jboss.dependency.plugins.AbstractControllerContextActions.uninstall(AbstractControllerContextActions.java:58) > at > org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:354) > at > org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:1664) > at > org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1275) > at > org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:827) > at > org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553) > at > org.jboss.system.ServiceController.doChange(ServiceController.java:688) > at org.jboss.system.ServiceController.stop(ServiceController.java:510) > at > org.jboss.system.deployers.ServiceDeployer.stop(ServiceDeployer.java:170) > at > org.jboss.system.deployers.ServiceDeployer.undeploy(ServiceDeployer.java:150) > at > org.jboss.system.deployers.ServiceDeployer.undeploy(ServiceDeployer.java:46) > at > org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalUndeploy(AbstractSimpleRealDeployer.java:69) > at > org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.undeploy(AbstractRealDeployer.java:112) > at > org.jboss.deployers.plugins.deployers.DeployerWrapper.undeploy(DeployerWrapper.java:196) > at > org.jboss.deployers.plugins.deployers.DeployersImpl.doUndeploy(DeployersImpl.java:1469) > at > org.jboss.deployers.plugins.deployers.DeployersImpl.doUninstallParentLast(DeployersImpl.java:1376) > at > org.jboss.deployers.plugins.deployers.DeployersImpl.doUninstallParentLast(DeployersImpl.java:1369) > at > org.jboss.deployers.plugins.deployers.DeployersImpl.uninstall(DeployersImpl.java:1331) > at > org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:354) > at > org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:1664) > at > org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1275) > at > org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:827) > at > org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553) > at > org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:694) > at > org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:679) > at > org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117) > at > org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:362) > at > org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:255) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) > at > java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:619) > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
