[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_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