You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Alastair Maw (JIRA)" <ji...@apache.org> on 2007/06/07 17:52:26 UTC
[jira] Created: (WICKET-625) Wicket doesn't clean up properly when
hot-deploying; hangs onto Class references.
Wicket doesn't clean up properly when hot-deploying; hangs onto Class references.
---------------------------------------------------------------------------------
Key: WICKET-625
URL: https://issues.apache.org/jira/browse/WICKET-625
Project: Wicket
Issue Type: Bug
Components: wicket, wicket-extensions, wicket-spring
Affects Versions: 1.3.0-beta1
Reporter: Alastair Maw
Assignee: Alastair Maw
When you undeploy a webapp, ideally it should go away and its WebAppClassLoader should be garbage collected. There are various reasons this won't happen, but they essentially split into two problems:
1) The App Server has references to classes in the WebAppClassLoader in its own objects (on Tomcat these are typically commons logging statics in StandardContext in catalina, or some of the jakarta code). There's not much you can do about this, short of getting a better app server.
2) You hold references to Class objects loaded by your WebAppClassLoader in static fields in other Classes loaded by your WebAppClassLoader.
Number 2 can be solved by the use of WeakReferences to the Class objects.
Note that you also need to be careful about classes that have Class references internally, such as java.lang.reflect.Method and Field. You can also hold these items in a WeakReference, but they have the potential to be garbage collected randomly, unlike the underlying Class objects.
I have some patches that allow me to start up and shut down a Spring-backed Wicket-based app and have the classloader cope properly. They could probably do with some review.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-625) Wicket doesn't clean up properly
when hot-deploying; hangs onto Class references.
Posted by "Alastair Maw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505934 ]
Alastair Maw commented on WICKET-625:
-------------------------------------
Added cache clean-up on per-application basis for PropertyResolver.
> Wicket doesn't clean up properly when hot-deploying; hangs onto Class references.
> ---------------------------------------------------------------------------------
>
> Key: WICKET-625
> URL: https://issues.apache.org/jira/browse/WICKET-625
> Project: Wicket
> Issue Type: Bug
> Components: wicket, wicket-extensions, wicket-spring
> Affects Versions: 1.3.0-beta1
> Reporter: Alastair Maw
> Assignee: Alastair Maw
> Attachments: WICKET-625.patch
>
>
> When you undeploy a webapp, ideally it should go away and its WebAppClassLoader should be garbage collected. There are various reasons this won't happen, but they essentially split into two problems:
> 1) The App Server has references to classes in the WebAppClassLoader in its own objects (on Tomcat these are typically commons logging statics in StandardContext in catalina, or some of the jakarta code). There's not much you can do about this, short of getting a better app server.
> 2) You hold references to Class objects loaded by your WebAppClassLoader in static fields in other Classes loaded by your WebAppClassLoader.
> Number 2 can be solved by the use of WeakReferences to the Class objects.
> Note that you also need to be careful about classes that have Class references internally, such as java.lang.reflect.Method and Field. You can also hold these items in a WeakReference, but they have the potential to be garbage collected randomly, unlike the underlying Class objects.
> I have some patches that allow me to start up and shut down a Spring-backed Wicket-based app and have the classloader cope properly. They could probably do with some review.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-625) Wicket doesn't clean up properly
when hot-deploying; hangs onto Class references.
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12507704 ]
Igor Vaynberg commented on WICKET-625:
--------------------------------------
here is another thing you might want to look into, if wicket is deployed and undeployed without any url hit you get
RROR - log - failed wicket
org.apache.wicket.WicketRuntimeException: There is no application attached to current thread main
at org.apache.wicket.Application.get(Application.java:170)
at org.apache.wicket.markup.MarkupCache.<init>(MarkupCache.java:80)
at org.apache.wicket.settings.Settings.getMarkupCache(Settings.java:1258)
at org.apache.wicket.Application.internalDestroy(Application.java:827)
at org.apache.wicket.protocol.http.WebApplication.internalDestroy(WebApplication.java:495)
at org.apache.wicket.protocol.http.WicketFilter.destroy(WicketFilter.java:104)
at org.mortbay.jetty.servlet.FilterHolder.doStop(FilterHolder.java:102)
at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:65)
at org.mortbay.jetty.servlet.ServletHandler.doStop(ServletHandler.java:162)
at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:65)
at org.mortbay.jetty.handler.HandlerWrapper.doStop(HandlerWrapper.java:131)
at org.mortbay.jetty.servlet.SessionHandler.doStop(SessionHandler.java:124)
at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:65)
at org.mortbay.jetty.handler.HandlerWrapper.doStop(HandlerWrapper.java:131)
at org.mortbay.jetty.handler.ContextHandler.doStop(ContextHandler.java:477)
at org.mortbay.jetty.webapp.WebAppContext.doStop(WebAppContext.java:513)
at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:65)
at org.mortbay.jetty.handler.HandlerWrapper.doStop(HandlerWrapper.java:131)
at org.mortbay.jetty.Server.doStop(Server.java:260)
at org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:65)
at com.tbs.webapp.StartTbs.main(StartTbs.java:29)
> Wicket doesn't clean up properly when hot-deploying; hangs onto Class references.
> ---------------------------------------------------------------------------------
>
> Key: WICKET-625
> URL: https://issues.apache.org/jira/browse/WICKET-625
> Project: Wicket
> Issue Type: Bug
> Components: wicket, wicket-extensions, wicket-spring
> Affects Versions: 1.3.0-beta1
> Reporter: Alastair Maw
> Assignee: Alastair Maw
> Attachments: WICKET-625.patch
>
>
> When you undeploy a webapp, ideally it should go away and its WebAppClassLoader should be garbage collected. There are various reasons this won't happen, but they essentially split into two problems:
> 1) The App Server has references to classes in the WebAppClassLoader in its own objects (on Tomcat these are typically commons logging statics in StandardContext in catalina, or some of the jakarta code). There's not much you can do about this, short of getting a better app server.
> 2) You hold references to Class objects loaded by your WebAppClassLoader in static fields in other Classes loaded by your WebAppClassLoader.
> Number 2 can be solved by the use of WeakReferences to the Class objects.
> Note that you also need to be careful about classes that have Class references internally, such as java.lang.reflect.Method and Field. You can also hold these items in a WeakReference, but they have the potential to be garbage collected randomly, unlike the underlying Class objects.
> I have some patches that allow me to start up and shut down a Spring-backed Wicket-based app and have the classloader cope properly. They could probably do with some review.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-625) Wicket doesn't clean up properly
when hot-deploying; hangs onto Class references.
Posted by "Alastair Maw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505787 ]
Alastair Maw commented on WICKET-625:
-------------------------------------
I've now put in a bunch of fixes for this, such that we're probably 80% of the way there. This is the easy 80%, mind you. ;-)
The remaining things are harder to fix, as they mostly references Methods not classes.
> Wicket doesn't clean up properly when hot-deploying; hangs onto Class references.
> ---------------------------------------------------------------------------------
>
> Key: WICKET-625
> URL: https://issues.apache.org/jira/browse/WICKET-625
> Project: Wicket
> Issue Type: Bug
> Components: wicket, wicket-extensions, wicket-spring
> Affects Versions: 1.3.0-beta1
> Reporter: Alastair Maw
> Assignee: Alastair Maw
> Attachments: WICKET-625.patch
>
>
> When you undeploy a webapp, ideally it should go away and its WebAppClassLoader should be garbage collected. There are various reasons this won't happen, but they essentially split into two problems:
> 1) The App Server has references to classes in the WebAppClassLoader in its own objects (on Tomcat these are typically commons logging statics in StandardContext in catalina, or some of the jakarta code). There's not much you can do about this, short of getting a better app server.
> 2) You hold references to Class objects loaded by your WebAppClassLoader in static fields in other Classes loaded by your WebAppClassLoader.
> Number 2 can be solved by the use of WeakReferences to the Class objects.
> Note that you also need to be careful about classes that have Class references internally, such as java.lang.reflect.Method and Field. You can also hold these items in a WeakReference, but they have the potential to be garbage collected randomly, unlike the underlying Class objects.
> I have some patches that allow me to start up and shut down a Spring-backed Wicket-based app and have the classloader cope properly. They could probably do with some review.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-625) Wicket doesn't clean up properly when
hot-deploying; hangs onto Class references.
Posted by "Alastair Maw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alastair Maw updated WICKET-625:
--------------------------------
Attachment: WICKET-625.patch
The attached patch works.
We need some way to fix the SoftReference stuff better (we should manually clear these caches, I think).
> Wicket doesn't clean up properly when hot-deploying; hangs onto Class references.
> ---------------------------------------------------------------------------------
>
> Key: WICKET-625
> URL: https://issues.apache.org/jira/browse/WICKET-625
> Project: Wicket
> Issue Type: Bug
> Components: wicket, wicket-extensions, wicket-spring
> Affects Versions: 1.3.0-beta1
> Reporter: Alastair Maw
> Assignee: Alastair Maw
> Attachments: WICKET-625.patch
>
>
> When you undeploy a webapp, ideally it should go away and its WebAppClassLoader should be garbage collected. There are various reasons this won't happen, but they essentially split into two problems:
> 1) The App Server has references to classes in the WebAppClassLoader in its own objects (on Tomcat these are typically commons logging statics in StandardContext in catalina, or some of the jakarta code). There's not much you can do about this, short of getting a better app server.
> 2) You hold references to Class objects loaded by your WebAppClassLoader in static fields in other Classes loaded by your WebAppClassLoader.
> Number 2 can be solved by the use of WeakReferences to the Class objects.
> Note that you also need to be careful about classes that have Class references internally, such as java.lang.reflect.Method and Field. You can also hold these items in a WeakReference, but they have the potential to be garbage collected randomly, unlike the underlying Class objects.
> I have some patches that allow me to start up and shut down a Spring-backed Wicket-based app and have the classloader cope properly. They could probably do with some review.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-625) Wicket doesn't clean up properly
when hot-deploying; hangs onto Class references.
Posted by "Alastair Maw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12507709 ]
Alastair Maw commented on WICKET-625:
-------------------------------------
Thanks. Sorted.
> Wicket doesn't clean up properly when hot-deploying; hangs onto Class references.
> ---------------------------------------------------------------------------------
>
> Key: WICKET-625
> URL: https://issues.apache.org/jira/browse/WICKET-625
> Project: Wicket
> Issue Type: Bug
> Components: wicket, wicket-extensions, wicket-spring
> Affects Versions: 1.3.0-beta1
> Reporter: Alastair Maw
> Assignee: Alastair Maw
> Attachments: WICKET-625.patch
>
>
> When you undeploy a webapp, ideally it should go away and its WebAppClassLoader should be garbage collected. There are various reasons this won't happen, but they essentially split into two problems:
> 1) The App Server has references to classes in the WebAppClassLoader in its own objects (on Tomcat these are typically commons logging statics in StandardContext in catalina, or some of the jakarta code). There's not much you can do about this, short of getting a better app server.
> 2) You hold references to Class objects loaded by your WebAppClassLoader in static fields in other Classes loaded by your WebAppClassLoader.
> Number 2 can be solved by the use of WeakReferences to the Class objects.
> Note that you also need to be careful about classes that have Class references internally, such as java.lang.reflect.Method and Field. You can also hold these items in a WeakReference, but they have the potential to be garbage collected randomly, unlike the underlying Class objects.
> I have some patches that allow me to start up and shut down a Spring-backed Wicket-based app and have the classloader cope properly. They could probably do with some review.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-625) Wicket doesn't clean up properly
when hot-deploying; hangs onto Class references.
Posted by "Johan Compagner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502528 ]
Johan Compagner commented on WICKET-625:
----------------------------------------
i think we have more class problems that we should solve
i already reported that once on the dev list: "PackageResource and ResourceReferences keeping a class reference"
also the DefaultClassResolver is maybe not something we should do..
> Wicket doesn't clean up properly when hot-deploying; hangs onto Class references.
> ---------------------------------------------------------------------------------
>
> Key: WICKET-625
> URL: https://issues.apache.org/jira/browse/WICKET-625
> Project: Wicket
> Issue Type: Bug
> Components: wicket, wicket-extensions, wicket-spring
> Affects Versions: 1.3.0-beta1
> Reporter: Alastair Maw
> Assignee: Alastair Maw
> Attachments: WICKET-625.patch
>
>
> When you undeploy a webapp, ideally it should go away and its WebAppClassLoader should be garbage collected. There are various reasons this won't happen, but they essentially split into two problems:
> 1) The App Server has references to classes in the WebAppClassLoader in its own objects (on Tomcat these are typically commons logging statics in StandardContext in catalina, or some of the jakarta code). There's not much you can do about this, short of getting a better app server.
> 2) You hold references to Class objects loaded by your WebAppClassLoader in static fields in other Classes loaded by your WebAppClassLoader.
> Number 2 can be solved by the use of WeakReferences to the Class objects.
> Note that you also need to be careful about classes that have Class references internally, such as java.lang.reflect.Method and Field. You can also hold these items in a WeakReference, but they have the potential to be garbage collected randomly, unlike the underlying Class objects.
> I have some patches that allow me to start up and shut down a Spring-backed Wicket-based app and have the classloader cope properly. They could probably do with some review.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-625) Wicket doesn't clean up properly
when hot-deploying; hangs onto Class references.
Posted by "Alastair Maw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502445 ]
Alastair Maw commented on WICKET-625:
-------------------------------------
Note some complexities:
WeakReference is not Serializable and never will be (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4217372). I'm therefore replacing current Class references with the equivalent Class.getName(), which should be fine for our purposes.
> Wicket doesn't clean up properly when hot-deploying; hangs onto Class references.
> ---------------------------------------------------------------------------------
>
> Key: WICKET-625
> URL: https://issues.apache.org/jira/browse/WICKET-625
> Project: Wicket
> Issue Type: Bug
> Components: wicket, wicket-extensions, wicket-spring
> Affects Versions: 1.3.0-beta1
> Reporter: Alastair Maw
> Assignee: Alastair Maw
> Attachments: WICKET-625.patch
>
>
> When you undeploy a webapp, ideally it should go away and its WebAppClassLoader should be garbage collected. There are various reasons this won't happen, but they essentially split into two problems:
> 1) The App Server has references to classes in the WebAppClassLoader in its own objects (on Tomcat these are typically commons logging statics in StandardContext in catalina, or some of the jakarta code). There's not much you can do about this, short of getting a better app server.
> 2) You hold references to Class objects loaded by your WebAppClassLoader in static fields in other Classes loaded by your WebAppClassLoader.
> Number 2 can be solved by the use of WeakReferences to the Class objects.
> Note that you also need to be careful about classes that have Class references internally, such as java.lang.reflect.Method and Field. You can also hold these items in a WeakReference, but they have the potential to be garbage collected randomly, unlike the underlying Class objects.
> I have some patches that allow me to start up and shut down a Spring-backed Wicket-based app and have the classloader cope properly. They could probably do with some review.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.