Enthuware

An explanation says that:

A stateless session bean cannot access resource managers in @PostConstruct or @Remove methods.

This is wrong, stateless session beans don't have @Remove. Perhaps you mean @PreDestroy?

You can annotate a method in a stateless session bean with @Remove. It may not be called but it is not wrong to do so. This has been changed to PreDestroy nevertheless.

thanks for your feedback!

there u=is no throws clause in the method definition is that o.k

That is ok because EJBException is a RuntimeException.

HTH,
Paul.

sector 4.7.2 Table 2
Spec allow the JNDI access to java:comp/env in PostConstruct method.
what purpose this allowed access to JNDI look up will serve then ?

rkbansal83 wrote:sector 4.7.2 Table 2
Spec allow the JNDI access to java:comp/env in PostConstruct method.
what purpose this allowed access to JNDI look up will serve then ?

JNDI access to java:comp/env is not only for accessing Resource Managers. It is also used for simple properties.

HTH,
Paul.

I think Enthuware's answer to this question is incorrect.

The explanation of the first and second answers of the question are: "A stateless session bean cannot access resource managers in a @PostConstruct method." and "A stateless session bean cannot access resource managers in @PostConstruct or @PreDestroy methods."

I created an example on github doing the same thing that's in the example, doing a jndi lookup of another stateless session bean on @PostConstruct and @PreDesktroy methods, and both ways worked.

The example is on https://github.com/andreiribas/ejb31-jn ... t-example/

In this project, there is a singleton bean, Mainclass. It gets a reference of ResourceDependencyLocator business interface, and its implementation is the stateless session bean ResourceDependencyLocatorBean class.
In ResourceDependencyLocatorBean class, it has a @PostConstruct method, and in this method it uses JNDI to get a reference to the ResourceDependency, and this class is another stateless session bean.

Some code of the classes, the complete code is on github:

//Main Class
@Singleton
@Startup
public class Main {

private Logger LOGGER;

@EJB
private ResourceDependencyLocator resourceDependencyLocator;

@PostConstruct
public void start() {

this.LOGGER = Logger.getLogger(Main.class);

LOGGER.debug(String.format("Resource Dependency message is: %s.", resourceDependencyLocator.locate().getMessage()));

}

}

....


//ResourceDependencyLocatorBean class

@PostConstruct
public void setUp() {

this.LOGGER = Logger.getLogger(ResourceDependencyLocatorBean.class);

try {

InitialContext ctx = new InitialContext();

LOGGER.debug(String.format("ejbJndiName is %s.", ejbJndiName));

this.resourceDependencyInstance = (ResourceDependency) ctx.lookup(ejbJndiName);

} catch(Exception e) {
throw new EJBException(e.getMessage());
}

}


@PreDestroy
public void tearDown() {

try {

InitialContext ctx = new InitialContext();

LOGGER.debug(String.format("Looking up ResourceDependency instance again before destroying this bean. The Dependency Message returned is: %s.", ((ResourceDependency) ctx.lookup(ejbJndiName)).getMessage()));

} catch(Exception e) {
throw new EJBException(e.getMessage());
}

}

According to Enthuware's answer, this should not work, but it does, it returns the right object in the @PostConstruct method and I call another method on it. It returns OK without any exceptions.

I'm testing it using Junit unit tests, and also deploying the war file in an embedded Glassfish V3.2 using maven.

As per Table 2 in section 4.7.2 of EJB 3.1 specification, access to resource manager is not allowed in PostConstruct, and PreDestroy methods.
Sometime the containers violate the specification so it is better to rely on the the specification than on the implementation of a container.

HTH,
Paul.

Why the EJB 3.1 specification allows a singleton or stateful bean to access resource managers such as QueueConnectionFactory in @PostContruct and @PreDestroy methods?

But stateless bean cannot access resource managers in life cycle callback interceptor methods.

what happens if we annotate this method with @PostConstruct for example?

compilation error? if not, why couldn't be it a @PostConstruct method regardless of the method functionality?

thanks!

This method is accessing a resource manager ( QueueConnectionFactory ). You cannot do that in a method that is annotated with @PostConstruct.
There won't be a compilation error but most probably an exception at run time (if the container implements the specification correctly.)