glassfish
  1. glassfish
  2. GLASSFISH-20450

Weld combination of API/implementation in single bundle slows down server startup

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: 4.0_dev
    • Fix Version/s: 4.1
    • Component/s: cdi
    • Labels:
      None

      Description

      Currently, the weld-osgi-bundle.jar file contains the javax.enterprise.* (context, inject, event, etc.) classes (the API consisting of 108 classes) and 2716 implementation classes (org.jboss.weld, etc.).

      Experiments have shown that if this bundle is split into two bundles, e.g., weld-osgi-api.jar and weld-osgi-impl.jar, then a 3% improvement can be achieved in the devx_web performance benchmark. After server startup, the weld-osgi-impl.jar stays in the installed state. It is resolved during application deployment.

      This issue is for making this split.

        Activity

        Hide
        TangYong added a comment -

        Just now, we(I and Jeremy) have done a hard test for the issue as following:

        We are doing GlassFish on-demand starting experiments and we have decreased modules into mini-modules for meeting GlassFish Domain normal Starting.

        In these mini-modules, some modules as API are necessary and this is reasonable. However,weld-osgi-bundle.jar can not be removed. We know that some modules depend on CDI and only depend on CDI API rather than Impl. We wish that API from weld-osgi-bundle.jar can be separated in order that in on-demand starting env, we can only preserve API and remove impl. Thus, this will improve GF Starting performance.

        So, from this point, I agree with separating APIs from implementations.

        Show
        TangYong added a comment - Just now, we(I and Jeremy) have done a hard test for the issue as following: We are doing GlassFish on-demand starting experiments and we have decreased modules into mini-modules for meeting GlassFish Domain normal Starting. In these mini-modules, some modules as API are necessary and this is reasonable. However,weld-osgi-bundle.jar can not be removed. We know that some modules depend on CDI and only depend on CDI API rather than Impl. We wish that API from weld-osgi-bundle.jar can be separated in order that in on-demand starting env, we can only preserve API and remove impl. Thus, this will improve GF Starting performance. So, from this point, I agree with separating APIs from implementations.
        Hide
        TangYong added a comment -

        Pl. allowing me explain the issue in detailed:

        javax.transaction-api.jar imports javax.enterprise.context package, so it depends on cdi api 1.1. On minimizing GlassFish domain starting, javax.transaction-api.jar is necessary.

        Well, because cdi api 1.1 is wrapped into weld-osgi-bundle.jar, we must include weld-osgi-bundle.jar even though it also wraps
        cdi 1.1 implementation while minimizing GlassFish domain starting. So, from this point, we should separate cdi api from implementations.

        On the other hand, I looked into the newest wildfly-8.0.0.Beta1, on its modules splitting, about CDI, it has the following modules,

        1) cdi-api-1.1.jar

        Its aim is only for cdi api 1.1

        2) weld-api-2.1.CR1.jar

        Its aim is for weld api, this is related to implementation.

        3) weld-core-impl-2.1.0.CR1.jar

        Its aim is for weld implementation, this is related to implementation.

        4) weld-spi-2.1.CR1.jar

        Its aim is for weld spi implementation, this is related to implementation.

        Based on the above analyse, I think that current weld-osgi-bundle.jar is not good for modulation principle.

        Best Regards!
        Tang

        Show
        TangYong added a comment - Pl. allowing me explain the issue in detailed: javax.transaction-api.jar imports javax.enterprise.context package, so it depends on cdi api 1.1. On minimizing GlassFish domain starting, javax.transaction-api.jar is necessary. Well, because cdi api 1.1 is wrapped into weld-osgi-bundle.jar, we must include weld-osgi-bundle.jar even though it also wraps cdi 1.1 implementation while minimizing GlassFish domain starting. So, from this point, we should separate cdi api from implementations. On the other hand, I looked into the newest wildfly-8.0.0.Beta1, on its modules splitting, about CDI, it has the following modules, 1) cdi-api-1.1.jar Its aim is only for cdi api 1.1 2) weld-api-2.1.CR1.jar Its aim is for weld api, this is related to implementation. 3) weld-core-impl-2.1.0.CR1.jar Its aim is for weld implementation, this is related to implementation. 4) weld-spi-2.1.CR1.jar Its aim is for weld spi implementation, this is related to implementation. Based on the above analyse, I think that current weld-osgi-bundle.jar is not good for modulation principle. Best Regards! Tang
        Hide
        TangYong added a comment -

        in current GF modules, there are two modules which all exports 'javax.inject'.

        1) weld-osgi-bundle.jar
        2) javax.inject.jar

        seperating Weld API from implementation is a solution for the issue.

        Show
        TangYong added a comment - in current GF modules, there are two modules which all exports 'javax.inject'. 1) weld-osgi-bundle.jar 2) javax.inject.jar seperating Weld API from implementation is a solution for the issue.
        Hide
        TangYong added a comment -

        The issues related to this jira will be resolved by GLASSFISH-20922.

        Pl. confirming and closing this jira.

        Show
        TangYong added a comment - The issues related to this jira will be resolved by GLASSFISH-20922 . Pl. confirming and closing this jira.
        Hide
        jjsnyder83 added a comment -
        Show
        jjsnyder83 added a comment - Duplicate of https://java.net/jira/browse/GLASSFISH-20922

          People

          • Assignee:
            phil.zampino
            Reporter:
            Tom Mueller
          • Votes:
            1 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: