• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Junilu Lacar
  • Liutauras Vilda
Sheriffs:
  • Paul Clapham
  • Jeanne Boyarsky
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Piet Souris
  • Carey Brown
Bartenders:
  • Jesse Duncan
  • Frits Walraven
  • Mikalai Zaikin

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

 
Greenhorn
Posts: 6
Netbeans IDE Fedora Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 6
Netbeans IDE Fedora Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!!
 
Bartender
Posts: 10336
Hibernate Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 6
Netbeans IDE Fedora Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
pie. tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic