You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xbean-dev@geronimo.apache.org by "Christopher Sahnwaldt (JIRA)" <ji...@apache.org> on 2007/10/18 14:39:50 UTC
[jira] Created: (XBEAN-95) register PropertyEditors locally, not
globally
register PropertyEditors locally, not globally
----------------------------------------------
Key: XBEAN-95
URL: https://issues.apache.org/jira/browse/XBEAN-95
Project: XBean
Issue Type: Bug
Components: spring
Reporter: Christopher Sahnwaldt
org.apache.xbean.spring.context.impl.PropertyEditorHelper registers PropertyEditors for java.io.File, java.net.URI, java.util.Date and javax.management.ObjectName using java.beans.PropertyEditorManager.registerEditor(). This may cause problems:
- the usual problem with global variables: another application running in the same JVM may register a different PropertyEditor, e.g. for java.util.Date. One of the applications will then use the PropertyEditor that was registered by the other application. Which application 'wins' depends on the order of the calls to PropertyEditorManager.registerEditor().
- java.beans.PropertyEditorManager keeps a strong reference to the registered classes. The xbean PropertyEditor classes are loaded by the context class loader, (which is the webapp class loader if running in Tomcat etc.). The class java.beans.PropertyEditorManager is loaded by the bootstrap class loader. This means that there is a strong reference from the bootstrap class loader to the webapp class loader, which means that the webapp class loader cannot be unloaded, which means that the webapp is not garbage collected when it is undeployed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (XBEAN-95) register PropertyEditors
locally, not globally
Posted by "Christopher Sahnwaldt (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/XBEAN-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535910 ]
jcsahnwaldt edited comment on XBEAN-95 at 10/18/07 6:13 AM:
----------------------------------------------------------------------
I think this can be fixed by a small change in org.apache.xbean.spring.context.v2c.XBeanNamespaceHandler.registerCustomEditors().
Current version (SVN revision 517909):
{code}
/**
* Registers whatever custom editors we need
*/
public static void registerCustomEditors(DefaultListableBeanFactory beanFactory) {
PropertyEditorHelper.registerCustomEditors();
}
{code}
New version:
{code}
/**
* Registers whatever custom editors we need
*/
public static void registerCustomEditors(DefaultListableBeanFactory beanFactory) {
PropertyEditorRegistrar registrar =
new PropertyEditorRegistrar()
{
public void registerCustomEditors( PropertyEditorRegistry registry )
{
registry.registerCustomEditor(java.io.File.class, new org.apache.xbean.spring.context.impl.FileEditor());
registry.registerCustomEditor(java.net.URI.class, new org.apache.xbean.spring.context.impl.URIEditor());
registry.registerCustomEditor(java.util.Date.class, new org.apache.xbean.spring.context.impl.DateEditor());
registry.registerCustomEditor(javax.management.ObjectName.class, new org.apache.xbean.spring.context.impl.ObjectNameEditor());
}
};
beanFactory.addPropertyEditorRegistrar(registrar);
}
{code}
Two new imports are needed:
import org.springframework.beans.PropertyEditorRegistrar;
import org.springframework.beans.PropertyEditorRegistry;
PropertyEditorHelper.registerCustomEditors() is also called by the static initializers of org.apache.xbean.spring.context.v2c.XBeanBeanDefinitionParserDelegate and org.apache.xbean.spring.context.v2c.XBeanNamespaceHandler. I would think that these static initializers can simply be removed, but I'm not sure.
was (Author: jcsahnwaldt):
I think this can be fixed by a small change in org.apache.xbean.spring.context.v2c.XBeanNamespaceHandler.registerCustomEditors().
Current version (SVN revision 517909):
/**
* Registers whatever custom editors we need
*/
public static void registerCustomEditors(DefaultListableBeanFactory beanFactory) {
PropertyEditorHelper.registerCustomEditors();
}
New version:
/**
* Registers whatever custom editors we need
*/
public static void registerCustomEditors(DefaultListableBeanFactory beanFactory) {
PropertyEditorRegistrar registrar =
new PropertyEditorRegistrar()
{
public void registerCustomEditors( PropertyEditorRegistry registry )
{
registry.registerCustomEditor(java.io.File.class, new org.apache.xbean.spring.context.impl.FileEditor());
registry.registerCustomEditor(java.net.URI.class, new org.apache.xbean.spring.context.impl.URIEditor());
registry.registerCustomEditor(java.util.Date.class, new org.apache.xbean.spring.context.impl.DateEditor());
registry.registerCustomEditor(javax.management.ObjectName.class, new org.apache.xbean.spring.context.impl.ObjectNameEditor());
}
};
beanFactory.addPropertyEditorRegistrar(registrar);
}
Two new imports are needed:
import org.springframework.beans.PropertyEditorRegistrar;
import org.springframework.beans.PropertyEditorRegistry;
PropertyEditorHelper.registerCustomEditors() is also called by the static initializers of org.apache.xbean.spring.context.v2c.XBeanBeanDefinitionParserDelegate and org.apache.xbean.spring.context.v2c.XBeanNamespaceHandler. I would think that these static initializers can simply be removed, but I'm not sure.
> register PropertyEditors locally, not globally
> ----------------------------------------------
>
> Key: XBEAN-95
> URL: https://issues.apache.org/jira/browse/XBEAN-95
> Project: XBean
> Issue Type: Bug
> Components: spring
> Reporter: Christopher Sahnwaldt
>
> org.apache.xbean.spring.context.impl.PropertyEditorHelper registers PropertyEditors for java.io.File, java.net.URI, java.util.Date and javax.management.ObjectName using java.beans.PropertyEditorManager.registerEditor(). This may cause problems:
> - the usual problem with global variables: another application running in the same JVM may register a different PropertyEditor, e.g. for java.util.Date. One of the applications will then use the PropertyEditor that was registered by the other application. Which application 'wins' depends on the order of the calls to PropertyEditorManager.registerEditor().
> - java.beans.PropertyEditorManager keeps a strong reference to the registered classes. The xbean PropertyEditor classes are loaded by the context class loader, (which is the webapp class loader if running in Tomcat etc.). The class java.beans.PropertyEditorManager is loaded by the bootstrap class loader. This means that there is a strong reference from the bootstrap class loader to the webapp class loader, which means that the webapp class loader cannot be unloaded, which means that the webapp is not garbage collected when it is undeployed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (XBEAN-95) register PropertyEditors locally, not
globally
Posted by "Dain Sundstrom (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/XBEAN-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dain Sundstrom closed XBEAN-95.
-------------------------------
Resolution: Fixed
I applied all of your suggested changes.
> register PropertyEditors locally, not globally
> ----------------------------------------------
>
> Key: XBEAN-95
> URL: https://issues.apache.org/jira/browse/XBEAN-95
> Project: XBean
> Issue Type: Bug
> Components: spring
> Reporter: Christopher Sahnwaldt
> Assignee: Dain Sundstrom
>
> org.apache.xbean.spring.context.impl.PropertyEditorHelper registers PropertyEditors for java.io.File, java.net.URI, java.util.Date and javax.management.ObjectName using java.beans.PropertyEditorManager.registerEditor(). This may cause problems:
> - the usual problem with global variables: another application running in the same JVM may register a different PropertyEditor, e.g. for java.util.Date. One of the applications will then use the PropertyEditor that was registered by the other application. Which application 'wins' depends on the order of the calls to PropertyEditorManager.registerEditor().
> - java.beans.PropertyEditorManager keeps a strong reference to the registered classes. The xbean PropertyEditor classes are loaded by the context class loader, (which is the webapp class loader if running in Tomcat etc.). The class java.beans.PropertyEditorManager is loaded by the bootstrap class loader. This means that there is a strong reference from the bootstrap class loader to the webapp class loader, which means that the webapp class loader cannot be unloaded, which means that the webapp is not garbage collected when it is undeployed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (XBEAN-95) register PropertyEditors locally, not
globally
Posted by "Christopher Sahnwaldt (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/XBEAN-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535914 ]
Christopher Sahnwaldt commented on XBEAN-95:
--------------------------------------------
Here is a workaround to fix the class loader memory leak.
Add the following methods to {{org.apache.xbean.spring.context.impl.PropertyEditorHelper}}:
{code}
public static void unregisterCustomEditors() {
unregisterEditor("java.io.File");
unregisterEditor("java.net.URI");
unregisterEditor("java.util.Date");
unregisterEditor("javax.management.ObjectName");
}
protected static void unregisterEditor(String typeName) {
Class type = loadClass(typeName);
if (type != null) {
PropertyEditorManager.registerEditor(type, null);
}
}
{code}
Call {{PropertyEditorHelper.unregisterCustomEditors()}} when the application is undeployed, for example in an implementation of {{ServletContextListener.contextDestroyed()}}.
> register PropertyEditors locally, not globally
> ----------------------------------------------
>
> Key: XBEAN-95
> URL: https://issues.apache.org/jira/browse/XBEAN-95
> Project: XBean
> Issue Type: Bug
> Components: spring
> Reporter: Christopher Sahnwaldt
>
> org.apache.xbean.spring.context.impl.PropertyEditorHelper registers PropertyEditors for java.io.File, java.net.URI, java.util.Date and javax.management.ObjectName using java.beans.PropertyEditorManager.registerEditor(). This may cause problems:
> - the usual problem with global variables: another application running in the same JVM may register a different PropertyEditor, e.g. for java.util.Date. One of the applications will then use the PropertyEditor that was registered by the other application. Which application 'wins' depends on the order of the calls to PropertyEditorManager.registerEditor().
> - java.beans.PropertyEditorManager keeps a strong reference to the registered classes. The xbean PropertyEditor classes are loaded by the context class loader, (which is the webapp class loader if running in Tomcat etc.). The class java.beans.PropertyEditorManager is loaded by the bootstrap class loader. This means that there is a strong reference from the bootstrap class loader to the webapp class loader, which means that the webapp class loader cannot be unloaded, which means that the webapp is not garbage collected when it is undeployed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (XBEAN-95) register PropertyEditors locally, not
globally
Posted by "Christopher Sahnwaldt (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/XBEAN-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535910 ]
Christopher Sahnwaldt commented on XBEAN-95:
--------------------------------------------
I think this can be fixed by a small change in org.apache.xbean.spring.context.v2c.XBeanNamespaceHandler.registerCustomEditors().
Current version (SVN revision 517909):
/**
* Registers whatever custom editors we need
*/
public static void registerCustomEditors(DefaultListableBeanFactory beanFactory) {
PropertyEditorHelper.registerCustomEditors();
}
New version:
/**
* Registers whatever custom editors we need
*/
public static void registerCustomEditors(DefaultListableBeanFactory beanFactory) {
PropertyEditorRegistrar registrar =
new PropertyEditorRegistrar()
{
public void registerCustomEditors( PropertyEditorRegistry registry )
{
registry.registerCustomEditor(java.io.File.class, new org.apache.xbean.spring.context.impl.FileEditor());
registry.registerCustomEditor(java.net.URI.class, new org.apache.xbean.spring.context.impl.URIEditor());
registry.registerCustomEditor(java.util.Date.class, new org.apache.xbean.spring.context.impl.DateEditor());
registry.registerCustomEditor(javax.management.ObjectName.class, new org.apache.xbean.spring.context.impl.ObjectNameEditor());
}
};
beanFactory.addPropertyEditorRegistrar(registrar);
}
Two new imports are needed:
import org.springframework.beans.PropertyEditorRegistrar;
import org.springframework.beans.PropertyEditorRegistry;
PropertyEditorHelper.registerCustomEditors() is also called by the static initializers of org.apache.xbean.spring.context.v2c.XBeanBeanDefinitionParserDelegate and org.apache.xbean.spring.context.v2c.XBeanNamespaceHandler. I would think that these static initializers can simply be removed, but I'm not sure.
> register PropertyEditors locally, not globally
> ----------------------------------------------
>
> Key: XBEAN-95
> URL: https://issues.apache.org/jira/browse/XBEAN-95
> Project: XBean
> Issue Type: Bug
> Components: spring
> Reporter: Christopher Sahnwaldt
>
> org.apache.xbean.spring.context.impl.PropertyEditorHelper registers PropertyEditors for java.io.File, java.net.URI, java.util.Date and javax.management.ObjectName using java.beans.PropertyEditorManager.registerEditor(). This may cause problems:
> - the usual problem with global variables: another application running in the same JVM may register a different PropertyEditor, e.g. for java.util.Date. One of the applications will then use the PropertyEditor that was registered by the other application. Which application 'wins' depends on the order of the calls to PropertyEditorManager.registerEditor().
> - java.beans.PropertyEditorManager keeps a strong reference to the registered classes. The xbean PropertyEditor classes are loaded by the context class loader, (which is the webapp class loader if running in Tomcat etc.). The class java.beans.PropertyEditorManager is loaded by the bootstrap class loader. This means that there is a strong reference from the bootstrap class loader to the webapp class loader, which means that the webapp class loader cannot be unloaded, which means that the webapp is not garbage collected when it is undeployed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (XBEAN-95) register PropertyEditors
locally, not globally
Posted by "Christopher Sahnwaldt (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/XBEAN-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535910 ]
jcsahnwaldt edited comment on XBEAN-95 at 10/18/07 6:15 AM:
----------------------------------------------------------------------
I think this can be fixed by a small change in {{org.apache.xbean.spring.context.v2c.XBeanNamespaceHandler.registerCustomEditors()}}.
Current version (SVN revision 517909):
{code}
/**
* Registers whatever custom editors we need
*/
public static void registerCustomEditors(DefaultListableBeanFactory beanFactory) {
PropertyEditorHelper.registerCustomEditors();
}
{code}
New version:
{code}
/**
* Registers whatever custom editors we need
*/
public static void registerCustomEditors(DefaultListableBeanFactory beanFactory) {
PropertyEditorRegistrar registrar =
new PropertyEditorRegistrar()
{
public void registerCustomEditors( PropertyEditorRegistry registry )
{
registry.registerCustomEditor(java.io.File.class, new org.apache.xbean.spring.context.impl.FileEditor());
registry.registerCustomEditor(java.net.URI.class, new org.apache.xbean.spring.context.impl.URIEditor());
registry.registerCustomEditor(java.util.Date.class, new org.apache.xbean.spring.context.impl.DateEditor());
registry.registerCustomEditor(javax.management.ObjectName.class, new org.apache.xbean.spring.context.impl.ObjectNameEditor());
}
};
beanFactory.addPropertyEditorRegistrar(registrar);
}
{code}
Two new imports are needed:
{code}
import org.springframework.beans.PropertyEditorRegistrar;
import org.springframework.beans.PropertyEditorRegistry;
{code}
{{PropertyEditorHelper.registerCustomEditors()}} is also called by the static initializers of {{org.apache.xbean.spring.context.v2c.XBeanBeanDefinitionParserDelegate}} and {{org.apache.xbean.spring.context.v2c.XBeanNamespaceHandler}}. I would think that these static initializers can simply be removed, but I'm not sure.
was (Author: jcsahnwaldt):
I think this can be fixed by a small change in org.apache.xbean.spring.context.v2c.XBeanNamespaceHandler.registerCustomEditors().
Current version (SVN revision 517909):
{code}
/**
* Registers whatever custom editors we need
*/
public static void registerCustomEditors(DefaultListableBeanFactory beanFactory) {
PropertyEditorHelper.registerCustomEditors();
}
{code}
New version:
{code}
/**
* Registers whatever custom editors we need
*/
public static void registerCustomEditors(DefaultListableBeanFactory beanFactory) {
PropertyEditorRegistrar registrar =
new PropertyEditorRegistrar()
{
public void registerCustomEditors( PropertyEditorRegistry registry )
{
registry.registerCustomEditor(java.io.File.class, new org.apache.xbean.spring.context.impl.FileEditor());
registry.registerCustomEditor(java.net.URI.class, new org.apache.xbean.spring.context.impl.URIEditor());
registry.registerCustomEditor(java.util.Date.class, new org.apache.xbean.spring.context.impl.DateEditor());
registry.registerCustomEditor(javax.management.ObjectName.class, new org.apache.xbean.spring.context.impl.ObjectNameEditor());
}
};
beanFactory.addPropertyEditorRegistrar(registrar);
}
{code}
Two new imports are needed:
import org.springframework.beans.PropertyEditorRegistrar;
import org.springframework.beans.PropertyEditorRegistry;
PropertyEditorHelper.registerCustomEditors() is also called by the static initializers of org.apache.xbean.spring.context.v2c.XBeanBeanDefinitionParserDelegate and org.apache.xbean.spring.context.v2c.XBeanNamespaceHandler. I would think that these static initializers can simply be removed, but I'm not sure.
> register PropertyEditors locally, not globally
> ----------------------------------------------
>
> Key: XBEAN-95
> URL: https://issues.apache.org/jira/browse/XBEAN-95
> Project: XBean
> Issue Type: Bug
> Components: spring
> Reporter: Christopher Sahnwaldt
>
> org.apache.xbean.spring.context.impl.PropertyEditorHelper registers PropertyEditors for java.io.File, java.net.URI, java.util.Date and javax.management.ObjectName using java.beans.PropertyEditorManager.registerEditor(). This may cause problems:
> - the usual problem with global variables: another application running in the same JVM may register a different PropertyEditor, e.g. for java.util.Date. One of the applications will then use the PropertyEditor that was registered by the other application. Which application 'wins' depends on the order of the calls to PropertyEditorManager.registerEditor().
> - java.beans.PropertyEditorManager keeps a strong reference to the registered classes. The xbean PropertyEditor classes are loaded by the context class loader, (which is the webapp class loader if running in Tomcat etc.). The class java.beans.PropertyEditorManager is loaded by the bootstrap class loader. This means that there is a strong reference from the bootstrap class loader to the webapp class loader, which means that the webapp class loader cannot be unloaded, which means that the webapp is not garbage collected when it is undeployed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (XBEAN-95) register PropertyEditors locally, not
globally
Posted by "Dain Sundstrom (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/XBEAN-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dain Sundstrom reassigned XBEAN-95:
-----------------------------------
Assignee: Dain Sundstrom
> register PropertyEditors locally, not globally
> ----------------------------------------------
>
> Key: XBEAN-95
> URL: https://issues.apache.org/jira/browse/XBEAN-95
> Project: XBean
> Issue Type: Bug
> Components: spring
> Reporter: Christopher Sahnwaldt
> Assignee: Dain Sundstrom
>
> org.apache.xbean.spring.context.impl.PropertyEditorHelper registers PropertyEditors for java.io.File, java.net.URI, java.util.Date and javax.management.ObjectName using java.beans.PropertyEditorManager.registerEditor(). This may cause problems:
> - the usual problem with global variables: another application running in the same JVM may register a different PropertyEditor, e.g. for java.util.Date. One of the applications will then use the PropertyEditor that was registered by the other application. Which application 'wins' depends on the order of the calls to PropertyEditorManager.registerEditor().
> - java.beans.PropertyEditorManager keeps a strong reference to the registered classes. The xbean PropertyEditor classes are loaded by the context class loader, (which is the webapp class loader if running in Tomcat etc.). The class java.beans.PropertyEditorManager is loaded by the bootstrap class loader. This means that there is a strong reference from the bootstrap class loader to the webapp class loader, which means that the webapp class loader cannot be unloaded, which means that the webapp is not garbage collected when it is undeployed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.