multiple @Remove, EJB3 incompatible?

[sannegrinovero]

Hello everyone, I was thinking about Seam's use of the @Remove and @Destroy annotations,
I am wondering if Seam is imposing me some limitations on respect to EJB3 specs, or if I'm missing something.

from the Seam docs:
@Destroy

The @Destroy method is called when the context that the Seam component is bound to ends. Components may define only one @Destroy method...[...]
...Destroy methods should be used only for cleanup.

@Remove

The EJB standard @Remove annotation specifies that a stateful session bean should be removed and its state destroyed after invocation of the annotated method. In Seam, all stateful session beans must define a method with no parameters marked @Remove. This method will be called when Seam destroys the session context.

Our application has some Stateful Beans with 1 single @Destroy and multiple @Remove; toying since some days JBoss Tools i get this error:

Duplicate @Remove method "methodname"

.

The applications actually looks-like working and I cant't tell if something bad is happening behind the scenes, but:
The warning from the tool makes sense as "This method will be called when Seam destroys the session context".. How could Seam know which method to call?

EJB3 uses the single @Destroy as a callback to cleanup, and is triggered by one of the @Remove; I think Seam is abusing this to call a @Remove (expecting it to be single) to trigger the EJB destroy.. is that right? couldn't seam directly ask EJB to trigger destruction? or have another annotation, an extension to @Remove, single on a bean, so to know which one to call?
I know I could avoid the need of multiple @Remove s with another design, but that's not the point.

Do I really need to remove the multiple "@Remove" from my beans? Does it really cause some trouble? I wouldn't like Seam spontaneously to call some of my annotated actions.

[pmuir]

"sannegrinovero" wrote:
Our application has some Stateful Beans with 1 single @Destroy and multiple @Remove; toying since some days JBoss Tools i get this error:

Duplicate @Remove method "methodname"

.

So, this is probably a bug with JBoss Tools.

The warning from the tool makes sense as "This method will be called when Seam destroys the session context".. How could Seam know which method to call?

Seam doesn't call the @Remove, the EJB container does - Seam asks for the Session to be destroyed, and the EJB container can act on it.


I'm quite confused by what you are saying, but what *happens* is this:

You call a method annotated @Remove, after the completion of the this method, the container destroys the SFSB, executing any callbacks (@Destroy methods are all registered as callbacks) before it does so.

EJB3 uses the single @Destroy as a callback to cleanup, and is triggered by one of the @Remove;I think Seam is abusing this to call a @Remove (expecting it to be single) to trigger the EJB destroy.. is that right?

No, Seam doesn't call methods @Remove, you do

couldn't seam directly ask EJB to trigger destruction?

When?

or have another annotation, an extension to @Remove, single on a bean, so to know which one to call?

Why?

[sannegrinovero]

thanks a lot Pete,
if you think it's a bug of the tools then all the rest of my confusion doesn't apply.

Still you say

Seam doesn't call the @Remove, the EJB container does

That makes some confusion, I would say that the EJB containers calls the destroy, and not the remove: as you write later on

No, Seam doesn't call methods @Remove, you do

.

Still, isn't documentation wrong when it says

In Seam, all stateful session beans must define a method with no parameters marked @Remove. This method will be called when Seam destroys the session context.

?
Why should Seam need a @Remove method? How does it identify the correct method when multiple methods are annotated?

[pmuir]

There is a bit of trickery here

If you define a method

@Remove
public void remove() {}

(method name doesn't matter)

then Seam assumes it is also the method to call for @Destroy. What happens if you have multiple methods marked @Remove with no parameters is the last one is taken as the @Destroy method. This is probably wrong. File a JIRA issue.

[sannegrinovero]

Thanks again,

here is the JIRA:
http://jira.jboss.org/jira/browse/JBSEAM-2475

Hope the documentation could be fixed too; I will do it myself if I manage to understand how it will be solved.