Weld
  1. Weld
  2. WELD-625

Local no-interface view EJB3.1 proxy requests superclass of EJB from container

    Details

    • Type: Bug Bug
    • Status: Closed Closed (View Workflow)
    • Priority: Major Major
    • Resolution: Rejected
    • Affects Version/s: 1.0.1.Final
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:
    • Workaround:
      Workaround Exists
    • Workaround Description:
      Hide

      Use EJBs with local interface views

      Show
      Use EJBs with local interface views
    • Steps to Reproduce:
      Hide

      Install Glassfish 3.0.1 or 3.1r15
      Deploy test case
      Browse to /ErrorDemo off context-root
      Click "cdi" link

      Show
      Install Glassfish 3.0.1 or 3.1r15 Deploy test case Browse to /ErrorDemo off context-root Click "cdi" link
    • Similar Issues:
      Show 10 results 

      Description

      If Weld (CDI) is used to inject a local no-interface view of an EJB into another managed bean, the generated proxy that is injected cannot resolve calls to methods implemented in the EJB's superclass that aren't overridden by the concrete EJB class.

      An outline of the simplified test case that demonstrates the problem is:

      // This can be any DI candidate in an EJB container. In this case it's a JSF2 backing bean
      // managed in a CDI context.
      //
      @javax.inject.Named
      @javax.enterprise.context.SessionScoped
      public class InjectionSite {
      // If injected via @EJB, everything works, because we don't use Weld to create the proxy.
      @Inject private EJBClass ejb;
      public int getValue()

      { // Throws IllegalStateException from Weld return ejb.getValue(); }

      }

      // The EJB its self has a method that's implemented by a superclass and
      // not overridden by the concrete EJB class.
      @Stateless
      public class EJBClass extends EJBSuper

      { // Inherits getValue() from super }

      public class EJBSuper {
      public int getValue()

      { return 1; }

      }

      This seems to come down to Weld's EnterpriseBeanProxyMethodHandler. It decides which EJB class to ask the container for an instance of by determining which class implements the method being called. If the implementation is in a superclass of the EJB, this will fail, because the container doesn't know anything about the EJB's superclass, and in any non-trivial case there'll be several different EJBs with the same superclass anyway.

      The test case functions correctly if modified to use the Glassfish native JSF2/EJB injection via @EJB instead of Weld injection with @Inject, as the proxy created by @EJB isn't the Weld proxy implementation. That's only an option if you're using JSF2, though.

      As a workaround, the concrete EJB can wrap the superclass's methods, but this is rather clumsy in real-world cases where the superclass exists for a reason, particularly for things like data access facades where the superclass contains generified DAO methods and subclasses only provide a type param and a few helpers.

      If the object being injected isn't an EJB, everything works fine, but that's not really an option if you need EJB features or if you're injecting a bean that can't be made serializable into a serializable object like a JSF2 session-scoped bean.

      Background here: http://forums.java.net/jive/thread.jspa?messageID=480532&#480532 . A test case is attached to the thread.

        Activity

        Hide
        Craig Ringer
        added a comment -

        Deployable artifact that demonstrates the problem, and the sources to it.

        Show
        Craig Ringer
        added a comment - Deployable artifact that demonstrates the problem, and the sources to it.
        Show
        Craig Ringer
        added a comment - Possibly related JIRA issues: https://jira.jboss.org/browse/CDITCK-153 https://jira.jboss.org/browse/WELD-381 https://jira.jboss.org/browse/WELD-341 https://jira.jboss.org/browse/WELD-305
        Hide
        Craig Ringer
        added a comment -

        After a request on the Glassfish list, a bug has been filed against glassfish's cdi integration for this issue. The URL is https://glassfish.dev.java.net/issues/show_bug.cgi?id=13040 .

        Show
        Craig Ringer
        added a comment - After a request on the Glassfish list, a bug has been filed against glassfish's cdi integration for this issue. The URL is https://glassfish.dev.java.net/issues/show_bug.cgi?id=13040 .
        Hide
        Pete Muir
        added a comment -

        Siva has confirmed this is an issue in Weld/GlassFish integration

        Show
        Pete Muir
        added a comment - Siva has confirmed this is an issue in Weld/GlassFish integration

          People

          • Assignee:
            Pete Muir
            Reporter:
            Craig Ringer
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: