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
            Priority: Critical
             Fix For: 1.1.2.Final


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.


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        
_______________________________________________
weld-issues mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/weld-issues

Reply via email to