Glassfish 4 scans for @PostConstruct with CDI disabled

Question

I'm doing and upgrade from Glassfish 3.1.2.2 to Glassfish 4.1 for a set of Spring applications. Since I use the Spring to handle @Inject annotations, I have disabled Glassfish' CDI using this command:

asadmin set configs.config.server-config.cdi-service.enable-implicit-cdi=false

Still, when I deploy one of my applications, I get the following error message:

The lifecycle method [something] must not throw a checked exception.
Related annotation information: annotation [@javax.annotation.PostConstruct()] 
on annotated element [public void com.something.MyClass.something() throws 
java.io.IOException] of type [METHOD]. Please see server.log for more details.

The class in question is an abstract class with no implementations in the application that I'm trying to deploy, it's just something that is on my classpath.

Why is Glassfish validating my @PostConstruct when I've disabled CDI? Why is Glassfish validating @PostConstruct on something that can not become a bean? How can I prevent Glassfish from interferring with anything that I'm using Spring for?

Answer 1

Annotation @PostConstruct is a general annotation used in any dependency injection mechanism. The Javadoc explicitely states that, unless used within an interceptor, it must be put on a method, which has void return type and throws no checked exceptions.

It is weird that Spring allows checked exceptions on post-construct methods, as there is not way how to handle them. But as this requirement is only a validation and can be ignored, Spring probably ignores checked exceptions and Glassfish does not. There is possibly an unnecessary Glassfish feature, that it scans and validates all classes, even if not used in CDI or any other mechanism (EJB, ...)

The best is to remove checked exceptions to align the code with the documentation and make it portable.

Answer 2

You can solve this issue first by adding a web.xml with metadata-complete="true". Next you will want to make sure your context are in the Web root Directory /WEB-INF/.

With this glassfish can load all @PostConstructSpring dependencies.

More of a work around in my opinion.