Details
-
Type:
Bug
-
Status: Resolved
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 5.4.3
-
Fix Version/s: 5.7.0
-
Component/s: None
-
Labels:None
Description
A static block in org.apache.activemq.util.IntrospectionSupport registers org.apache.activemq.util.StringArrayEditor with java.beans.PropertyEditorManager. In a web application environment, this will cause classloader leaks, since java.beans.PropertyEditorManager keeps a strong reference to the editor class.
ActiveMQ should at least provide a graceful means of deregistering org.apache.activemq.util.StringArrayEditor (by calling java.beans.PropertyEditorManager.registerEditor() again with editor class null).
Issue Links
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
The issue would be if people run with multiple AMQ brokers in the same JVM, and hot deploy or uninstall a single broker. Then this would affect existing running brokers as the property editor becomes uninstalled.
In the comment before we hit an issue in the past in Camel, so we no longer use property editors, and they are neither thread safe to use anyway.
AMQ-4011 should fix this problem
Improved the logic to avoid adding the same search paths yet again if AcitveMQ is redeployed.
Okay I have refactored the code to not use StringArrayEditor as a JDK property editor, and thus we dont enlist it to the property editor manager. Which then should fix the leak.
Yeah we hit an issue with AMQ reqistering a javax.jms.Destination property editor that played tricks. IMHO property editors in the JDK should not be used, as they are per JVM, and you can override each others editors etc.