Don't Overload EJB 3 Lifecycle and Interceptor Methods: Part 2

In part one, I wrote about not to overload EJB 3 lifecycle and interceptor methods, which is another programming restriction in EJB. Under what circumstances are developers likely to fall into this trap?

1. Some method names are so good that we want to use it in multiple methods, such as init, initialize, initialise, etc. This is so natural in java and one will never expect them to be disallowed in EJB 3 lifecycle and interceptor methods.

2. When migrating some EJBs from 2.x to 3.0 and their bean classes already have overloaded methods. You annotate one of them to be lifecycle or interceptor method.

How can we detect such application errors? The good news is verifier will catch it. In JavaEE SDK 5/Glassfish/Sun Java System Application Server, it's install-dir/bin/verifier. In my NetBeans 5.5, I can also verify it by right-click the project node and choose verify. This will run the verifier, since my NetBeans has already been configured with Sun Java System Application Server 9.0.

C:\tmp > C:\Sun\AppServer\bin\verifier hello.ear

Test Name : tests.ejb.ejb30.CallbackMethodArgument
Test Assertion : Lifecycle callback interceptor methods defined on an interceptor class should have InvocationContext as argument. When defined on the bean class they should have empty argument. Please refer to EJB 3.0 "Core Contracts and Requirements" Specification Section #11.4 for further information.
Test Description : For [ hello#hello-ejb.jar#ResourceBean ]
Wrong PostConstruct interceptor method [ public void com.foo.ejb.ResourceBean.init(java.util.Properties) ]
This verifier is appserver-independent, and you can use it to verify any J2EE and JavaEE applications for potential errors/warnings, even if you are not using Glassfish. Other appservers and IDEs may or may not have a verifier program, and they may or may not catch such an error.

Continue to part 3 ...