@PostConstruct no longer called on stateless session bean usage

[ahofle]

Hello.

We are using Wildly Swarm (2018.3.3) and recently upgraded to Wildfly Thorntail 2.2.1.Final (microservice versions of Wildfly).

We have several stateless EJBs for providing RESTful services to clients and we use an @PostContruct annotation on an init() method in them to perform some required security context/initialization with each service/business method invocation.  This method was previously being called each time a service invocation occurred with Wildly Swarm 2018.3.3, but after upgrading to Thorntail the method is no longer called after the initial service call.  However, dependency injection is still performed with each call.  When changing the beans to @Stateful, init() is called with every service invocation.  The Swarm/Thorntail guys tell us this code is all part of Wildfly and didn't know why it changed.

The JEE6 spec is a little fuzzy on this life cycle and how often @PostConstruct is invoked, but it seems to be grouped with dependency injection:

The Lifecycles of Enterprise Beans - The Java EE 6 Tutorial

Any idea what changed with regard to this behavior?  Are there any options to register an event handler when a stateless bean is about to be invoked?  Or even better, is it possible to disable stateless session bean pooling so that a new instance is created each time the service is invoked?  We tried modifying sldb-strict-max-pool and max-pool-size but 1 appears to be is the minimum pool size.

Any help would be appreciated.

Thanks,

Andy

[pferraro]

These days, WildFly default configurations use instance pools for @Stateless EJBs, since this commit:

Switch default configs to use auto-configured strict-max-pools · wildfly/wildfly@02f2144 · GitHub

The EJB container triggers @PostConstruct methods only after new instances are created.  When using @Stateless EJB instance pooling, each invocation will not created a new instance, but rather use an instance from the pool, thus you should not expect to see a @PostConstruct method triggered for each method invocation.

Refer to §4.7.1 of the EJB specification for details.

[ahofle]

Thank you for the reply, you are right...the older version was simply not pooling.  Is there any way to disable the pooling (like the older behavior) or otherwise add some sort of handler when an EJB is taken from the pool and is about to be used to service a request?  There is some security related initialization that we really need to perform once per service invocation.

[pferraro]

Rather than disabling instance pooling (which you would do by removing the strict-max-pool configuration from the stateless element within the ejb3 subsystem) which would impact performance and reduce the portability of your application, I would recommend you instead implement your security related initialization within AroundInvoke [1] callbacks.

See §7.3 of the EJB specification for details. 

[1] AroundInvoke (Java(TM) EE 8 Specification APIs)