[
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.
