Win a copy of TDD for a Shopping Website LiveProject this week in the Testing forum!

hareendran dileep

Greenhorn
+ Follow
since May 07, 2009
hareendran likes ...
Netbeans IDE Fedora Java
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by hareendran dileep

Vivek,

Please try the following and let me know how it turned out.

java -classpath AdviceAppClient.jar;C:\j2sdkee1.3.1\lib\j2ee.jar;. AdviceClient


And forget about your CLASSPATH variable for now! If this works out I will tell you why
Karthick,

Whenever you do a response.setHeader, you are sending some instruction to the browser (which initiated the request). In this case with "Content-Disposition" you are advising the browser how to handle the content being streamed to it.

Ulf Dittmer's code says that the browser should treat the response body as an attachment and that it's name to be shown in the File Download dialog is "myFooBar.jar"

Hope this helps!
13 years ago
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?
Did you try adding the server jars in the classpath (runtime)?
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!!
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