4:43 p.m.
Ed Roberts created AS7-6054:
-------------------------------
Summary: 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
Assignee: Thomas Diesler
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
4:47 p.m.
[
https://issues.jboss.org/browse/AS7-6054?page=com.atlassian.jira.plugin.s...
]
Thomas Diesler commented on AS7-6054:
-------------------------------------
How does this resolve in felix/equinox?
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
Assignee: Thomas Diesler
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
7:56 p.m.
[
https://issues.jboss.org/browse/AS7-6054?page=com.atlassian.jira.plugin.s...
]
Ed Roberts commented on AS7-6054:
---------------------------------
{code}
WARNING: %bundles.pluginTitle: Cannot start
org.osgi.framework.BundleException: The bundle
"org.springframework.security.ldap_3.1.1.RELEASE [69]" could not be resolved.
Reason: Package uses conflict: Import-Package: org.springframework.ldap;
version="[1.3.0,1.4.0)", Package uses conflict: Import-Package:
org.springframework.ldap.core; version="[1.3.0,1.4.0)", Package uses conflict:
Import-Package: org.springframework.ldap.core.support; version="[1.3.0,1.4.0)",
Package uses conflict: Import-Package: org.springframework.ldap.support;
version="[1.3.0,1.4.0)"
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolverError(AbstractBundle.java:1327)
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureException(AbstractBundle.java:1311)
at
org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:323)
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:299)
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:291)
at
org.apache.felix.webconsole.internal.core.BundlesServlet.doPost(BundlesServlet.java:298)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at
org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:493)
at
org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:418)
at
org.eclipse.equinox.http.servlet.internal.ServletRegistration.handleRequest(ServletRegistration.java:90)
at
org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:109)
at
org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:67)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at
org.eclipse.equinox.http.jetty.internal.HttpServerManager$InternalHttpServiceServlet.service(HttpServerManager.java:268)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
at org.mortbay.jetty.servlet.ServletHandler.dispatch(ServletHandler.java:677)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
at org.mortbay.http.HttpServer.service(HttpServer.java:909)
at org.mortbay.http.HttpConnection.service(HttpConnection.java:820)
at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:986)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:837)
at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:245)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
{code}
Hmmm, cryptic.
I am guessing by saying that the problem is with conflicting wires between one of our
bundle repackages of org.springframework.ldap (that is picking up a spring requirement
from the 3.0.7 set) and the spring-security-ldap 3.1.1 bundle, which aims to wire with our
bundle (that is picking up the same spring requirement from 3.1.1).
I will try to get to the bottom of that. The INSTALLED resolution status in JBoss OSGi is
understandable, but the extra output is definitely necessary to see why it wasn't
RESOLVED.
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
Assignee: Thomas Diesler
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
4189
days inactive
4189
days old
2 comments
2 participants
participants (2)
-
Ed Roberts (JIRA) -
Thomas Diesler (JIRA)