Issue Details (XML | Word | Printable)

Key: GLASSFISH-18369
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Critical Critical
Assignee: jitu
Reporter: Sanjeeb Sahoo
Votes: 1
Watchers: 1

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

weld dependencies are part of distribution

Created: 15/Feb/12 01:10 PM   Updated: 01/Mar/13 07:10 PM   Resolved: 01/Mar/13 07:10 PM
Component/s: cdi
Affects Version/s: 4.0_b23
Fix Version/s: 4.0

Time Tracking:
Not Specified

Participants: jitu, jthoennes, Sanjeeb Sahoo, Shing Wai Chan and Sivakumar Thyagarajan

 Description  « Hide

In trunk build, I am seeing various weld dependencies being part of distribution when they should not be. e.g.,

and may be others?

This will cause all kinds of classloading issues as users won't be able to use different versions of these jars in their application. So, they must be removed from distribution.

Sivakumar Thyagarajan added a comment - 15/Feb/12 04:28 PM

It appears that the glassfish-web packager zip brings in slf4j and cal10n, because of maven dependencies of webtier-all. This may need to be fixed.

[ ../packager/glassfish-web] $ unzip -l target/ | grep "cal10n|slf"
28866 2012-02-15 21:26 glassfish3/glassfish/modules/cal10n-api.jar
23659 2012-02-15 21:26 glassfish3/glassfish/modules/slf4j-api.jar
41626 2012-02-15 21:26 glassfish3/glassfish/modules/slf4j-ext.jar

Transferring this issue to Shingwai

Sivakumar Thyagarajan added a comment - 15/Feb/12 04:29 PM

Shingwai, please let me know if there is anyway we can help. It appears that glassfish-web packager brings in weld osgi impl's dependencies such as cal10n, sfl4j.

Shing Wai Chan added a comment - 07/Mar/12 09:11 PM

The slf4j-api, slf4j-ext and cal10n-api are bring it by org.jboss.weld:weld-core:jar:1.1.4.Final:compile which is bring it by org.glassfish.web:web-sse:jar:4.0-SNAPSHOT:compile

Sanjeeb Sahoo added a comment - 02/Apr/12 05:57 PM


Can this bug be fixed by depending on javax.inject/javax.inject/1 instead of weld-osgi? More over, mark the dependency a provided scope dependency so that it does not get pulled in to the distribution. Could you do it ASAP?


jitu added a comment - 02/Apr/12 10:22 PM

If I do the following changes in web-sse/pom.xml, running into an exception. May be HK2 maven plugin needs an update.


  • <groupId>org.jboss.weld</groupId>
  • <artifactId>weld-osgi-bundle</artifactId>
    + <groupId>javax.inject</groupId>
    + <artifactId>javax.inject</artifactId>
    + <version>1</version>
    + <scope>provided</scope>

java.lang.ClassCastException: cannot be cast to com.sun.mirror.type.AnnotationType
at com.sun.mirror.util.SimpleDeclarationVisitor.visitParameterDeclaration(
at com.sun.mirror.util.DeclarationScanner.visitDeclaration(
at com.sun.mirror.util.DeclarationScanner.visitParameterDeclaration(
at com.sun.mirror.util.SourceOrderDeclScanner.visitExecutableDeclaration(
at com.sun.mirror.util.DeclarationScanner.visitMethodDeclaration(
at com.sun.mirror.util.SourceOrderDeclScanner.visitClassDeclaration(
at org.jvnet.hk2.config.generator.ConfigInjectorGenerator.process(
at com.sun.mirror.apt.AnnotationProcessors$CompositeAnnotationProcessor.process(
at com.sun.mirror.apt.AnnotationProcessors$CompositeAnnotationProcessor.process(
at com.sun.enterprise.module.maven.HK2CompileMojo$1.compileInProcess(
at com.sun.enterprise.module.maven.AptCompiler.compile(
at org.apache.maven.plugin.AbstractCompilerMojo.execute(
at com.sun.enterprise.module.maven.CompilerMojo.execute(
at com.sun.enterprise.module.maven.HK2CompileMojo.execute(
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(
at org.apache.maven.DefaultMaven.doExecute(
at org.apache.maven.DefaultMaven.execute(
at org.apache.maven.cli.MavenCli.main(
at org.apache.maven.cli.compat.CompatibleMain.main(
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
at java.lang.reflect.Method.invoke(
at org.codehaus.classworlds.Launcher.launchEnhanced(
at org.codehaus.classworlds.Launcher.launch(
at org.codehaus.classworlds.Launcher.mainWithExitCode(
at org.codehaus.classworlds.Launcher.main(

Sanjeeb Sahoo added a comment - 03/Apr/12 01:35 AM

I think this is happening because hk2 also depends on javax.inject. This is a guess only. If you don't want to spend a lot of time, then you could try changing the existing weld-osgi-bundle dependency to a provided scope dependency so that's its transitive dependencies are not pulled in by the build.

jitu added a comment - 03/Apr/12 06:22 PM

weld-osgi-bundle artifact is marked with provided scope
main/appserver/web/web-sse$ svn ci pom.xml
Sending pom.xml
Transmitting file data .
Committed revision 53341.

jthoennes added a comment - 04/Apr/12 10:09 AM

In reply to comment #6:
> I think this is happening because hk2 also depends on javax.inject. This is a
> guess only. If you don't want to spend a lot of time, then you could try
> changing the existing weld-osgi-bundle dependency to a provided scope dependency
> so that's its transitive dependencies are not pulled in by the build.

Sahoo, please could you elaborate on this? We are also struck by this issue.

And: Will this be corrected for at least GF 4.0?

Thanks, Jörg

Sanjeeb Sahoo added a comment - 07/Apr/12 06:39 PM

Jörg, pl file a separate bug for the hk2 plugin issue against HK2 project to get a faster response from the relevant developers.

Sanjeeb Sahoo added a comment - 07/Apr/12 06:40 PM

jitu, why is this bug still open?

jitu added a comment - 08/Apr/12 05:55 AM

Will close the issue if there aren't any comments.