[
http://jira.jboss.com/jira/browse/JBSEAM-1593?page=all ]
Gavin King updated JBSEAM-1593:
-------------------------------
Fix Version/s: 2.0.0.CR1
Priority: Blocker (was: Major)
Ouch! I must have really disengaged my brain when I made those changes.
I might have to roll back that whole change. Damn.
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
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