-
Bug
-
Resolution: Fixed
-
P4
-
1.4.2
-
b38
-
generic
-
generic
-
Not verified
We have the following problem:
Add an application on the WAS server
Start and stop the application
Within the application register Editor via java.bean.PropertyEditorManager.register Method.
Keep monitoring the Perm Space.
Once the perm space is getting filled to its max
Get HeapDumps
From HeapDumps its clear that Editor objects are holding reference to CompoundClass Loader and due to which perm space is getting depleted.
The basic aim for raising this bug is to request
1> To have a separate API to de-register the Editor instead of reusing the same registerEditior Method of de-registeration.
From the present api docs, its very unclear that user has to de-register the editors using the same method.
2> To make the API specification document correct stating that user has to remove the unwanted and unused Editor's via the separate method provided for de-registeration.
The PropertyEditorManager documentation does not make any recommendation with respect to situations requiring deregistration, nor does it discuss classloaders since unwanted Editor objects are holding the classloader loaded those objects and the JVM cannot not automatically remove the objects from the list. Hence we need to clearly state in the API document that users have to take care of removing unwanted Editor from the registered list.
Add an application on the WAS server
Start and stop the application
Within the application register Editor via java.bean.PropertyEditorManager.register Method.
Keep monitoring the Perm Space.
Once the perm space is getting filled to its max
Get HeapDumps
From HeapDumps its clear that Editor objects are holding reference to CompoundClass Loader and due to which perm space is getting depleted.
The basic aim for raising this bug is to request
1> To have a separate API to de-register the Editor instead of reusing the same registerEditior Method of de-registeration.
From the present api docs, its very unclear that user has to de-register the editors using the same method.
2> To make the API specification document correct stating that user has to remove the unwanted and unused Editor's via the separate method provided for de-registeration.
The PropertyEditorManager documentation does not make any recommendation with respect to situations requiring deregistration, nor does it discuss classloaders since unwanted Editor objects are holding the classloader loaded those objects and the JVM cannot not automatically remove the objects from the list. Hence we need to clearly state in the API document that users have to take care of removing unwanted Editor from the registered list.
- relates to
-
JDK-4809008 Introspector cache should be cleared without explicit flush methods calls
-
- Resolved
-