[GLASSFISH-19747] Duplication of weld classes causes increase of distribution size by 3.5MB Created: 28/Feb/13  Updated: 12/Aug/13  Resolved: 09/May/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b78
Fix Version/s: 4.0_b89_RC5

Type: Bug Priority: Major
Reporter: Sanjeeb Sahoo Assignee: phil.zampino
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0-approved


To support CDI in ACC, we are including weld-se.jar in distribution. Its size is 3.5MB - same as weld-osgi-bundle.jar. A quick analysis shows that the two jars mostly overlapping. See the attached files which list the jar contents as resource names. In fact, the se jar even repackages javax.annotation, javax.el, javax.interceptor inside it. I see no reason for them to be included like that in our product when we already have them in file system in separate places. The only extra set of classes are actually org.jboss.weld.environment.se and crucial META-INF/services files. Here is what we should strive for:
a) Just have all weld related classes in weld-osgi-bundle.jar and make it useable from ACC.
b) If this is not possible, then see the SE specific artifacts can be packaged in to a separate jar and used in conjunction with above jar.

Comment by phil.zampino [ 29/Apr/13 ]

Determining if weld-se-core.jar can be the resolution to this issue.

Comment by phil.zampino [ 09/May/13 ]

Committed revision 61908. Replaced weld-se.jar with weld-se-core.jar

Comment by Sanjeeb Sahoo [ 09/May/13 ]

If this fix was so simple, I am wondering why we didn't do it in 4.0 which is going to be downloaded by a lot of folks. It reduces the benefit of the fix.

Comment by phil.zampino [ 09/May/13 ]
  • What is the impact on the customer of the bug?
    Improved download experience; Reduces the distribution size by almost 3.5M
  • How likely is it that a customer will see the bug and how serious is the bug?
    Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
    What CTS failures are caused by this bug?

Every customer who downloads the distribution will "feel" the additional 3.5M, but there is no associated functional issue.

  • What is the cost/risk of fixing the bug?
    There is little to no risk associated with this change. The functionality is new for 4.0, and has already been in place for some time. This change merely modifies the dependencies to re-use existing copies in the distribution, rather than adding duplicates.

How risky is the fix? How much work is the fix? Is the fix complicated?

  • Is there an impact on documentation or message strings?

There is no doc or message impact.

  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

Quicklook, EJB devtests (these leverage the ACC, so they could be affected)

  • Which is the targeted build of 4.0 for this fix?


  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.

This is not a new revision of the Weld dependencies, just a different packaging thereof.

Comment by michael.y.chen [ 09/May/13 ]

approved for B89.

Comment by phil.zampino [ 10/May/13 ]

Committed revision 61948 to 4.0 branch

Generated at Sat Jul 04 01:05:37 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.