6:35 p.m.
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
8:23 a.m.
New subject: [JBoss JIRA] Commented: (WELD-932) weld-osgi-bundle binds to invalid SLF4J package versions
[
https://issues.jboss.org/browse/WELD-932?page=com.atlassian.jira.plugin.s...
]
Sahoo Sahoo commented on WELD-932:
----------------------------------
There is a reason for embedding slf4j API and importing at the same time. I think
that's discussed in GlassFish forum, so check there. I agree about the version range
in Import-Package.
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
8:34 p.m.
New subject: [JBoss JIRA] Commented: (WELD-932) weld-osgi-bundle binds to invalid SLF4J package versions
[
https://issues.jboss.org/browse/WELD-932?page=com.atlassian.jira.plugin.s...
]
Ancoron Luciferis commented on WELD-932:
----------------------------------------
OK, I just gave a quick-shot at it.
However, can we have an updated version?
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
3:40 p.m.
New subject: [JBoss JIRA] Updated: (WELD-932) weld-osgi-bundle binds to invalid SLF4J package versions
[
https://issues.jboss.org/browse/WELD-932?page=com.atlassian.jira.plugin.s...
]
Ales Justin updated WELD-932:
-----------------------------
Fix Version/s: 1.2.0.Beta1
(was: 1.1.2.Final)
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.2.0.Beta1
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
2:14 p.m.
New subject: [JBoss JIRA] (WELD-932) weld-osgi-bundle binds to invalid SLF4J package versions
[
https://issues.jboss.org/browse/WELD-932?page=com.atlassian.jira.plugin.s...
]
Ales Justin commented on WELD-932:
----------------------------------
What's the updated version?
I see we currently use 1.5.10. Is that OK?
I don't wanna have direct mvn dependency with range,
but I can change that bundle's import will use range.
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.2.0.Beta1
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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:33 p.m.
New subject: [JBoss JIRA] (WELD-932) weld-osgi-bundle binds to invalid SLF4J package versions
[
https://issues.jboss.org/browse/WELD-932?page=com.atlassian.jira.plugin.s...
]
Ales Justin updated WELD-932:
-----------------------------
Fix Version/s: 1.2.0.Beta1
(was: 1.1.3.Final)
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.2.0.Beta1
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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:25 p.m.
New subject: [JBoss JIRA] (WELD-932) weld-osgi-bundle binds to invalid SLF4J package versions
[
https://issues.jboss.org/browse/WELD-932?page=com.atlassian.jira.plugin.s...
]
Ancoron Luciferis updated WELD-932:
-----------------------------------
Attachment: weld-932-master.patch
Hm, another postpone to 1.2? So there will be no 1.1.4 release?
I have a quite simple patch to this problem that I'm using since I filed this bug.
I've updated it to the latest master:
[^weld-932-master.patch]
So I would like to see a 1.1.4 release that may be used as a direct replacement for
previous 1.1.x versions, e.g. in GlassFish 3.x (which depends on 1.1.2.Final currently).
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.2.0.Beta1
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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:23 p.m.
New subject: [JBoss JIRA] (WELD-932) weld-osgi-bundle binds to invalid SLF4J package versions
[
https://issues.jboss.org/browse/WELD-932?page=com.atlassian.jira.plugin.s...
]
Ales Justin reassigned WELD-932:
--------------------------------
Assignee: Ales Justin
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.2.0.Beta1
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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:38 p.m.
New subject: [JBoss JIRA] (WELD-932) weld-osgi-bundle binds to invalid SLF4J package versions
[
https://issues.jboss.org/browse/WELD-932?page=com.atlassian.jira.plugin.s...
]
Ales Justin updated WELD-932:
-----------------------------
Fix Version/s: 1.1.3.SP1
(was: 1.2.0.Beta1)
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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:54 p.m.
New subject: [JBoss JIRA] (WELD-932) weld-osgi-bundle binds to invalid SLF4J package versions
[
https://issues.jboss.org/browse/WELD-932?page=com.atlassian.jira.plugin.s...
]
Ales Justin resolved WELD-932.
------------------------------
Resolution: Done
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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:54 p.m.
New subject: [JBoss JIRA] (WELD-932) weld-osgi-bundle binds to invalid SLF4J package versions
[
https://issues.jboss.org/browse/WELD-932?page=com.atlassian.jira.plugin.s...
]
Ancoron Luciferis commented on WELD-932:
----------------------------------------
Thank you very much! :)
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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
4548
days inactive
4679
days old
10 comments
9 participants
participants (9)
-
Ales Justin (Assigned) (JIRA) -
Ales Justin (Commented) (JIRA)
-
Ales Justin (JIRA)
-
Ales Justin (Resolved) (JIRA)
-
Ales Justin (Updated) (JIRA)
-
Ancoron Luciferis (Commented) (JIRA)
-
Ancoron Luciferis (JIRA)
-
Ancoron Luciferis (Updated) (JIRA)
-
Sahoo Sahoo (JIRA)