You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Alexandros Karypidis <ak...@yahoo.gr> on 2010/03/20 17:06:11 UTC
(Un-)deployment woes on Tomcat (and JBoss)
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: (Un-)deployment woes on Tomcat (and JBoss)
Posted by Pierre Goupil <go...@gmail.com>.
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 <ak...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Les deux règles universelles du bide :
1) on n'explique pas un bide
2) dans le futur, un bide sera toujours un bide.
Re: (Un-)deployment woes on Tomcat (and JBoss)
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <ak...@yahoo.gr> 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
>> BaseClassLoader@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=ClassLoaderDomain@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=ClassLoaderDomain@4d41e2{DefaultDomain}} roots=[..........,
>> DelegatingHandler@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, ................................]
>> <IMPORT-ALL>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<ak...@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-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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: (Un-)deployment woes on Tomcat (and JBoss)
Posted by Alexandros Karypidis <ak...@yahoo.gr>.
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
> BaseClassLoader@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=ClassLoaderDomain@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=ClassLoaderDomain@4d41e2{DefaultDomain}} roots=[..........,
> DelegatingHandler@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,
> ................................] <IMPORT-ALL>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<ak...@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-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: (Un-)deployment woes on Tomcat (and JBoss)
Posted by Alexandros Karypidis <ak...@yahoo.gr>.
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
BaseClassLoader@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=ClassLoaderDomain@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=ClassLoaderDomain@4d41e2{DefaultDomain}} roots=[..........,
DelegatingHandler@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,
................................] <IMPORT-ALL>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<ak...@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-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: (Un-)deployment woes on Tomcat (and JBoss)
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <ak...@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-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