[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1593) New processing for stateful bean @Destroy and @Remove causes problems.
1:35 a.m.
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
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
1:50 a.m.
New subject: [jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-1593) New processing for stateful bean @Destroy and @Remove causes problems.
[ http://jira.jboss.com/jira/browse/JBSEAM-1593?page=comments#action_12367437 ]
Chris Rudd commented on JBSEAM-1593:
------------------------------------
Here is a potential fix. It only sets the defaultRemoveMethod to the first scanned
(instead of last) but will "override" with the @Destroy method, if it is also an
@Remove method. Additionally Component.callDefaultRemoveMethod is modified to only call
the default remove if it is NOT the @Destroy method as well (as it stands now a lone
@Destroy @Remove method would be called twice, which is probably not a good thing)
Component.java line 539
private void scanMethod(Context applicationContext, Map<Method, Annotation>
selectionSetters, Set<String> dataModelNames, Method method)
{
if ( method.isAnnotationPresent(REMOVE) )
{
removeMethods.put( method.getName(), method );
if ( method.getParameterTypes().length==0 )
{
+ // prefer the @Destroy method as the default remove method
+ if( defaultRemoveMethod == null || method.isAnnotationPresent(Destroy.class)
+ {
defaultRemoveMethod = method;
+ }
lifecycleMethods.add(method);
}
}
Component.java line 1866
private void callDefaultRemoveMethod(Object instance)
{
+ if( getDefaultRemoveMethod() != getDestroyMethod() )
callComponentMethod( instance, getDefaultRemoveMethod() );
}
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
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
1:52 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Assigned: (JBSEAM-1593) New processing for stateful bean @Destroy and @Remove causes problems.
[ http://jira.jboss.com/jira/browse/JBSEAM-1593?page=all ]
Gavin King reassigned JBSEAM-1593:
----------------------------------
Assignee: Gavin King
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
1:52 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-1593) New processing for stateful bean @Destroy and @Remove causes problems.
[ 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
1:52 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Updated: (JBSEAM-1593) New processing for stateful bean @Destroy and @Remove causes problems.
[ 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
9:30 a.m.
New subject: [jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-1593) New processing for stateful bean @Destroy and @Remove causes problems.
[ http://jira.jboss.com/jira/browse/JBSEAM-1593?page=comments#action_12367847 ]
Chris Rudd commented on JBSEAM-1593:
------------------------------------
I dont think its that bad ).
Ive looked over the code a bit more and i think you did handle the case where I thought
both the destroyMethod and defaultRemoveMethod would be called. In the block that picks up
the @Destroy it only sets Component.destroyMethod if its NOT also the @Remove.
This is what i would do.
Process the @Destroy first, and only process the @Remove if the @Destroy is null or NOT
also an @Remove. This way the remove is only valid if there is no destroy or the destroy
is not an @Remove
The only issue I see is how to handle overriden @Destroy methods that dont redeclare the
@Remove. I see in the @Destroy processing you account for the @Destroy being overriden
(the getName comparison). I couldnt find anything in the spec to address method overriding
in reguards to @Remove, so im not sure the following EJB would be removed or not when the
destroy method is called.
class FooBase {
....
@Destroy
@Remove
public void destroy() {}
}
@Stateful
class Foo implements LocalFoo {
...
@Override
@Destroy
public void destroy() {}
}
### Begin Code changes ###
private void scanMethod(Context applicationContext, Map<Method, Annotation>
selectionSetters, Set<String> dataModelNames, Method method)
{
- if ( method.isAnnotationPresent(Destroy.class) &&
method!=getDefaultRemoveMethod() )
+ if ( method.isAnnotationPresent(Destroy.class) )
{
/*if ( method.getParameterTypes().length>0 ) and it doesnt take a Component
paramater
{
throw new IllegalStateException("@Destroy methods may not have
parameters: " + name);
}*/
if (type!=JAVA_BEAN && type!=STATEFUL_SESSION_BEAN)
{
throw new IllegalArgumentException("Only JavaBeans and stateful session
beans support @Destroy methods: " + name);
}
if ( destroyMethod!=null&& !destroyMethod.getName().equals(
method.getName() ) )
{
throw new IllegalStateException("component has two @Destroy methods:
" + name);
}
if (destroyMethod==null)
{
destroyMethod = method;
lifecycleMethods.add(method);
}
}
- if ( method.isAnnotationPresent(REMOVE)
+ if ( method.isAnnotationPresent(REMOVE) && (getDestroyMethod() == null || !
getDestroyMethod().isAnnotationPresent(REMOVE))
{
removeMethods.put( method.getName(), method );
if ( method.getParameterTypes().length==0 )
{
defaultRemoveMethod = method;
lifecycleMethods.add(method);
}
}
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
7:58 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Resolved: (JBSEAM-1593) New processing for stateful bean @Destroy and @Remove causes problems.
[ http://jira.jboss.com/jira/browse/JBSEAM-1593?page=all ]
Norman Richards resolved JBSEAM-1593.
-------------------------------------
Resolution: Done
I've went ahead and tackled this one, making sure that the code accurately tests for
multiple @Destroy methods and making sure that if an @Remove method is marked as @Destroy,
that is that is the default remove method.
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
7:12 a.m.
New subject: [jbossseam-issues] [JBoss JIRA] Closed: (JBSEAM-1593) New processing for stateful bean @Destroy and @Remove causes problems.
[ http://jira.jboss.com/jira/browse/JBSEAM-1593?page=all ]
Pete Muir closed JBSEAM-1593.
-----------------------------
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
6129
days inactive
6385
days old
7 comments
4 participants
participants (4)
-
Chris Rudd (JIRA) -
Gavin King (JIRA)
-
Norman Richards (JIRA)
-
Pete Muir (JIRA)