Migrating JAX-RS services from Glassfish 3 - failed to lazily initialize a collection

[poisond]

Hi

I'm trying to migrate an application from Glassfish 3 to Wildfly 9.

I have several JAX-RS services to query JPA entities...  simplified example:

@Stateless
@Path("ent")
public class EntFacadeREST {

  @PersistenceContext(unitName="prod")
  private EntityManager em;

  @GET
  @Produces({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})
  public List<Ent> findAll() {
    CriteriaBuilder cb = em.getCriteriaBuilder();
    CriteriaQuery<Ent> cq = cb.createQuery(Ent.class);
    Root<Ent> rootEntry = cq.from(Ent.class);
    CriteriaQuery<Ent> all = cq.select(rootEntry);
    TypedQuery<Ent> allQuery = em.createQuery(all);
    return allQuery.getResultList();
  }
}

This works fine in Glassfish and I was surprised seeing the following stacktrace in Wildfly:

org.jboss.resteasy.spi.UnhandledException: org.hibernate.LazyInitializationException: failed to lazily initialize a collection of role: Ent.limitationCollection, could not initialize proxy - no Session
org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:247)
org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:149)
org.jboss.resteasy.core.SynchronousDispatcher.writeResponse(SynchronousDispatcher.java:432)
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:376)
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179)
org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
a.i.HttpCacheFilter.doFilter(HttpCacheFilter.java:91)
io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
a.i.AccessControlServletFilter.doFilter(AccessControlServletFilter.java:55)
io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
java.lang.Thread.run(Thread.java:745)

Theese are the suggested workarounds I've found:

* Use FetchType.EAGER: Absolute no-go.

* Use @Stateful EJB and PersistenceContextType.EXTENDED: While it works and is less sub optimal than the former workaround, it seems rather dirty to make the EJBs into @Stateful beans just as a workaround.

So, what is the proper solution to this?

I always thought the JAXB-marshalling took place inside the EJB transaction.

Is this a different interpretation of specs? Something not specified? A bug in Wildfly or Glassfish?

TIA,

Andrew