Issue Details (XML | Word | Printable)

Key: GLASSFISH-20450
Type: Bug Bug
Status: Resolved Resolved
Resolution: Duplicate
Priority: Major Major
Assignee: phil.zampino
Reporter: Tom Mueller
Votes: 1
Watchers: 5

If you were logged in you would be able to see more operations.

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

Created: 01/May/13 04:33 PM   Updated: Wednesday 07:29 PM   Resolved: Wednesday 07:29 PM
Component/s: cdi
Affects Version/s: 4.0_b86_RC2
Fix Version/s: 4.0.1

Time Tracking:
Not Specified

Tags: devx_web
Participants: jjsnyder83, mtaube, phil.zampino, Sanjeeb Sahoo, TangYong, tlcksnyder and Tom Mueller

 Description  « Hide

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.

Tom Mueller added a comment - 01/May/13 04:50 PM

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

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

jjsnyder83 added a comment - 01/May/13 05:37 PM

The packages to move into an weld-osgi-api.jar include:

Tom Mueller added a comment - 02/May/13 04:46 PM

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

tlcksnyder added a comment - 02/May/13 09:00 PM

Defer to 4.0.1.

Sanjeeb Sahoo added a comment - 03/May/13 12:54 AM

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

mtaube added a comment - 06/May/13 05:56 PM

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.

Sanjeeb Sahoo added a comment - 07/May/13 03:18 AM

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

Tom Mueller added a comment - 07/May/13 02:48 PM

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.

Sanjeeb Sahoo added a comment - 07/May/13 03:44 PM

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.

TangYong added a comment - 17/Nov/13 02:45 PM

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.

TangYong added a comment - 19/Nov/13 02:29 AM

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!

TangYong added a comment - 06/Dec/13 02:37 AM

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.

TangYong added a comment - 10/Dec/13 01:38 PM

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

Pl. confirming and closing this jira.

jjsnyder83 added a comment - 16/Apr/14 07:29 PM