EJB 3 - lifecycle callback interceptor - should not be final or static?

[hareendran dileep]

Hi,
In the EJB 3 Simplified API, it is stated that lifecycle callback interceptor methods should not be final or static (sec 3.4.1).
However I was able to make my Stateless Session Bean's @PreDestroy methods final and static and get it working in Glassfish v2.1.
I tried this out in my bean based interceptor method and Interceptor class based method. Both duly logged the PreDestroy message I had written on to the log files.

I am downright confused here. Glassfish is supposed to be the reference implementation server. Then why is it behaving like this?
Could anyone enlighten me

[hareendran dileep]

Looks like Jose Campana's post "Fundamental Doubt about static methods" is also on the same topic. Should have looked around the place a bit more before making my own post.

However as an answer Jaikiran only quotes the same statement from EJB 3 Simplified API (that one should not make it final or static).

But my problem is that I am able to do that and get it working too!!

[Paul Sturrock]

Its probably working by luck rather than by design. I'm sure if you tried the same thing in an applicaiton server that applied the standards much more strictly (e.g. WebSphere) it wouldn't work. There are a lot of things you can do in EJBs that the specification says you shouldn't. Stick to the specs. not what the compiler or one applciation serevr lets you do.

[hareendran dileep]

Paul,
Thanks for responding!!

I totally agree with the fact that one should stick to the specs.
The only other server I have is Websphere 6.1 which supports only EJB 2.x. So I am not able to test it elsewhere.

Basically my question is about two things.
1) Why does the spec explicitly specify that the interceptor method should not be final or static?
2) Why does the "Reference Implementation" server allow me to deviate from the spec.

Anyway here's what I guess the answer is. If any one knows better, please correct me.

For 1, I think the spec team expects the implementer to use some Dynamic Proxying mechanism a la Spring's AOP to implement Interceptors. If they use something like CGLIB (which creates a proxy by extending the original class and then overriding the method) final or static methods are definitely no no.

For 2, I guess the Glassfish team is not using CGLIB Probably they are manipulating the bytecode right away ... maybe ASM?