[jira] Issue Comment Edited: (WICKET-625) Wicket doesn't clean up properly when hot-deploying; hangs onto Class references.

["Daniel Stoch (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/WICKET-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12737489#action_12737489 ] 

Daniel Stoch edited comment on WICKET-625 at 7/31/09 4:51 AM:
--------------------------------------------------------------

I think the problem still exists in Injector class (in 1.4), so this issue should be reopened. There is classToFields field with "FIXME: WICKET-625..." comment :), which is used to cache fields to inject for specified class. This map is not cleaned up when hot-deploying.
The patch attached above removes this map (cache), but it has not been applied and I think it is ok, because removing this cache could drastically degrade performance.

My proposal is to use a solution described in this article: http://weblogs.java.net/blog/jhook/archive/2006/12/class_metadata.html
and define classToFields field as a:
WeakHashMap<ClassLoader, ConcurrentHashMap<String, ClassMetaData>>
where a ClassLoader key will be a class loader of injected object's class. When we will use ClassLoader as the key, then the second map can store class names instead of Class<?> references.

      was (Author: interface):
    I think the problem still exists in Injector class, so this issue should be reopened. There is classToFields field with "FIXME: WICKET-625..." comment :), which is used to cache fields to inject for specified class. This map is not cleaned up when hot-deploying.
The patch attached above removes this map (cache), but it has not been applied and I think it is ok, because removing this cache could drastically degrade performance.

My proposal is to use a solution described in this article: http://weblogs.java.net/blog/jhook/archive/2006/12/class_metadata.html
and define classToFields field as a:
WeakHashMap<ClassLoader, ConcurrentHashMap<String, ClassMetaData>>
where a ClassLoader key will be a class loader of injected object's class. When we will use ClassLoader as the key, then the second map can store class names instead of 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
>             Fix For: 1.3.5
>
>         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.