@PostConstruct method not called on CDI bean from external deployment module

[per.norrman]

Using wildfly 10.1.0.Final, I have a problem with CDI beans defined in external modules (looks like bug).

I have simple rest web application (test-app.war) where a service is injected with a bean that is defined in an external module (test.service). This dependency is declared in a jboss-deployment-structure.xml file:

<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
    <deployment>
        <dependencies>
            <module name="test.service" meta-inf="import"/>
        </dependencies>
    </deployment>
</jboss-deployment-structure>

The bean implementation:

@ApplicationScoped
public class MessageProducerImpl implements MessageProducer {
     private Status status = Status.UNDEFINED;

    @PostConstruct
    private void init() { this.status = Status.INITIALIZED; }

    public Status status() { return status; }
}

The implementation lives in the test.service module, which also has module dependencies to org.jboss.weld.core and org.jboss.weld.spi. After deploying the module and the webapp, wildfly starts ok with no error messages. The service is injected and invoked like this:

@Path("/")
@ApplicationScoped
public class MessageResource {
        
    @Inject
    MessageProducer messageProducer;

    @GET
    @Path("/status")
    public Response status() {
      String result = messageProducer.status() + "\n";
      return Response.status(200).entity(result).build();
    }
}

I would've expected that invoking this resource should return INITIALIZED, but it returns UNDEFINED, i.e. the init() method of the bean has not been called. If I package the external module jar directly in the webapp, INITIALIZED is returned.

Have I forgotten anything?

Cheers,

Per Norrman

[manovotn]

Hi Petr,

what you describe is somewhat grey area which may or may not work as you think/expect.

Have you tried using initializer method instead of `@PostConstruct` call? Should do the job done for you and might just work in external module.

Myself, I'll have to find out more about external modules to investigate this - if you could attach sources/reproducer, that would be great.

[per.norrman]

Hi Matej,

thanks for the reply. I will have a look at initializer method. In the meantime, I attach a gitbundle of the minimal reproducer.

Cheers,

Per

[per.norrman]

Hi Matej,

Injection method solved the problem, or maybe it should be viewed as a workaround, since I'm not dependent on an orderly shutdown through @PreDestroy. However, it would still be of value to understand why it happens. I can clearly see from trace logging that CDI is populating the client proxy object with post construct method interceptors.

Cheers,

Per

[manovotn]

Alright, so after some investigation (most credits go to mkouba), we found the issue.

In your module.xml, you want to add a dependency on

<module name="javax.annotation.api"/>

and then post construct interceptor starts working.

As it stands, if you do not add this dependency, the annotation will be ignored.

Normally, if you miss a dependency in module.xml, it would blow up, but it looks like there is some tweak (making it look intended) for annotations where it ignores the missing pieces.

As a consequence, when Weld attempts to grab this class and turn it into proxy, it no longer sees the annotation hence cannot do post construct properly.

EDIT: Actually this behaviour seems to be expected as it is defined by JVM - when you miss the class on CP at runtime, the program will still execute and ignore the annotations.

It had been explained in this SO question (and by extension in the JLS).