[GLASSFISH-20450] Weld combination of API/implementation in single bundle slows down server startup Created: 01/May/13  Updated: 20/Dec/16  Resolved: 16/Apr/14

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_dev
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: Tom Mueller Assignee: phil.zampino
Resolution: Duplicate Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: devx_web

 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.



 Comments   
Comment by Tom Mueller [ 01/May/13 ]

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).

Comment by jjsnyder83 [ 01/May/13 ]

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

Comment by Tom Mueller [ 02/May/13 ]

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

Comment by tlcksnyder [ 02/May/13 ]

Defer to 4.0.1.

Comment by Sanjeeb Sahoo [ 03/May/13 ]

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

Comment by mtaube [ 06/May/13 ]

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.

Comment by Sanjeeb Sahoo [ 07/May/13 ]

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

Comment by Tom Mueller [ 07/May/13 ]

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.

Comment by Sanjeeb Sahoo [ 07/May/13 ]

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.

Comment by TangYong [ 17/Nov/13 ]

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.

Comment by TangYong [ 19/Nov/13 ]

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

Comment by TangYong [ 06/Dec/13 ]

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.

Comment by TangYong [ 10/Dec/13 ]

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

Pl. confirming and closing this jira.

Comment by jjsnyder83 [ 16/Apr/14 ]

Duplicate of https://java.net/jira/browse/GLASSFISH-20922

Generated at Tue Jan 24 18:00:07 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.