Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
Win a copy of OCP Oracle Certified Professional Java SE 11 Programmer I Study Guide: Exam 1Z0-815 this week in the Programmer Certification forum!

Sanju Thomas

Ranch Hand
+ Follow
since Dec 29, 2004
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 Sanju Thomas

Test result from Glasfish is also strange. When we had @AroundInvoke interceptor methods inside the bean the "interceptorMethodOne" got invoked, when we moved to a seperate interceptor class the "interceptorMethod" got invoked.

anyways what should I answer for the exam ?

According to spec we can have only one @AroundInvoke method in a class. Whether its in bean class or in sperate interceptor class. is that correct ?
lets keep it simple. How many method(s) I can annot with @PrePassivate in a statefull session bean ? Many places I have seen the answer is "ONE".
I have tested this in JBoss 5, JBoss did PERMIT me to have two methods with @PrePassivate annotation. It did not throw any spec vilocation error/exception ? Does the JBoss not follow the spec ? or we can have more than one @PrePassivate method inside the bean. (Not talking about interceptors at all).
you are correct, I removed the jndi binding code from the bean class.
10 years ago
how many PrePassivate methods we can have in an stateful session bean ?
Section 12.3 of the EJB core specs says that we can have only one @AroundInvoket method in a class.


AroundInvoke methods may be defined on superclasses of the bean class or interceptor classes.
However, only one AroundInvoke method may be present on a given class. An AroundInvoke
method cannot be a business method of the bean.



But I could write two AroundInvoke methods in the Bean class, and JBoss 5.0 did not complain anything about it!.

Code is gien below.

Remote interface


Bean Class




Client code



JBoss console output
------------------------

13:01:16,381 INFO [STDOUT] interceptorMethod is called
13:01:16,381 INFO [STDOUT] interceptorMethodOne is called
13:01:16,381 INFO [STDOUT] Business Method
13:01:16,427 INFO [STDOUT] interceptorMethod is called
13:01:16,427 INFO [STDOUT] interceptorMethodOne is called
13:01:16,427 INFO [STDOUT] Business method one


Whats happening here ?? Am I doing something wrong ? or JBoss is not following spec ? Both interceptor methods are permitted and both are getting executed. Please help.


Thanks Peter its worked. This is what shown in the console.

12:22:50,131 INFO [SessionSpecContainer] Starting jboss.j2ee:jar=mybean.jar,nam
e=MyBean,service=EJB3
12:22:50,131 INFO [EJBContainer] STARTED EJB: mine.test.ejb.MyBean ejbName: MyB
ean
12:22:50,209 INFO [JndiSessionRegistrarBase] Binding the following Entries in G
lobal JNDI:

MyBean/remote - EJB3.x Default Remote Business Interface
MyBean/remote-mine.test.ejb.IBean - EJB3.x Remote Business Interface


"/remote" with the bean name is something new I think. It was not there in JBoss 4, isn't it ?
10 years ago
Hi Peter, Thanks for the reply. I am using jboss-5.0.1.GA.
10 years ago
My JBoss client lookup return me org.jnp.interfaces.NamingContext type instead of my Bean remote type, I could not figure out anything wrong with the client. Please have a look.

Remote Interface



Bean Class



Client Class




Exception on the invocation of client. The loojup return me a type of org.jnp.interfaces.NamingContext, it shoud have been my remote type.

Exception in thread "main" java.lang.ClassCastException: org.jnp.interfaces.NamingContext
at mine.test.ejb.client.EjbClient.main(EjbClient.java:18)
10 years ago
I agree. You got to wait until the command comes from the client. once the command reaches, you can notify your waiting thread so that it can process the command.
change your code to interrupt the current thread.

Thread.currentThread().interrupt();

in the catch block write the logic to break your loop.
what kind of job your thread does ? its doing some kind of IO operation ? then the CPU usage might go up. Not sure if you can reduce it using your code.
if you change the line given below

MyThread thrd1 = new MyThread("Firsr", str1, str2);

to

MyThread thrd1 = new MyThread("First", str1, str2);

then it should create a dead lock.