[jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-1593) New processing for stateful bean @Destroy and @Remove causes problems.
Chris Rudd (JIRA)
jira-events at lists.jboss.org
Thu Jul 5 10:30:50 EDT 2007
[ 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
More information about the seam-issues
mailing list