Uploaded image for project: 'Weld'
  1. Weld
  2. WELD-932

weld-osgi-bundle binds to invalid SLF4J package versions

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Critical
    • Resolution: Done
    • Affects Version/s: 1.1.1.Final
    • Fix Version/s: 1.1.3.SP1
    • Component/s: OSGi support
    • Labels:
      None
    • Environment:

      OSGi + SLF4J 1.6.x

    • Estimated Difficulty:
      Low

      Description

      The current weld-osgi-bundle is a bit weird in multiple ways:

      1. it packages slf4j 1.5.6 and at the same time imports it
      2. the package import definition is not a range, although incompatible API's are known already (1.5.x vs. 1.6.x)

      The actual problem manifests itself e.g. in GlassFish 3.1+ with a deployed SLF4J 1.6.1:

      WARNING: Failed to deploy bundle com.something.support.web [319]
      org.glassfish.osgijavaeebase.DeploymentException: Deployment of com.something.support.web [319] failed because of following reason: Failed while deploying bundle com.something.support.web [319] : java.lang.RuntimeException: Failed to deploy bundle [ com.something.support.web [319] ], root cause: Exception while loading the app
      	at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:125)
      	at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154)
      	at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:107)
      	at org.glassfish.osgijavaeebase.JavaEEExtender.access$200(JavaEEExtender.java:61)
      	at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:151)
      	at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:148)
      	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
      	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
      	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
      	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
      	at java.lang.Thread.run(Thread.java:662)
      Caused by: java.lang.RuntimeException: Failed to deploy bundle [ com.something.support.web [319] ], root cause: Exception while loading the app
      	at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:196)
      	at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:118)
      	at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:121)
      	... 10 more
      Caused by: java.lang.NoSuchMethodError: org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
      	at org.slf4j.cal10n.LocLogger.info(LocLogger.java:122)
      	at org.jboss.weld.bootstrap.WeldBootstrap.<clinit>(WeldBootstrap.java:213)
      	at org.glassfish.weld.WeldDeployer.load(WeldDeployer.java:345)
      	at org.glassfish.weld.WeldDeployer.load(WeldDeployer.java:99)
      	at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:186)
      	at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:257)
      	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461)
      	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
      	at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:183)
      	... 12 more
      

      This introduces problems when someone deploys an application which in turn requires the SLF4J API 1.6.x.

      So I suggest to fix it like this:

      Import-Package:
       ...
       org.slf4j;version="[1.5.10,1.6)";resolution:=optional,
       org.slf4j.helpers;version="[1.5.10,1.6)";resolution:=optional,
       org.slf4j.spi;version="[1.5.10,1.6)";resolution:=optional
      

      Furthermore there are still some placeholders inside the META-INF/MANIFEST.MF:

      Specification-Version: ${parsedVersion.osgiVersion}
      Maven-Version: ${maven.version}
      SCM: r${buildNumber}
      

      The final goal should be to get rid of embedding the org.slf4j stuff altogether.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  alesj AleŇ° Justin
                  Reporter:
                  Ancoron Ancoron Luciferis
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  3 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: