[weld-issues] [JBoss JIRA] (WELD-932) weld-osgi-bundle binds to invalid SLF4J package versions

weld-osgi-bundle binds to invalid SLF4J package versions -------------------------------------------------------- Key: WELD-932 URL: https://issues.jboss.org/browse/WELD-932 Project: Weld Issue Type: Bug Components: OSGi support Affects Versions: 1.1.1.Final Environment: OSGi + SLF4J 1.6.x Reporter: Ancoron Luciferis Assignee: Ales Justin Priority: Critical Fix For: 1.1.3.SP1 Attachments: weld-932-master.patch The current weld-osgi-bundle is a bit weird in multiple ways: # it packages slf4j 1.5.6 and at the same time imports it # 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: {noformat} 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 {noformat} 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: {noformat} 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 {noformat} Furthermore there are still some placeholders inside the {{META-INF/MANIFEST.MF}}: {noformat} Specification-Version: ${parsedVersion.osgiVersion} Maven-Version: ${maven.version} SCM: r${buildNumber} {noformat} The final goal should be to get rid of embedding the org.slf4j stuff altogether.