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

        Tom Mueller created issue -
        Hide
        Tom Mueller added a comment -

        Here is an analysis of how the bundle status changes given this change:

        After a server start (with no application), the following modules are no longer resolved after the split (they are in the installed state):

        Deployment Related JavaEE Full Profile Classes
        JavaServer Pages(TM) Standard Tag Library API
        Mojarra JSF Implementation 2.2.0
        Weld connector for glassfish
        Weld integration for glassfish
        org.glassfish.main.web.weld-integration-fragment

        The state of all bundles after the deploy of an application is the same (except there is the new added bundle which is resolved).

        Show
        Tom Mueller added a comment - Here is an analysis of how the bundle status changes given this change: After a server start (with no application), the following modules are no longer resolved after the split (they are in the installed state): Deployment Related JavaEE Full Profile Classes JavaServer Pages(TM) Standard Tag Library API Mojarra JSF Implementation 2.2.0 Weld connector for glassfish Weld integration for glassfish org.glassfish.main.web.weld-integration-fragment The state of all bundles after the deploy of an application is the same (except there is the new added bundle which is resolved).
        Hide
        jjsnyder83 added a comment -

        The packages to move into an weld-osgi-api.jar include:
        javax.enterprise.*
        javax.decorator

        Show
        jjsnyder83 added a comment - The packages to move into an weld-osgi-api.jar include: javax.enterprise.* javax.decorator
        Hide
        Tom Mueller added a comment -

        It would be nice to get this into 4.0, if possible. Please evaluate.

        Show
        Tom Mueller added a comment - It would be nice to get this into 4.0, if possible. Please evaluate.
        Tom Mueller made changes -
        Field Original Value New Value
        Fix Version/s 4.0 [ 10970 ]
        Hide
        tlcksnyder added a comment -

        Defer to 4.0.1.

        Show
        tlcksnyder added a comment - Defer to 4.0.1.
        tlcksnyder made changes -
        Fix Version/s 4.0.1 [ 16061 ]
        Fix Version/s 4.0 [ 10970 ]
        Hide
        Sanjeeb Sahoo added a comment -

        I think we have a bad dependency issue here. We should not separate the api from implementation bundle.

        Show
        Sanjeeb Sahoo added a comment - I think we have a bad dependency issue here. We should not separate the api from implementation bundle.
        Hide
        mtaube added a comment -

        weld-integration-fragment attaches to the weld osgi-bundle, and imports from the weld-integration bundle. This seems to be what is causing the transitive resolution of ejb-container.

        Show
        mtaube added a comment - weld-integration-fragment attaches to the weld osgi-bundle, and imports from the weld-integration bundle. This seems to be what is causing the transitive resolution of ejb-container.
        Hide
        Sanjeeb Sahoo added a comment -

        Was weld-osgi bundle getting resolved in 3.1.2 as well? Or is this bad dependency a regression in 4.0?

        Show
        Sanjeeb Sahoo added a comment - Was weld-osgi bundle getting resolved in 3.1.2 as well? Or is this bad dependency a regression in 4.0?
        Hide
        Tom Mueller added a comment -

        Here are the states of the Weld related bundles after starting 3.1.2:

        Weld OSGi Bundle | 3.1.2 | Resolved
        Weld integration for glassfish | 3.1.2 | Active
        org.glassfish.main.web.weld-integration-fragment | 3.1.2 | Resolved

        The problem in 4.0 is not so much that these bundles are getting resolved, but that in 4.0, the resolution of weld-osgi-bundle.jar causes ejb-container to be resolved as well where it didn't in 3.1.2. See issue GLASSFISH-20409.

        Show
        Tom Mueller added a comment - Here are the states of the Weld related bundles after starting 3.1.2: Weld OSGi Bundle | 3.1.2 | Resolved Weld integration for glassfish | 3.1.2 | Active org.glassfish.main.web.weld-integration-fragment | 3.1.2 | Resolved The problem in 4.0 is not so much that these bundles are getting resolved, but that in 4.0, the resolution of weld-osgi-bundle.jar causes ejb-container to be resolved as well where it didn't in 3.1.2. See issue GLASSFISH-20409 .
        Hide
        Sanjeeb Sahoo added a comment -

        My point is we should not separate APIs from implementations. They are against our preferred packaging approach as Bill described in maven/osgi/javaee packaging document. The APIs should only be needed if the corresponding implementation is also needed. It seems to me that some bundles are incorrectly packaged leading these kind of issues.

        Show
        Sanjeeb Sahoo added a comment - My point is we should not separate APIs from implementations. They are against our preferred packaging approach as Bill described in maven/osgi/javaee packaging document. The APIs should only be needed if the corresponding implementation is also needed. It seems to me that some bundles are incorrectly packaged leading these kind of issues.
        jjsnyder83 made changes -
        Assignee jjsnyder83 [ jjsnyder83 ] phil.zampino [ phil.zampino ]
        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.
        Sanjeeb Sahoo made changes -
        Comment [ Can't we add another bundle with javax.inject APIs inside it instead of disturbing existing weld bundle? ]
        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
        jjsnyder83 made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Duplicate [ 3 ]
        Romain Grécourt made changes -
        Fix Version/s 4.1 [ 16387 ]
        Fix Version/s 4.0.1 [ 16061 ]
        Joe Di Pol made changes -
        Affects Version/s 4.0_dev [ 17784 ]

          People

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

            Dates

            • Created:
              Updated:
              Resolved: