glassfish
  1. glassfish
  2. GLASSFISH-11131

Passivation of injected resources in to EJB and jsr299 beans

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: V3
    • Fix Version/s: V3
    • Component/s: cdi
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: Macintosh

    • Issuezilla Id:
      11,131

      Description

      This bug is related to passivation of injected javaEE resources in to JSR299
      Beans and EJB.

      There is a SFSB EJB bean injected in to a JSR299 Bean and when this bean is tried
      to be serialized/de-serialized it fails to create the original bean. Looks like the
      proxy which wraps the orignal SFSB is not serializable.

      Similarly, there is a jsr299 Bean injected with JavaEE resources such as
      EntityManager and EntityManagerFactory. When serialization/deserialization
      happens the proxy wrapping EntityManager and EntityManagerFactory does not
      seem to be serializable.

      Passivation of EJB and other injected EE resources is JSR 299 requirements. See
      6.6.1, 6.6.2 and 7.3.6 of jsr299 spec.

        Activity

        Hide
        vivekp added a comment -

        The corresponding JIRA issue on weld is:
        https://jira.jboss.org/jira/browse/CDITCK-69. As per Pete's evaliuation
        "readResolve() method is not being called on the SerializedProxy before the
        instance is assigned to the field"

        To reproduce this issue:

        Follow the instructions at, http://appserver.sfbay.sun.com/Wiki.jsp?
        page=Jsr299TckRunning.

        To run this particular test replace the jsr299-tck-impl.suite.xml inside jsr299-
        tck-1.0.1-SNAPSHOT/artifact directory by the one attached.

        Show
        vivekp added a comment - The corresponding JIRA issue on weld is: https://jira.jboss.org/jira/browse/CDITCK-69 . As per Pete's evaliuation "readResolve() method is not being called on the SerializedProxy before the instance is assigned to the field" To reproduce this issue: Follow the instructions at, http://appserver.sfbay.sun.com/Wiki.jsp? page=Jsr299TckRunning. To run this particular test replace the jsr299-tck-impl.suite.xml inside jsr299- tck-1.0.1-SNAPSHOT/artifact directory by the one attached.
        Hide
        vivekp added a comment -

        Created an attachment (id=3971)
        jsr299-tck-impl-suite.xml

        Show
        vivekp added a comment - Created an attachment (id=3971) jsr299-tck-impl-suite.xml
        Hide
        ludo added a comment -
        Show
        ludo added a comment - maybe https://glassfish.dev.java.net/issues/show_bug.cgi?id=11150 is related?
        Hide
        Sanjeeb Sahoo added a comment -

        OK, this turned out to be yet another class loading issue. The solution for the
        time being is to export these two packages from weld-osgi-bundle:

        org.jboss.weld.bean.builtin; org.jboss.weld.bean.builtin.ee

        I don't have the latest weld source to generate a patch, but it is as simple as
        updating the pom.xml with above package names. I have tested
        testPassivationOfEjbs test successfully.

        More details:
        ---------------------
        Yes, writeReplace is being called which is why SerializedProxy is written to the
        stream, but this SerializedProxy has handler of type
        org.jboss.weld.bean.builtin.CallableMethodHandler which in turn has a field of
        type org.jboss.weld.bean.builtin.ee.AbstractEECallable. Packages for these two
        classes are not exported by weld bundle, so application class loader can't load
        them. Unfortunately, the tests are written such that default ObjectInputStream
        is used which in turn uses something called "latest user defined class loader"
        to load user defined classes. During this test execution, "latest user defined
        class loader" is application class loader. More over, deserialization logic is
        taking an alternate course when it is not able to load these classes and I am
        quite sure that's as per Java I/O spec. So, exporting those packages makes the
        test pass.

        For Pete & JSR 299 folks:
        -------------------------------------------------------
        I am not sure why the test is using ObjectInputStream and ObjectOutputStream to
        read & write managed beans. In GlassFish, we use specialized ObjectInputStream
        and ObjectOutputStream to read and write container managed objects. Those
        specialized streams contain extra data like OSGi bundle details for a class. I
        would expect managed bean container to have an SPI which an appserver can use to
        provide suitableObjectInputStream and ObjectOutputStream objects for use. I
        think this is something to think about in future.

        Final Thoughts:
        -------------------------
        Looking at the number of packages exported by weld bundle, I think we need to
        look at the class loading strategy wrt javassist more closely after this release.

        Show
        Sanjeeb Sahoo added a comment - OK, this turned out to be yet another class loading issue. The solution for the time being is to export these two packages from weld-osgi-bundle: org.jboss.weld.bean.builtin; org.jboss.weld.bean.builtin.ee I don't have the latest weld source to generate a patch, but it is as simple as updating the pom.xml with above package names. I have tested testPassivationOfEjbs test successfully. More details: --------------------- Yes, writeReplace is being called which is why SerializedProxy is written to the stream, but this SerializedProxy has handler of type org.jboss.weld.bean.builtin.CallableMethodHandler which in turn has a field of type org.jboss.weld.bean.builtin.ee.AbstractEECallable. Packages for these two classes are not exported by weld bundle, so application class loader can't load them. Unfortunately, the tests are written such that default ObjectInputStream is used which in turn uses something called "latest user defined class loader" to load user defined classes. During this test execution, "latest user defined class loader" is application class loader. More over, deserialization logic is taking an alternate course when it is not able to load these classes and I am quite sure that's as per Java I/O spec. So, exporting those packages makes the test pass. For Pete & JSR 299 folks: ------------------------------------------------------- I am not sure why the test is using ObjectInputStream and ObjectOutputStream to read & write managed beans. In GlassFish, we use specialized ObjectInputStream and ObjectOutputStream to read and write container managed objects. Those specialized streams contain extra data like OSGi bundle details for a class. I would expect managed bean container to have an SPI which an appserver can use to provide suitableObjectInputStream and ObjectOutputStream objects for use. I think this is something to think about in future. Final Thoughts: ------------------------- Looking at the number of packages exported by weld bundle, I think we need to look at the class loading strategy wrt javassist more closely after this release.
        Hide
        rogerk added a comment -

        the weld osgi bundle pom.xml has the two packages exported:
        org.jboss.weld.bean.builtin; org.jboss.weld.bean.builtin.ee

        The test passes.

        Show
        rogerk added a comment - the weld osgi bundle pom.xml has the two packages exported: org.jboss.weld.bean.builtin; org.jboss.weld.bean.builtin.ee The test passes.

          People

          • Assignee:
            rogerk
            Reporter:
            vivekp
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: