[jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-1593) New processing for stateful bean @Destroy and @Remove causes problems.

[Chris Rudd (JIRA)]

    [ 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