[JBoss JIRA] (AS7-6054) https://github.com/jbosgi/jboss-as/tree/as5476
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-6054?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler updated AS7-6054:
--------------------------------
Summary: https://github.com/jbosgi/jboss-as/tree/as5476 (was: OSGi Bundle Resolution Exception not being revealed)
> https://github.com/jbosgi/jboss-as/tree/as5476
> ----------------------------------------------
>
> Key: AS7-6054
> URL: https://issues.jboss.org/browse/AS7-6054
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Affects Versions: 7.2.0.Alpha1
> Environment: Windows XP SP2
> Oracle JDK 1.6.0_32
> Reporter: Ed Roberts
>
> I am able to recreate a bundle resolution problem that gives very little help in where the cause lies.
> We deploy a set of Spring 3.1.1.RELEASE bundles in the bundles directory structure, exposed through the standalone.xml capabilities. Separately, a set of bundles are located in the deployments folder, and they include/use some Spring 3.0.7.RELEASE; e.g. beans and core. The reason for the duplication is because a particular LDAP bundle does not work with the later spring bundles. When I deploy the spring-security-ldap-3.1.1.RELEASE.jar in the deployments folder, I get the following WARNING in the console/log file
> {code}
> 2012-11-27 16:24:13,808 WARN [org.jboss.as.osgi](MSC service thread 1-5) JBAS011910: Cannot resolve requirements: []
> {code}
> The cause of the issue was located during a debug session, to be
> {code}
> Chain 1:
> org.springframework.security.ldap [HostBundleRevision[org.springframework.security.ldap:3.1.1.RELEASE]]
> import: null
> |
> export: osgi.wiring.package=org.springframework.beans
> org.springframework.beans [HostBundleRevision[org.springframework.beans:3.0.7.RELEASE]]
> Chain 2:
> org.springframework.security.ldap [HostBundleRevision[org.springframework.security.ldap:3.1.1.RELEASE]]
> import: null
> |
> export: osgi.wiring.package=org.springframework.context.support; uses:=org.springframework.beans
> org.springframework.context [HostBundleRevision[org.springframework.context:3.1.1.RELEASE]]
> import: null
> |
> export: osgi.wiring.package=org.springframework.beans
> org.springframework.beans [HostBundleRevision[org.springframework.beans:3.1.1.RELEASE]]
> {code}
> It seems that when there are multiple providers of a requirement, the requiring bundle is deemed invalid. That doesn't seem correct. Should it not just choose the first valid provider ? Either way, when the Unresolved Bundles are empty in BundleResolveProcessor, the details of the multiple providers should at least be logged as an ERROR as it prevents the bundle from being successfully resolved.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-6054) Package uses conflict with org.springframework.ldap
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-6054?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler updated AS7-6054:
--------------------------------
Summary: Package uses conflict with org.springframework.ldap (was: https://github.com/jbosgi/jboss-as/tree/as5476)
> Package uses conflict with org.springframework.ldap
> ---------------------------------------------------
>
> Key: AS7-6054
> URL: https://issues.jboss.org/browse/AS7-6054
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Affects Versions: 7.2.0.Alpha1
> Environment: Windows XP SP2
> Oracle JDK 1.6.0_32
> Reporter: Ed Roberts
>
> I am able to recreate a bundle resolution problem that gives very little help in where the cause lies.
> We deploy a set of Spring 3.1.1.RELEASE bundles in the bundles directory structure, exposed through the standalone.xml capabilities. Separately, a set of bundles are located in the deployments folder, and they include/use some Spring 3.0.7.RELEASE; e.g. beans and core. The reason for the duplication is because a particular LDAP bundle does not work with the later spring bundles. When I deploy the spring-security-ldap-3.1.1.RELEASE.jar in the deployments folder, I get the following WARNING in the console/log file
> {code}
> 2012-11-27 16:24:13,808 WARN [org.jboss.as.osgi](MSC service thread 1-5) JBAS011910: Cannot resolve requirements: []
> {code}
> The cause of the issue was located during a debug session, to be
> {code}
> Chain 1:
> org.springframework.security.ldap [HostBundleRevision[org.springframework.security.ldap:3.1.1.RELEASE]]
> import: null
> |
> export: osgi.wiring.package=org.springframework.beans
> org.springframework.beans [HostBundleRevision[org.springframework.beans:3.0.7.RELEASE]]
> Chain 2:
> org.springframework.security.ldap [HostBundleRevision[org.springframework.security.ldap:3.1.1.RELEASE]]
> import: null
> |
> export: osgi.wiring.package=org.springframework.context.support; uses:=org.springframework.beans
> org.springframework.context [HostBundleRevision[org.springframework.context:3.1.1.RELEASE]]
> import: null
> |
> export: osgi.wiring.package=org.springframework.beans
> org.springframework.beans [HostBundleRevision[org.springframework.beans:3.1.1.RELEASE]]
> {code}
> It seems that when there are multiple providers of a requirement, the requiring bundle is deemed invalid. That doesn't seem correct. Should it not just choose the first valid provider ? Either way, when the Unresolved Bundles are empty in BundleResolveProcessor, the details of the multiple providers should at least be logged as an ERROR as it prevents the bundle from being successfully resolved.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-5998) Failure in org.jboss.as.test.integration.osgi.stilts.StompletTestCase
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-5998?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler resolved AS7-5998.
---------------------------------
Fix Version/s: (was: 7.2.0.Alpha1)
Resolution: Duplicate Issue
Duplicates AS7-6016
> Failure in org.jboss.as.test.integration.osgi.stilts.StompletTestCase
> ---------------------------------------------------------------------
>
> Key: AS7-5998
> URL: https://issues.jboss.org/browse/AS7-5998
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Reporter: Brian Stansberry
> Assignee: Thomas Diesler
>
> StompletTestCase failed on http://teamcity.cafe-babe.org/viewLog.html?buildId=1589&tab=buildResultsD...
> Relevant details from the server log are below. It looks like BundleStateRevision.getModuleClassLoader() can return null if a ModuleLoadException is thrown, resulting in the NPE in the log.
> 16:45:42,074 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "stomplet-server-provider"
> 16:45:42,078 INFO [org.jboss.osgi.framework] (MSC service thread 1-5) JBOSGI011001: Bundle installed: stomplet-server-provider:0.0.0
> 16:45:42,090 WARN [org.jboss.as.osgi] (MSC service thread 1-7) JBAS011915: Cannot deploy from management operation, bypassing deployment unit processors: [org.jboss.netty:3.4.5.Final,location=org.jboss.netty:main]
> 16:45:42,353 INFO [org.jboss.osgi.framework] (MSC service thread 1-6) JBOSGI011001: Bundle installed: org.jboss.netty:3.4.5.Final
> 16:45:42,356 WARN [org.jboss.as.osgi] (MSC service thread 1-7) JBAS011915: Cannot deploy from management operation, bypassing deployment unit processors: [stilts-stomplet-server-bundle:0.1.26,location=org.projectodd.stilts:main]
> 16:45:42,394 INFO [org.jboss.osgi.framework] (MSC service thread 1-2) JBOSGI011001: Bundle installed: stilts-stomplet-server-bundle:0.1.26
> 16:45:42,424 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC00001: Failed to start service jboss.deployment.unit.stomplet-server-provider.Activate: org.jboss.msc.service.StartException in service jboss.deployment.unit.stomplet-server-provider.Activate: JBAS011968: Cannot start bundle: stomplet-server-provider:0.0.0
> at org.jboss.as.osgi.deployment.BundleActivateProcessor$BundleActivateService.start(BundleActivateProcessor.java:130)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_32]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_32]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_32]
> Caused by: org.osgi.framework.BundleException: JBOSGI011254: Cannot start bundle: stilts-stomplet-server-bundle:0.1.26
> at org.jboss.osgi.framework.internal.DefaultBundleLifecycleHandler.start(DefaultBundleLifecycleHandler.java:110)
> at org.jboss.as.osgi.service.BundleLifecycleIntegration.start(BundleLifecycleIntegration.java:167)
> at org.jboss.osgi.framework.internal.HostBundleState.transitionToActive(HostBundleState.java:292)
> at org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:228)
> at org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:516)
> at org.jboss.as.test.integration.osgi.stilts.bundle.StompletServerActivator.start(StompletServerActivator.java:41)
> at org.jboss.osgi.framework.internal.DefaultBundleLifecycleHandler.start(DefaultBundleLifecycleHandler.java:84)
> at org.jboss.as.osgi.service.BundleLifecycleIntegration.start(BundleLifecycleIntegration.java:174)
> at org.jboss.osgi.framework.internal.HostBundleState.transitionToActive(HostBundleState.java:292)
> at org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:228)
> at org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:522)
> at org.jboss.as.osgi.deployment.BundleActivateProcessor$BundleActivateService.start(BundleActivateProcessor.java:127)
> ... 5 more
> Caused by: java.lang.NullPointerException
> at org.jboss.osgi.framework.internal.HostBundleRevision.loadClass(HostBundleRevision.java:121)
> at org.jboss.osgi.framework.internal.AbstractBundleState.loadClass(AbstractBundleState.java:444)
> at org.jboss.osgi.framework.internal.HostBundleState.loadClass(HostBundleState.java:102)
> at org.jboss.osgi.framework.internal.DefaultBundleLifecycleHandler.start(DefaultBundleLifecycleHandler.java:76)
> ... 16 more
> 16:45:42,631 INFO [org.jboss.osgi.framework] (MSC service thread 1-7) JBOSGI011005: Bundle uninstalled: stomplet-server-provider:0.0.0
> 16:45:42,633 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) JBAS015877: Stopped deployment stomplet-server-provider in 4ms
> 16:45:42,634 ERROR [org.jboss.as.server] (management-handler-thread - 2) JBAS015870: Deploy of deployment "stomplet-server-provider" was rolled back with the following failure message:
> {"JBAS014671: Failed services" => {"jboss.deployment.unit.stomplet-server-provider.Activate" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.stomplet-server-provider.Activate: JBAS011968: Cannot start bundle: stomplet-server-provider:0.0.0
> Caused by: org.osgi.framework.BundleException: JBOSGI011254: Cannot start bundle: stilts-stomplet-server-bundle:0.1.26
> Caused by: java.lang.NullPointerException"}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-6054) OSGi Bundle Resolution Exception not being revealed
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-6054?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler updated AS7-6054:
--------------------------------
Fix Version/s: (was: 7.2.0.Alpha1)
Assignee: (was: Thomas Diesler)
> OSGi Bundle Resolution Exception not being revealed
> ---------------------------------------------------
>
> Key: AS7-6054
> URL: https://issues.jboss.org/browse/AS7-6054
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Affects Versions: 7.2.0.Alpha1
> Environment: Windows XP SP2
> Oracle JDK 1.6.0_32
> Reporter: Ed Roberts
>
> I am able to recreate a bundle resolution problem that gives very little help in where the cause lies.
> We deploy a set of Spring 3.1.1.RELEASE bundles in the bundles directory structure, exposed through the standalone.xml capabilities. Separately, a set of bundles are located in the deployments folder, and they include/use some Spring 3.0.7.RELEASE; e.g. beans and core. The reason for the duplication is because a particular LDAP bundle does not work with the later spring bundles. When I deploy the spring-security-ldap-3.1.1.RELEASE.jar in the deployments folder, I get the following WARNING in the console/log file
> {code}
> 2012-11-27 16:24:13,808 WARN [org.jboss.as.osgi](MSC service thread 1-5) JBAS011910: Cannot resolve requirements: []
> {code}
> The cause of the issue was located during a debug session, to be
> {code}
> Chain 1:
> org.springframework.security.ldap [HostBundleRevision[org.springframework.security.ldap:3.1.1.RELEASE]]
> import: null
> |
> export: osgi.wiring.package=org.springframework.beans
> org.springframework.beans [HostBundleRevision[org.springframework.beans:3.0.7.RELEASE]]
> Chain 2:
> org.springframework.security.ldap [HostBundleRevision[org.springframework.security.ldap:3.1.1.RELEASE]]
> import: null
> |
> export: osgi.wiring.package=org.springframework.context.support; uses:=org.springframework.beans
> org.springframework.context [HostBundleRevision[org.springframework.context:3.1.1.RELEASE]]
> import: null
> |
> export: osgi.wiring.package=org.springframework.beans
> org.springframework.beans [HostBundleRevision[org.springframework.beans:3.1.1.RELEASE]]
> {code}
> It seems that when there are multiple providers of a requirement, the requiring bundle is deemed invalid. That doesn't seem correct. Should it not just choose the first valid provider ? Either way, when the Unresolved Bundles are empty in BundleResolveProcessor, the details of the multiple providers should at least be logged as an ERROR as it prevents the bundle from being successfully resolved.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months