Memory Leak when calling @Destroy (with SFSBs) ---------------------------------------------- Key: JBSEAM-4863 URL: https://issues.jboss.org/browse/JBSEAM-4863 Project: Seam 2 Issue Type: Bug Affects Versions: 2.2.2.Final Environment: JBoss AS 5.1.0.GA Reporter: Daniel Lechner Labels: conversation, destroy Fix For: 2.3.0.Final In an example-project, we have 2 Seam components, one POJO and one SFSB. The POJO-component uses the SFSB-component via Seam-DI (@In). The POJO-component has a method annotated with @Destroy. We are using the POJO-component in a (long-running-)conversation. So the POJO-component as well as the SFSB-component will be created within the conversation. When the conversation ends and all components will be removed, the @Destroy-methods of all seam-components are called one after each other. The order, the @Destroy-methods are called, depend on the hashCode of the seam-name of the components (the component-names are put into an java.util.HashSet in the method org.jboss.seam.contexts.ServerConversationContext.getNamesFromSession() - the for-loop of the method org.jboss.seam.contexts.Contexts.destroy iterates through this HashSet afterwards). If the component-names are chosen this way, that the SFSB-component will be removed before the POJO-component is removed, a memory leak occurs: 1. the SFSB-component is destroyed by seam - the container removes the SFSB (the @Remove-method of the SFSB is called) 2. the @Destroy-method of the POJO-component is called. But before, Seam-DI creates a new SFSB-component TestEJB because of the @In-annotation 3. the POJO-component is removed from the conversation (and later by the GC) 4. the SFSB-component's @Remove-method is not called again - the container keeps the SFSB-instance An example-code can be found in the forum reference

Memory Leak when calling @Destroy (with SFSBs) ---------------------------------------------- Key: JBSEAM-4863 URL: https://issues.jboss.org/browse/JBSEAM-4863 Project: Seam 2 Issue Type: Bug Affects Versions: 2.2.2.Final Environment: JBoss AS 5.1.0.GA Reporter: Daniel Lechner Assignee: Vaclav Dedik Labels: conversation, destroy Fix For: 2.3.0.Final Original Estimate: 3 days Remaining Estimate: 3 days In an example-project, we have 2 Seam components, one POJO and one SFSB. The POJO-component uses the SFSB-component via Seam-DI (@In). The POJO-component has a method annotated with @Destroy. We are using the POJO-component in a (long-running-)conversation. So the POJO-component as well as the SFSB-component will be created within the conversation. When the conversation ends and all components will be removed, the @Destroy-methods of all seam-components are called one after each other. The order, the @Destroy-methods are called, depend on the hashCode of the seam-name of the components (the component-names are put into an java.util.HashSet in the method org.jboss.seam.contexts.ServerConversationContext.getNamesFromSession() - the for-loop of the method org.jboss.seam.contexts.Contexts.destroy iterates through this HashSet afterwards). If the component-names are chosen this way, that the SFSB-component will be removed before the POJO-component is removed, a memory leak occurs: 1. the SFSB-component is destroyed by seam - the container removes the SFSB (the @Remove-method of the SFSB is called) 2. the @Destroy-method of the POJO-component is called. But before, Seam-DI creates a new SFSB-component TestEJB because of the @In-annotation 3. the POJO-component is removed from the conversation (and later by the GC) 4. the SFSB-component's @Remove-method is not called again - the container keeps the SFSB-instance An example-code can be found in the forum reference

Memory Leak when calling @Destroy (with SFSBs) ---------------------------------------------- Key: JBSEAM-4863 URL: https://issues.jboss.org/browse/JBSEAM-4863 Project: Seam 2 Issue Type: Bug Affects Versions: 2.2.2.Final Environment: JBoss AS 5.1.0.GA Reporter: Daniel Lechner Assignee: Vaclav Dedik Labels: conversation, destroy Fix For: 2.3.0.Final Attachments: JBSEAM-4863.zip Original Estimate: 3 days Remaining Estimate: 3 days In an example-project, we have 2 Seam components, one POJO and one SFSB. The POJO-component uses the SFSB-component via Seam-DI (@In). The POJO-component has a method annotated with @Destroy. We are using the POJO-component in a (long-running-)conversation. So the POJO-component as well as the SFSB-component will be created within the conversation. When the conversation ends and all components will be removed, the @Destroy-methods of all seam-components are called one after each other. The order, the @Destroy-methods are called, depend on the hashCode of the seam-name of the components (the component-names are put into an java.util.HashSet in the method org.jboss.seam.contexts.ServerConversationContext.getNamesFromSession() - the for-loop of the method org.jboss.seam.contexts.Contexts.destroy iterates through this HashSet afterwards). If the component-names are chosen this way, that the SFSB-component will be removed before the POJO-component is removed, a memory leak occurs: 1. the SFSB-component is destroyed by seam - the container removes the SFSB (the @Remove-method of the SFSB is called) 2. the @Destroy-method of the POJO-component is called. But before, Seam-DI creates a new SFSB-component TestEJB because of the @In-annotation 3. the POJO-component is removed from the conversation (and later by the GC) 4. the SFSB-component's @Remove-method is not called again - the container keeps the SFSB-instance An example-code can be found in the forum reference

Memory Leak when calling @Destroy (with SFSBs) ---------------------------------------------- Key: JBSEAM-4863 URL: https://issues.jboss.org/browse/JBSEAM-4863 Project: Seam 2 Issue Type: Bug Affects Versions: 2.2.2.Final Environment: JBoss AS 5.1.0.GA Reporter: Daniel Lechner Assignee: Vaclav Dedik Labels: conversation, destroy Fix For: 2.3.0.Final Attachments: JBSEAM-4863.zip Original Estimate: 3 days Remaining Estimate: 3 days In an example-project, we have 2 Seam components, one POJO and one SFSB. The POJO-component uses the SFSB-component via Seam-DI (@In). The POJO-component has a method annotated with @Destroy. We are using the POJO-component in a (long-running-)conversation. So the POJO-component as well as the SFSB-component will be created within the conversation. When the conversation ends and all components will be removed, the @Destroy-methods of all seam-components are called one after each other. The order, the @Destroy-methods are called, depend on the hashCode of the seam-name of the components (the component-names are put into an java.util.HashSet in the method org.jboss.seam.contexts.ServerConversationContext.getNamesFromSession() - the for-loop of the method org.jboss.seam.contexts.Contexts.destroy iterates through this HashSet afterwards). If the component-names are chosen this way, that the SFSB-component will be removed before the POJO-component is removed, a memory leak occurs: 1. the SFSB-component is destroyed by seam - the container removes the SFSB (the @Remove-method of the SFSB is called) 2. the @Destroy-method of the POJO-component is called. But before, Seam-DI creates a new SFSB-component TestEJB because of the @In-annotation 3. the POJO-component is removed from the conversation (and later by the GC) 4. the SFSB-component's @Remove-method is not called again - the container keeps the SFSB-instance An example-code can be found in the forum reference

Memory Leak when calling @Destroy (with SFSBs) ---------------------------------------------- Key: JBSEAM-4863 URL: https://issues.jboss.org/browse/JBSEAM-4863 Project: Seam 2 Issue Type: Bug Affects Versions: 2.2.2.Final Environment: JBoss AS 5.1.0.GA Reporter: Daniel Lechner Assignee: Vaclav Dedik Labels: conversation, destroy Fix For: 2.3.0.CR1 Attachments: JBSEAM-4863.zip Original Estimate: 3 days Remaining Estimate: 3 days In an example-project, we have 2 Seam components, one POJO and one SFSB. The POJO-component uses the SFSB-component via Seam-DI (@In). The POJO-component has a method annotated with @Destroy. We are using the POJO-component in a (long-running-)conversation. So the POJO-component as well as the SFSB-component will be created within the conversation. When the conversation ends and all components will be removed, the @Destroy-methods of all seam-components are called one after each other. The order, the @Destroy-methods are called, depend on the hashCode of the seam-name of the components (the component-names are put into an java.util.HashSet in the method org.jboss.seam.contexts.ServerConversationContext.getNamesFromSession() - the for-loop of the method org.jboss.seam.contexts.Contexts.destroy iterates through this HashSet afterwards). If the component-names are chosen this way, that the SFSB-component will be removed before the POJO-component is removed, a memory leak occurs: 1. the SFSB-component is destroyed by seam - the container removes the SFSB (the @Remove-method of the SFSB is called) 2. the @Destroy-method of the POJO-component is called. But before, Seam-DI creates a new SFSB-component TestEJB because of the @In-annotation 3. the POJO-component is removed from the conversation (and later by the GC) 4. the SFSB-component's @Remove-method is not called again - the container keeps the SFSB-instance An example-code can be found in the forum reference