[jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-1593) New processing for stateful bean @Destroy and @Remove causes problems.
Gavin King (JIRA)
jira-events at lists.jboss.org
Wed Jul 4 14:52:58 EDT 2007
[ http://jira.jboss.com/jira/browse/JBSEAM-1593?page=comments#action_12367694 ]
Gavin King commented on JBSEAM-1593:
------------------------------------
This is embarrassing.
> New processing for stateful bean @Destroy and @Remove causes problems.
> ----------------------------------------------------------------------
>
> Key: JBSEAM-1593
> URL: http://jira.jboss.com/jira/browse/JBSEAM-1593
> Project: JBoss Seam
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.0.0.BETA1
> Reporter: Chris Rudd
> Assigned To: Gavin King
> Priority: Blocker
> Fix For: 2.0.0.CR1
>
>
> I have an EJB that has several methods marked as @Remove, as I want the bean remove whenever those methods are executed.
> One of which is marked as @Destroy, which is the ONLY one that should be called because the object is being destroyed (ie from a call to Component.destroy. The problem is that under the new processing rules the "defaultRemoveMethod is set to the last parameterless @Remove method.
> I would suggest that the defaultRemoveMethod only be set to a "found @Remove" method if the @Destroy method has not been defined / does not have the @Remove annotation.
> my class :
> class Foo {
> @Destroy
> @Remove
> public void cleanup() { /* does state cleanup*/ }
> @Remove
> public String removeEntity() { /* does some work*/ }
> }
> For this class cleanup is executed because its the destroy method, then removeEntity is executed since it was the last @Remove method found.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the seam-issues
mailing list