Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.1.0
    • Fix Version/s: 1.1.4
    • Component/s: Core
    • Labels:
      None

      Description

      I need to do some more investigation, but I believe OWB has a problem with @New is used with an EJB. It attempts to use a NewBean, which extends ManagedBean, but never sets a constructor (which it shouldn't, given its an EJB). I believe the lack of constructor leads to an NPE when super.createInstance is called.

        Activity

        Hide
        Mark Struberg added a comment -

        released with OWB-1.1.4

        Show
        Mark Struberg added a comment - released with OWB-1 .1.4
        Hide
        Mark Struberg added a comment -

        OWB now provides the necessary parts. There is now an EjbNewBean in OpenEJB which handles this for us.

        Show
        Mark Struberg added a comment - OWB now provides the necessary parts. There is now an EjbNewBean in OpenEJB which handles this for us.
        Hide
        Joe Bergmark added a comment -

        Unfortunately I think EJBs do have to have a version with @New as well. Section 3.12 says "For each managed bean, and for each session bean, a second bean exists which" etc.

        In order to let the EJB plugin handle this in a way that the common webbeans-impl code can understand, I'm thinking of the following:

        1) Remove the creation of current NewBean impl from EJBUtility. Let the plugin do this in defineSessionBean as it understands its EJBBean code better than we can in common code.
        2) Make NewBean an interface, so that anyone can implement that interface, and we can just check for the interface to know we should be ignoring Specialization, etc.
        3) Rename the current NewBean implementation class to something like NewManagedBean, and have it implement the NewBean interface.

        All the places where we construct NewBean's will need to be changed to use #3 (which is only 2 utility method I believe), and all of the checks for NewBean can remain as they are now.

        Another alternative would just be to check for the @New qualifier rather than "instanceof NewBean", but the spec doesn't really forbid that annotation from being used elsewhere.

        Show
        Joe Bergmark added a comment - Unfortunately I think EJBs do have to have a version with @New as well. Section 3.12 says "For each managed bean, and for each session bean, a second bean exists which" etc. In order to let the EJB plugin handle this in a way that the common webbeans-impl code can understand, I'm thinking of the following: 1) Remove the creation of current NewBean impl from EJBUtility. Let the plugin do this in defineSessionBean as it understands its EJBBean code better than we can in common code. 2) Make NewBean an interface, so that anyone can implement that interface, and we can just check for the interface to know we should be ignoring Specialization, etc. 3) Rename the current NewBean implementation class to something like NewManagedBean, and have it implement the NewBean interface. All the places where we construct NewBean's will need to be changed to use #3 (which is only 2 utility method I believe), and all of the checks for NewBean can remain as they are now. Another alternative would just be to check for the @New qualifier rather than "instanceof NewBean", but the spec doesn't really forbid that annotation from being used elsewhere.
        Hide
        Mark Struberg added a comment -

        This sounds like a good idea. The spec only says: for each Bean another New-Bean must exist. But EJBs are not being handled as Beans anyway.

        Show
        Mark Struberg added a comment - This sounds like a good idea. The spec only says: for each Bean another New-Bean must exist. But EJBs are not being handled as Beans anyway.
        Hide
        Joe Bergmark added a comment -

        Given the current code in EJBUtility's fireEvents that leads to the NPE, does anyone have a concern over taking this out of EJBUtility, and letting the OpenWebBeansEJBPlugin's defineSessionBean implementation take care of this work of creating a new version of the Bean with the @New qualifier, Dependent Scope, etc? It seems to be its going to be dependent on the EJB implementation.

        Show
        Joe Bergmark added a comment - Given the current code in EJBUtility's fireEvents that leads to the NPE, does anyone have a concern over taking this out of EJBUtility, and letting the OpenWebBeansEJBPlugin's defineSessionBean implementation take care of this work of creating a new version of the Bean with the @New qualifier, Dependent Scope, etc? It seems to be its going to be dependent on the EJB implementation.

          People

          • Assignee:
            Joe Bergmark
            Reporter:
            Joe Bergmark
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development