[JBoss JIRA] (AS7-5958) Incorrect Candidate permutation failed due to a conflict between imports exception when using host and fragment bundles
4:39 p.m.
Paul Illingworth created AS7-5958:
-------------------------------------
Summary: Incorrect Candidate permutation failed due to a conflict between
imports exception when using host and fragment bundles
Key: AS7-5958
URL: https://issues.jboss.org/browse/AS7-5958
Project: Application Server 7
Issue Type: Feature Request
Components: OSGi
Affects Versions: 7.2.0.Alpha1
Environment: Windows XP SP3
Reporter: Paul Illingworth
Assignee: Thomas Diesler
I am getting the following exception when my bundle is being resolved. I don't believe
this is correct.
{noformat}
2012-11-15 15:10:41,403 DEBUG [org.jboss.osgi.resolver](qtp4105020-187) Candidate
permutation failed due to a conflict between imports; will try another if possible.:
org.osgi.service.resolver.ResolutionException: Uses constraint violation. Unable to
resolve resource resource-console-web
[HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]] because it is exposed to package
'com.google.inject' from resources com.google.inject
[HostBundleRevision[com.google.inject:3.0.0]] and com.google.inject
[HostBundleRevision[com.google.inject:3.0.0]] via two dependency chains.
Chain 1:
resource-console-web [HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]]
import: null
|
export: osgi.wiring.package=com.google.inject
com.google.inject [HostBundleRevision[com.google.inject:3.0.0]]
Chain 2:
resource-console-web [HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]]
import: null
|
export: osgi.wiring.package=com.saaconsultants.gwt.rpc.server.servlets;
uses:=com.google.inject
reims-gwt-rpc [HostBundleRevision[reims-gwt-rpc:1.0.0.SNAPSHOT]]
import: null
|
export: osgi.wiring.package=com.google.inject
com.google.inject [HostBundleRevision[com.google.inject:3.0.0]]
at
org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1142)
at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:197)
at org.jboss.osgi.resolver.felix.StatelessResolver.resolve(StatelessResolver.java:56)
at
org.jboss.osgi.framework.internal.ResolverPlugin.resolveAndApply(ResolverPlugin.java:152)
at
org.jboss.osgi.framework.internal.ResolverPlugin.resolveAndApply(ResolverPlugin.java:167)
at
org.jboss.osgi.framework.internal.AbstractBundleState.ensureResolved(AbstractBundleState.java:598)
at
org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:214)
at
org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:520)
at
org.apache.felix.webconsole.internal.core.BundlesServlet.doPost(BundlesServlet.java:331)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:437)
at
org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:384)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.ops4j.pax.web.service.internal.HttpServiceStarted$2.invoke(HttpServiceStarted.java:209)
at org.ops4j.pax.web.service.internal.$Proxy39.service(Unknown Source)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:547)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:480)
at
org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:70)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:520)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:227)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:941)
at
org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:117)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:409)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:186)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:875)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at
org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:74)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)
at org.eclipse.jetty.server.Server.handle(Server.java:349)
at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:441)
at
org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:936)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:801)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:224)
at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:51)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
at java.lang.Thread.run(Thread.java:662)
2012-11-15 15:10:41,403 TRACE [org.jboss.osgi.framework](qtp4105020-187) Release framework
lock
{noformat}
It seems to be happening because the ResolverImpl.isCompatible() method is comparing two
capabilities; one is an AbstractBundleCapability and the other is a WrappedCapability that
contains the same instance of AbstractBundleCapability. The result of the comparison is
false.
As a quick hack I changed the equals method of WrappedCapability to
{noformat}
@Override
public boolean equals(Object obj)
{
return m_cap.equals(obj);
}
{noformat}
and that seemed to make it work and resolution was successful.
--
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:55 p.m.
[
https://issues.jboss.org/browse/AS7-5958?page=com.atlassian.jira.plugin.s...
]
Thomas Diesler updated AS7-5958:
--------------------------------
Fix Version/s: 7.2.0.Alpha1
Incorrect Candidate permutation failed due to a conflict between
imports exception when using host and fragment bundles
-----------------------------------------------------------------------------------------------------------------------
Key: AS7-5958
URL: https://issues.jboss.org/browse/AS7-5958
Project: Application Server 7
Issue Type: Feature Request
Components: OSGi
Affects Versions: 7.2.0.Alpha1
Environment: Windows XP SP3
Reporter: Paul Illingworth
Assignee: Thomas Diesler
Labels: OSGI
Fix For: 7.2.0.Alpha1
I am getting the following exception when my bundle is being resolved. I don't
believe this is correct.
{noformat}
2012-11-15 15:10:41,403 DEBUG [org.jboss.osgi.resolver](qtp4105020-187) Candidate
permutation failed due to a conflict between imports; will try another if possible.:
org.osgi.service.resolver.ResolutionException: Uses constraint violation. Unable to
resolve resource resource-console-web
[HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]] because it is exposed to package
'com.google.inject' from resources com.google.inject
[HostBundleRevision[com.google.inject:3.0.0]] and com.google.inject
[HostBundleRevision[com.google.inject:3.0.0]] via two dependency chains.
Chain 1:
resource-console-web [HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]]
import: null
|
export: osgi.wiring.package=com.google.inject
com.google.inject [HostBundleRevision[com.google.inject:3.0.0]]
Chain 2:
resource-console-web [HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]]
import: null
|
export: osgi.wiring.package=com.saaconsultants.gwt.rpc.server.servlets;
uses:=com.google.inject
reims-gwt-rpc [HostBundleRevision[reims-gwt-rpc:1.0.0.SNAPSHOT]]
import: null
|
export: osgi.wiring.package=com.google.inject
com.google.inject [HostBundleRevision[com.google.inject:3.0.0]]
at
org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1142)
at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:197)
at org.jboss.osgi.resolver.felix.StatelessResolver.resolve(StatelessResolver.java:56)
at
org.jboss.osgi.framework.internal.ResolverPlugin.resolveAndApply(ResolverPlugin.java:152)
at
org.jboss.osgi.framework.internal.ResolverPlugin.resolveAndApply(ResolverPlugin.java:167)
at
org.jboss.osgi.framework.internal.AbstractBundleState.ensureResolved(AbstractBundleState.java:598)
at
org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:214)
at
org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:520)
at
org.apache.felix.webconsole.internal.core.BundlesServlet.doPost(BundlesServlet.java:331)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:437)
at
org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:384)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.ops4j.pax.web.service.internal.HttpServiceStarted$2.invoke(HttpServiceStarted.java:209)
at org.ops4j.pax.web.service.internal.$Proxy39.service(Unknown Source)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:547)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:480)
at
org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:70)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:520)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:227)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:941)
at
org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:117)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:409)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:186)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:875)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at
org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:74)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)
at org.eclipse.jetty.server.Server.handle(Server.java:349)
at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:441)
at
org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:936)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:801)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:224)
at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:51)
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
at java.lang.Thread.run(Thread.java:662)
2012-11-15 15:10:41,403 TRACE [org.jboss.osgi.framework](qtp4105020-187) Release
framework lock
{noformat}
It seems to be happening because the ResolverImpl.isCompatible() method is comparing two
capabilities; one is an AbstractBundleCapability and the other is a WrappedCapability that
contains the same instance of AbstractBundleCapability. The result of the comparison is
false.
As a quick hack I changed the equals method of WrappedCapability to
{noformat}
@Override
public boolean equals(Object obj)
{
return m_cap.equals(obj);
}
{noformat}
and that seemed to make it work and resolution was successful.
--
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:55 p.m.
[
https://issues.jboss.org/browse/AS7-5958?page=com.atlassian.jira.plugin.s...
]
Thomas Diesler updated AS7-5958:
--------------------------------
Issue Type: Bug (was: Feature Request)
Incorrect Candidate permutation failed due to a conflict between
imports exception when using host and fragment bundles
-----------------------------------------------------------------------------------------------------------------------
Key: AS7-5958
URL: https://issues.jboss.org/browse/AS7-5958
Project: Application Server 7
Issue Type: Bug
Components: OSGi
Affects Versions: 7.2.0.Alpha1
Environment: Windows XP SP3
Reporter: Paul Illingworth
Assignee: Thomas Diesler
Labels: OSGI
Fix For: 7.2.0.Alpha1
I am getting the following exception when my bundle is being resolved. I don't
believe this is correct.
{noformat}
2012-11-15 15:10:41,403 DEBUG [org.jboss.osgi.resolver](qtp4105020-187) Candidate
permutation failed due to a conflict between imports; will try another if possible.:
org.osgi.service.resolver.ResolutionException: Uses constraint violation. Unable to
resolve resource resource-console-web
[HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]] because it is exposed to package
'com.google.inject' from resources com.google.inject
[HostBundleRevision[com.google.inject:3.0.0]] and com.google.inject
[HostBundleRevision[com.google.inject:3.0.0]] via two dependency chains.
Chain 1:
resource-console-web [HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]]
import: null
|
export: osgi.wiring.package=com.google.inject
com.google.inject [HostBundleRevision[com.google.inject:3.0.0]]
Chain 2:
resource-console-web [HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]]
import: null
|
export: osgi.wiring.package=com.saaconsultants.gwt.rpc.server.servlets;
uses:=com.google.inject
reims-gwt-rpc [HostBundleRevision[reims-gwt-rpc:1.0.0.SNAPSHOT]]
import: null
|
export: osgi.wiring.package=com.google.inject
com.google.inject [HostBundleRevision[com.google.inject:3.0.0]]
at
org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1142)
at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:197)
at org.jboss.osgi.resolver.felix.StatelessResolver.resolve(StatelessResolver.java:56)
at
org.jboss.osgi.framework.internal.ResolverPlugin.resolveAndApply(ResolverPlugin.java:152)
at
org.jboss.osgi.framework.internal.ResolverPlugin.resolveAndApply(ResolverPlugin.java:167)
at
org.jboss.osgi.framework.internal.AbstractBundleState.ensureResolved(AbstractBundleState.java:598)
at
org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:214)
at
org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:520)
at
org.apache.felix.webconsole.internal.core.BundlesServlet.doPost(BundlesServlet.java:331)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:437)
at
org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:384)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.ops4j.pax.web.service.internal.HttpServiceStarted$2.invoke(HttpServiceStarted.java:209)
at org.ops4j.pax.web.service.internal.$Proxy39.service(Unknown Source)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:547)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:480)
at
org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:70)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:520)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:227)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:941)
at
org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:117)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:409)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:186)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:875)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at
org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:74)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)
at org.eclipse.jetty.server.Server.handle(Server.java:349)
at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:441)
at
org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:936)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:801)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:224)
at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:51)
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
at java.lang.Thread.run(Thread.java:662)
2012-11-15 15:10:41,403 TRACE [org.jboss.osgi.framework](qtp4105020-187) Release
framework lock
{noformat}
It seems to be happening because the ResolverImpl.isCompatible() method is comparing two
capabilities; one is an AbstractBundleCapability and the other is a WrappedCapability that
contains the same instance of AbstractBundleCapability. The result of the comparison is
false.
As a quick hack I changed the equals method of WrappedCapability to
{noformat}
@Override
public boolean equals(Object obj)
{
return m_cap.equals(obj);
}
{noformat}
and that seemed to make it work and resolution was successful.
--
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
6:06 p.m.
[
https://issues.jboss.org/browse/AS7-5958?page=com.atlassian.jira.plugin.s...
]
Paul Illingworth commented on AS7-5958:
---------------------------------------
I am not suggesting this is right but it seems to work for me
{noformat}
@Override
public boolean equals(Object obj)
{
if (obj == null)
{
return false;
}
if (this == obj)
{
return true;
}
if (!(obj instanceof WrappedCapability)) {
return m_cap.equals(obj);
} else {
final WrappedCapability other = (WrappedCapability) obj;
if (m_host != other.m_host && (m_host == null ||
!m_host.equals(other.m_host)))
{
return false;
}
if (m_cap != other.m_cap && (m_cap == null ||
!m_cap.equals(other.m_cap)))
{
return false;
}
return true;
}
}
{noformat}
Incorrect Candidate permutation failed due to a conflict between
imports exception when using host and fragment bundles
-----------------------------------------------------------------------------------------------------------------------
Key: AS7-5958
URL: https://issues.jboss.org/browse/AS7-5958
Project: Application Server 7
Issue Type: Bug
Components: OSGi
Affects Versions: 7.2.0.Alpha1
Environment: Windows XP SP3
Reporter: Paul Illingworth
Assignee: Thomas Diesler
Labels: OSGI
Fix For: 7.2.0.Alpha1
I am getting the following exception when my bundle is being resolved. I don't
believe this is correct.
{noformat}
2012-11-15 15:10:41,403 DEBUG [org.jboss.osgi.resolver](qtp4105020-187) Candidate
permutation failed due to a conflict between imports; will try another if possible.:
org.osgi.service.resolver.ResolutionException: Uses constraint violation. Unable to
resolve resource resource-console-web
[HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]] because it is exposed to package
'com.google.inject' from resources com.google.inject
[HostBundleRevision[com.google.inject:3.0.0]] and com.google.inject
[HostBundleRevision[com.google.inject:3.0.0]] via two dependency chains.
Chain 1:
resource-console-web [HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]]
import: null
|
export: osgi.wiring.package=com.google.inject
com.google.inject [HostBundleRevision[com.google.inject:3.0.0]]
Chain 2:
resource-console-web [HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]]
import: null
|
export: osgi.wiring.package=com.saaconsultants.gwt.rpc.server.servlets;
uses:=com.google.inject
reims-gwt-rpc [HostBundleRevision[reims-gwt-rpc:1.0.0.SNAPSHOT]]
import: null
|
export: osgi.wiring.package=com.google.inject
com.google.inject [HostBundleRevision[com.google.inject:3.0.0]]
at
org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1142)
at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:197)
at org.jboss.osgi.resolver.felix.StatelessResolver.resolve(StatelessResolver.java:56)
at
org.jboss.osgi.framework.internal.ResolverPlugin.resolveAndApply(ResolverPlugin.java:152)
at
org.jboss.osgi.framework.internal.ResolverPlugin.resolveAndApply(ResolverPlugin.java:167)
at
org.jboss.osgi.framework.internal.AbstractBundleState.ensureResolved(AbstractBundleState.java:598)
at
org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:214)
at
org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:520)
at
org.apache.felix.webconsole.internal.core.BundlesServlet.doPost(BundlesServlet.java:331)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:437)
at
org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:384)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.ops4j.pax.web.service.internal.HttpServiceStarted$2.invoke(HttpServiceStarted.java:209)
at org.ops4j.pax.web.service.internal.$Proxy39.service(Unknown Source)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:547)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:480)
at
org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:70)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:520)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:227)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:941)
at
org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:117)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:409)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:186)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:875)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at
org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:74)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)
at org.eclipse.jetty.server.Server.handle(Server.java:349)
at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:441)
at
org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:936)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:801)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:224)
at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:51)
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
at java.lang.Thread.run(Thread.java:662)
2012-11-15 15:10:41,403 TRACE [org.jboss.osgi.framework](qtp4105020-187) Release
framework lock
{noformat}
It seems to be happening because the ResolverImpl.isCompatible() method is comparing two
capabilities; one is an AbstractBundleCapability and the other is a WrappedCapability that
contains the same instance of AbstractBundleCapability. The result of the comparison is
false.
As a quick hack I changed the equals method of WrappedCapability to
{noformat}
@Override
public boolean equals(Object obj)
{
return m_cap.equals(obj);
}
{noformat}
and that seemed to make it work and resolution was successful.
--
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
11:21 p.m.
[
https://issues.jboss.org/browse/AS7-5958?page=com.atlassian.jira.plugin.s...
]
Thomas Diesler commented on AS7-5958:
-------------------------------------
Would you be able to isolate this and show me a set of relevant manifest snippets so that
I can create a resolver test case [here|https://github.com/jbosgi/jbosgi-resolver]?
Perhaps you even like to provide pull request (with test).
Incorrect Candidate permutation failed due to a conflict between
imports exception when using host and fragment bundles
-----------------------------------------------------------------------------------------------------------------------
Key: AS7-5958
URL: https://issues.jboss.org/browse/AS7-5958
Project: Application Server 7
Issue Type: Bug
Components: OSGi
Affects Versions: 7.2.0.Alpha1
Environment: Windows XP SP3
Reporter: Paul Illingworth
Assignee: Thomas Diesler
Labels: OSGI
Fix For: 7.2.0.Alpha1
I am getting the following exception when my bundle is being resolved. I don't
believe this is correct.
{noformat}
2012-11-15 15:10:41,403 DEBUG [org.jboss.osgi.resolver](qtp4105020-187) Candidate
permutation failed due to a conflict between imports; will try another if possible.:
org.osgi.service.resolver.ResolutionException: Uses constraint violation. Unable to
resolve resource resource-console-web
[HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]] because it is exposed to package
'com.google.inject' from resources com.google.inject
[HostBundleRevision[com.google.inject:3.0.0]] and com.google.inject
[HostBundleRevision[com.google.inject:3.0.0]] via two dependency chains.
Chain 1:
resource-console-web [HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]]
import: null
|
export: osgi.wiring.package=com.google.inject
com.google.inject [HostBundleRevision[com.google.inject:3.0.0]]
Chain 2:
resource-console-web [HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]]
import: null
|
export: osgi.wiring.package=com.saaconsultants.gwt.rpc.server.servlets;
uses:=com.google.inject
reims-gwt-rpc [HostBundleRevision[reims-gwt-rpc:1.0.0.SNAPSHOT]]
import: null
|
export: osgi.wiring.package=com.google.inject
com.google.inject [HostBundleRevision[com.google.inject:3.0.0]]
at
org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1142)
at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:197)
at org.jboss.osgi.resolver.felix.StatelessResolver.resolve(StatelessResolver.java:56)
at
org.jboss.osgi.framework.internal.ResolverPlugin.resolveAndApply(ResolverPlugin.java:152)
at
org.jboss.osgi.framework.internal.ResolverPlugin.resolveAndApply(ResolverPlugin.java:167)
at
org.jboss.osgi.framework.internal.AbstractBundleState.ensureResolved(AbstractBundleState.java:598)
at
org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:214)
at
org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:520)
at
org.apache.felix.webconsole.internal.core.BundlesServlet.doPost(BundlesServlet.java:331)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:437)
at
org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:384)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.ops4j.pax.web.service.internal.HttpServiceStarted$2.invoke(HttpServiceStarted.java:209)
at org.ops4j.pax.web.service.internal.$Proxy39.service(Unknown Source)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:547)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:480)
at
org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:70)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:520)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:227)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:941)
at
org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:117)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:409)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:186)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:875)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at
org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:74)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)
at org.eclipse.jetty.server.Server.handle(Server.java:349)
at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:441)
at
org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:936)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:801)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:224)
at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:51)
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
at java.lang.Thread.run(Thread.java:662)
2012-11-15 15:10:41,403 TRACE [org.jboss.osgi.framework](qtp4105020-187) Release
framework lock
{noformat}
It seems to be happening because the ResolverImpl.isCompatible() method is comparing two
capabilities; one is an AbstractBundleCapability and the other is a WrappedCapability that
contains the same instance of AbstractBundleCapability. The result of the comparison is
false.
As a quick hack I changed the equals method of WrappedCapability to
{noformat}
@Override
public boolean equals(Object obj)
{
return m_cap.equals(obj);
}
{noformat}
and that seemed to make it work and resolution was successful.
--
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
9:27 a.m.
[
https://issues.jboss.org/browse/AS7-5958?page=com.atlassian.jira.plugin.s...
]
Thomas Diesler edited comment on AS7-5958 at 11/16/12 3:26 AM:
---------------------------------------------------------------
Dependent issue created: [FELIX-3759|https://issues.apache.org/jira/browse/FELIX-3759]
was (Author: thomas.diesler):
Dependent issue created: FELIX-3759
Incorrect Candidate permutation failed due to a conflict between
imports exception when using host and fragment bundles
-----------------------------------------------------------------------------------------------------------------------
Key: AS7-5958
URL: https://issues.jboss.org/browse/AS7-5958
Project: Application Server 7
Issue Type: Bug
Components: OSGi
Affects Versions: 7.2.0.Alpha1
Environment: Windows XP SP3
Reporter: Paul Illingworth
Assignee: Thomas Diesler
Labels: OSGI
Fix For: 7.2.0.Alpha1
I am getting the following exception when my bundle is being resolved. I don't
believe this is correct.
{noformat}
2012-11-15 15:10:41,403 DEBUG [org.jboss.osgi.resolver](qtp4105020-187) Candidate
permutation failed due to a conflict between imports; will try another if possible.:
org.osgi.service.resolver.ResolutionException: Uses constraint violation. Unable to
resolve resource resource-console-web
[HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]] because it is exposed to package
'com.google.inject' from resources com.google.inject
[HostBundleRevision[com.google.inject:3.0.0]] and com.google.inject
[HostBundleRevision[com.google.inject:3.0.0]] via two dependency chains.
Chain 1:
resource-console-web [HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]]
import: null
|
export: osgi.wiring.package=com.google.inject
com.google.inject [HostBundleRevision[com.google.inject:3.0.0]]
Chain 2:
resource-console-web [HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]]
import: null
|
export: osgi.wiring.package=com.saaconsultants.gwt.rpc.server.servlets;
uses:=com.google.inject
reims-gwt-rpc [HostBundleRevision[reims-gwt-rpc:1.0.0.SNAPSHOT]]
import: null
|
export: osgi.wiring.package=com.google.inject
com.google.inject [HostBundleRevision[com.google.inject:3.0.0]]
at
org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1142)
at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:197)
at org.jboss.osgi.resolver.felix.StatelessResolver.resolve(StatelessResolver.java:56)
at
org.jboss.osgi.framework.internal.ResolverPlugin.resolveAndApply(ResolverPlugin.java:152)
at
org.jboss.osgi.framework.internal.ResolverPlugin.resolveAndApply(ResolverPlugin.java:167)
at
org.jboss.osgi.framework.internal.AbstractBundleState.ensureResolved(AbstractBundleState.java:598)
at
org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:214)
at
org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:520)
at
org.apache.felix.webconsole.internal.core.BundlesServlet.doPost(BundlesServlet.java:331)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:437)
at
org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:384)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.ops4j.pax.web.service.internal.HttpServiceStarted$2.invoke(HttpServiceStarted.java:209)
at org.ops4j.pax.web.service.internal.$Proxy39.service(Unknown Source)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:547)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:480)
at
org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:70)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:520)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:227)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:941)
at
org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:117)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:409)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:186)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:875)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at
org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:74)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)
at org.eclipse.jetty.server.Server.handle(Server.java:349)
at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:441)
at
org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:936)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:801)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:224)
at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:51)
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
at java.lang.Thread.run(Thread.java:662)
2012-11-15 15:10:41,403 TRACE [org.jboss.osgi.framework](qtp4105020-187) Release
framework lock
{noformat}
It seems to be happening because the ResolverImpl.isCompatible() method is comparing two
capabilities; one is an AbstractBundleCapability and the other is a WrappedCapability that
contains the same instance of AbstractBundleCapability. The result of the comparison is
false.
As a quick hack I changed the equals method of WrappedCapability to
{noformat}
@Override
public boolean equals(Object obj)
{
return m_cap.equals(obj);
}
{noformat}
and that seemed to make it work and resolution was successful.
--
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
12:20 p.m.
[
https://issues.jboss.org/browse/AS7-5958?page=com.atlassian.jira.plugin.s...
]
Paul Illingworth commented on AS7-5958:
---------------------------------------
I have forked the code from github and if I understand the code enough I will try and put
together a test case.
Incorrect Candidate permutation failed due to a conflict between
imports exception when using host and fragment bundles
-----------------------------------------------------------------------------------------------------------------------
Key: AS7-5958
URL: https://issues.jboss.org/browse/AS7-5958
Project: Application Server 7
Issue Type: Bug
Components: OSGi
Affects Versions: 7.2.0.Alpha1
Environment: Windows XP SP3
Reporter: Paul Illingworth
Assignee: Thomas Diesler
Labels: OSGI
Fix For: 7.2.0.Alpha1
I am getting the following exception when my bundle is being resolved. I don't
believe this is correct.
{noformat}
2012-11-15 15:10:41,403 DEBUG [org.jboss.osgi.resolver](qtp4105020-187) Candidate
permutation failed due to a conflict between imports; will try another if possible.:
org.osgi.service.resolver.ResolutionException: Uses constraint violation. Unable to
resolve resource resource-console-web
[HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]] because it is exposed to package
'com.google.inject' from resources com.google.inject
[HostBundleRevision[com.google.inject:3.0.0]] and com.google.inject
[HostBundleRevision[com.google.inject:3.0.0]] via two dependency chains.
Chain 1:
resource-console-web [HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]]
import: null
|
export: osgi.wiring.package=com.google.inject
com.google.inject [HostBundleRevision[com.google.inject:3.0.0]]
Chain 2:
resource-console-web [HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]]
import: null
|
export: osgi.wiring.package=com.saaconsultants.gwt.rpc.server.servlets;
uses:=com.google.inject
reims-gwt-rpc [HostBundleRevision[reims-gwt-rpc:1.0.0.SNAPSHOT]]
import: null
|
export: osgi.wiring.package=com.google.inject
com.google.inject [HostBundleRevision[com.google.inject:3.0.0]]
at
org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1142)
at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:197)
at org.jboss.osgi.resolver.felix.StatelessResolver.resolve(StatelessResolver.java:56)
at
org.jboss.osgi.framework.internal.ResolverPlugin.resolveAndApply(ResolverPlugin.java:152)
at
org.jboss.osgi.framework.internal.ResolverPlugin.resolveAndApply(ResolverPlugin.java:167)
at
org.jboss.osgi.framework.internal.AbstractBundleState.ensureResolved(AbstractBundleState.java:598)
at
org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:214)
at
org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:520)
at
org.apache.felix.webconsole.internal.core.BundlesServlet.doPost(BundlesServlet.java:331)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:437)
at
org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:384)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.ops4j.pax.web.service.internal.HttpServiceStarted$2.invoke(HttpServiceStarted.java:209)
at org.ops4j.pax.web.service.internal.$Proxy39.service(Unknown Source)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:547)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:480)
at
org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:70)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:520)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:227)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:941)
at
org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:117)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:409)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:186)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:875)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at
org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:74)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)
at org.eclipse.jetty.server.Server.handle(Server.java:349)
at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:441)
at
org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:936)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:801)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:224)
at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:51)
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
at java.lang.Thread.run(Thread.java:662)
2012-11-15 15:10:41,403 TRACE [org.jboss.osgi.framework](qtp4105020-187) Release
framework lock
{noformat}
It seems to be happening because the ResolverImpl.isCompatible() method is comparing two
capabilities; one is an AbstractBundleCapability and the other is a WrappedCapability that
contains the same instance of AbstractBundleCapability. The result of the comparison is
false.
As a quick hack I changed the equals method of WrappedCapability to
{noformat}
@Override
public boolean equals(Object obj)
{
return m_cap.equals(obj);
}
{noformat}
and that seemed to make it work and resolution was successful.
--
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
1:27 p.m.
[
https://issues.jboss.org/browse/AS7-5958?page=com.atlassian.jira.plugin.s...
]
Thomas Diesler updated AS7-5958:
--------------------------------
Fix Version/s: (was: 7.2.0.Alpha1)
Incorrect Candidate permutation failed due to a conflict between
imports exception when using host and fragment bundles
-----------------------------------------------------------------------------------------------------------------------
Key: AS7-5958
URL: https://issues.jboss.org/browse/AS7-5958
Project: Application Server 7
Issue Type: Bug
Components: OSGi
Affects Versions: 7.2.0.Alpha1
Environment: Windows XP SP3
Reporter: Paul Illingworth
Assignee: Thomas Diesler
Labels: OSGI
I am getting the following exception when my bundle is being resolved. I don't
believe this is correct.
{noformat}
2012-11-15 15:10:41,403 DEBUG [org.jboss.osgi.resolver](qtp4105020-187) Candidate
permutation failed due to a conflict between imports; will try another if possible.:
org.osgi.service.resolver.ResolutionException: Uses constraint violation. Unable to
resolve resource resource-console-web
[HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]] because it is exposed to package
'com.google.inject' from resources com.google.inject
[HostBundleRevision[com.google.inject:3.0.0]] and com.google.inject
[HostBundleRevision[com.google.inject:3.0.0]] via two dependency chains.
Chain 1:
resource-console-web [HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]]
import: null
|
export: osgi.wiring.package=com.google.inject
com.google.inject [HostBundleRevision[com.google.inject:3.0.0]]
Chain 2:
resource-console-web [HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]]
import: null
|
export: osgi.wiring.package=com.saaconsultants.gwt.rpc.server.servlets;
uses:=com.google.inject
reims-gwt-rpc [HostBundleRevision[reims-gwt-rpc:1.0.0.SNAPSHOT]]
import: null
|
export: osgi.wiring.package=com.google.inject
com.google.inject [HostBundleRevision[com.google.inject:3.0.0]]
at
org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1142)
at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:197)
at org.jboss.osgi.resolver.felix.StatelessResolver.resolve(StatelessResolver.java:56)
at
org.jboss.osgi.framework.internal.ResolverPlugin.resolveAndApply(ResolverPlugin.java:152)
at
org.jboss.osgi.framework.internal.ResolverPlugin.resolveAndApply(ResolverPlugin.java:167)
at
org.jboss.osgi.framework.internal.AbstractBundleState.ensureResolved(AbstractBundleState.java:598)
at
org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:214)
at
org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:520)
at
org.apache.felix.webconsole.internal.core.BundlesServlet.doPost(BundlesServlet.java:331)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:437)
at
org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:384)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.ops4j.pax.web.service.internal.HttpServiceStarted$2.invoke(HttpServiceStarted.java:209)
at org.ops4j.pax.web.service.internal.$Proxy39.service(Unknown Source)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:547)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:480)
at
org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:70)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:520)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:227)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:941)
at
org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:117)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:409)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:186)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:875)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at
org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:74)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)
at org.eclipse.jetty.server.Server.handle(Server.java:349)
at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:441)
at
org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:936)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:801)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:224)
at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:51)
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
at java.lang.Thread.run(Thread.java:662)
2012-11-15 15:10:41,403 TRACE [org.jboss.osgi.framework](qtp4105020-187) Release
framework lock
{noformat}
It seems to be happening because the ResolverImpl.isCompatible() method is comparing two
capabilities; one is an AbstractBundleCapability and the other is a WrappedCapability that
contains the same instance of AbstractBundleCapability. The result of the comparison is
false.
As a quick hack I changed the equals method of WrappedCapability to
{noformat}
@Override
public boolean equals(Object obj)
{
return m_cap.equals(obj);
}
{noformat}
and that seemed to make it work and resolution was successful.
--
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
6:32 p.m.
[
https://issues.jboss.org/browse/AS7-5958?page=com.atlassian.jira.plugin.s...
]
Paul Illingworth commented on AS7-5958:
---------------------------------------
I have created a test case using manifests from a subset of the bundles that are causing
me issues but it all resolves correctly.
What I have noticed is that my test case only ever causes a single instance of the
WrappedResource class for the com.google.inject host bundle to be created whereas when
running in JBoss I get 2 instances of WrappedResource both containing a reference to the
com.google.inject host bundle.
Incorrect Candidate permutation failed due to a conflict between
imports exception when using host and fragment bundles
-----------------------------------------------------------------------------------------------------------------------
Key: AS7-5958
URL: https://issues.jboss.org/browse/AS7-5958
Project: Application Server 7
Issue Type: Bug
Components: OSGi
Affects Versions: 7.2.0.Alpha1
Environment: Windows XP SP3
Reporter: Paul Illingworth
Assignee: Thomas Diesler
Labels: OSGI
I am getting the following exception when my bundle is being resolved. I don't
believe this is correct.
{noformat}
2012-11-15 15:10:41,403 DEBUG [org.jboss.osgi.resolver](qtp4105020-187) Candidate
permutation failed due to a conflict between imports; will try another if possible.:
org.osgi.service.resolver.ResolutionException: Uses constraint violation. Unable to
resolve resource resource-console-web
[HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]] because it is exposed to package
'com.google.inject' from resources com.google.inject
[HostBundleRevision[com.google.inject:3.0.0]] and com.google.inject
[HostBundleRevision[com.google.inject:3.0.0]] via two dependency chains.
Chain 1:
resource-console-web [HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]]
import: null
|
export: osgi.wiring.package=com.google.inject
com.google.inject [HostBundleRevision[com.google.inject:3.0.0]]
Chain 2:
resource-console-web [HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]]
import: null
|
export: osgi.wiring.package=com.saaconsultants.gwt.rpc.server.servlets;
uses:=com.google.inject
reims-gwt-rpc [HostBundleRevision[reims-gwt-rpc:1.0.0.SNAPSHOT]]
import: null
|
export: osgi.wiring.package=com.google.inject
com.google.inject [HostBundleRevision[com.google.inject:3.0.0]]
at
org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1142)
at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:197)
at org.jboss.osgi.resolver.felix.StatelessResolver.resolve(StatelessResolver.java:56)
at
org.jboss.osgi.framework.internal.ResolverPlugin.resolveAndApply(ResolverPlugin.java:152)
at
org.jboss.osgi.framework.internal.ResolverPlugin.resolveAndApply(ResolverPlugin.java:167)
at
org.jboss.osgi.framework.internal.AbstractBundleState.ensureResolved(AbstractBundleState.java:598)
at
org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:214)
at
org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:520)
at
org.apache.felix.webconsole.internal.core.BundlesServlet.doPost(BundlesServlet.java:331)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:437)
at
org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:384)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.ops4j.pax.web.service.internal.HttpServiceStarted$2.invoke(HttpServiceStarted.java:209)
at org.ops4j.pax.web.service.internal.$Proxy39.service(Unknown Source)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:547)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:480)
at
org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:70)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:520)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:227)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:941)
at
org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:117)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:409)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:186)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:875)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at
org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:74)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)
at org.eclipse.jetty.server.Server.handle(Server.java:349)
at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:441)
at
org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:936)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:801)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:224)
at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:51)
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
at java.lang.Thread.run(Thread.java:662)
2012-11-15 15:10:41,403 TRACE [org.jboss.osgi.framework](qtp4105020-187) Release
framework lock
{noformat}
It seems to be happening because the ResolverImpl.isCompatible() method is comparing two
capabilities; one is an AbstractBundleCapability and the other is a WrappedCapability that
contains the same instance of AbstractBundleCapability. The result of the comparison is
false.
As a quick hack I changed the equals method of WrappedCapability to
{noformat}
@Override
public boolean equals(Object obj)
{
return m_cap.equals(obj);
}
{noformat}
and that seemed to make it work and resolution was successful.
--
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
6:34 p.m.
[
https://issues.jboss.org/browse/AS7-5958?page=com.atlassian.jira.plugin.s...
]
Paul Illingworth edited comment on AS7-5958 at 11/16/12 12:32 PM:
------------------------------------------------------------------
I have created a test case using manifests from a subset of the bundles that are causing
me issues but it all resolves correctly.
What I have noticed is that my test case only ever causes a single instance of the
WrappedResource class for the com.google.inject host to be created whereas when running in
JBoss I get 2 instances of WrappedResource each containing a reference to a different
instance of the com.google.inject host.
was (Author: pillingworth):
I have created a test case using manifests from a subset of the bundles that are
causing me issues but it all resolves correctly.
What I have noticed is that my test case only ever causes a single instance of the
WrappedResource class for the com.google.inject host bundle to be created whereas when
running in JBoss I get 2 instances of WrappedResource both containing a reference to the
com.google.inject host bundle.
Incorrect Candidate permutation failed due to a conflict between
imports exception when using host and fragment bundles
-----------------------------------------------------------------------------------------------------------------------
Key: AS7-5958
URL: https://issues.jboss.org/browse/AS7-5958
Project: Application Server 7
Issue Type: Bug
Components: OSGi
Affects Versions: 7.2.0.Alpha1
Environment: Windows XP SP3
Reporter: Paul Illingworth
Assignee: Thomas Diesler
Labels: OSGI
I am getting the following exception when my bundle is being resolved. I don't
believe this is correct.
{noformat}
2012-11-15 15:10:41,403 DEBUG [org.jboss.osgi.resolver](qtp4105020-187) Candidate
permutation failed due to a conflict between imports; will try another if possible.:
org.osgi.service.resolver.ResolutionException: Uses constraint violation. Unable to
resolve resource resource-console-web
[HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]] because it is exposed to package
'com.google.inject' from resources com.google.inject
[HostBundleRevision[com.google.inject:3.0.0]] and com.google.inject
[HostBundleRevision[com.google.inject:3.0.0]] via two dependency chains.
Chain 1:
resource-console-web [HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]]
import: null
|
export: osgi.wiring.package=com.google.inject
com.google.inject [HostBundleRevision[com.google.inject:3.0.0]]
Chain 2:
resource-console-web [HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]]
import: null
|
export: osgi.wiring.package=com.saaconsultants.gwt.rpc.server.servlets;
uses:=com.google.inject
reims-gwt-rpc [HostBundleRevision[reims-gwt-rpc:1.0.0.SNAPSHOT]]
import: null
|
export: osgi.wiring.package=com.google.inject
com.google.inject [HostBundleRevision[com.google.inject:3.0.0]]
at
org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1142)
at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:197)
at org.jboss.osgi.resolver.felix.StatelessResolver.resolve(StatelessResolver.java:56)
at
org.jboss.osgi.framework.internal.ResolverPlugin.resolveAndApply(ResolverPlugin.java:152)
at
org.jboss.osgi.framework.internal.ResolverPlugin.resolveAndApply(ResolverPlugin.java:167)
at
org.jboss.osgi.framework.internal.AbstractBundleState.ensureResolved(AbstractBundleState.java:598)
at
org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:214)
at
org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:520)
at
org.apache.felix.webconsole.internal.core.BundlesServlet.doPost(BundlesServlet.java:331)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:437)
at
org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:384)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.ops4j.pax.web.service.internal.HttpServiceStarted$2.invoke(HttpServiceStarted.java:209)
at org.ops4j.pax.web.service.internal.$Proxy39.service(Unknown Source)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:547)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:480)
at
org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:70)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:520)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:227)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:941)
at
org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:117)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:409)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:186)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:875)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at
org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:74)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)
at org.eclipse.jetty.server.Server.handle(Server.java:349)
at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:441)
at
org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:936)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:801)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:224)
at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:51)
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
at java.lang.Thread.run(Thread.java:662)
2012-11-15 15:10:41,403 TRACE [org.jboss.osgi.framework](qtp4105020-187) Release
framework lock
{noformat}
It seems to be happening because the ResolverImpl.isCompatible() method is comparing two
capabilities; one is an AbstractBundleCapability and the other is a WrappedCapability that
contains the same instance of AbstractBundleCapability. The result of the comparison is
false.
As a quick hack I changed the equals method of WrappedCapability to
{noformat}
@Override
public boolean equals(Object obj)
{
return m_cap.equals(obj);
}
{noformat}
and that seemed to make it work and resolution was successful.
--
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:35 p.m.
[
https://issues.jboss.org/browse/AS7-5958?page=com.atlassian.jira.plugin.s...
]
Paul Illingworth commented on AS7-5958:
---------------------------------------
I think the above code change fixes the symptom - its not the root cause of the problem.
It seems that when running in the JBoss AS7 there are two objects representing
com.google.inject, a AbstractHostedCapability and a WrappedCapability. When these are
compared (in the WrappedCapabilities equals) the comparison fails and so does
isCompatible().
Running the JUnit test case there is only ever one object representing com.google.inject,
a WrappedCapability and isCompatible() never then fails.
I have got as far as tracing the extra capability coming from the
ResolverImpl.getPackageSpaces() where it calls {{Wiring wiring =
rc.getWirings().get(resource);}} and then adding a capability to the list from the wiring
it obtained.
I am probably not going to be able to go much further - I am struggling a little as I
don't fully understand the code.
Incorrect Candidate permutation failed due to a conflict between
imports exception when using host and fragment bundles
-----------------------------------------------------------------------------------------------------------------------
Key: AS7-5958
URL: https://issues.jboss.org/browse/AS7-5958
Project: Application Server 7
Issue Type: Bug
Components: OSGi
Affects Versions: 7.2.0.Alpha1
Environment: Windows XP SP3
Reporter: Paul Illingworth
Assignee: Thomas Diesler
Labels: OSGI
I am getting the following exception when my bundle is being resolved. I don't
believe this is correct.
{noformat}
2012-11-15 15:10:41,403 DEBUG [org.jboss.osgi.resolver](qtp4105020-187) Candidate
permutation failed due to a conflict between imports; will try another if possible.:
org.osgi.service.resolver.ResolutionException: Uses constraint violation. Unable to
resolve resource resource-console-web
[HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]] because it is exposed to package
'com.google.inject' from resources com.google.inject
[HostBundleRevision[com.google.inject:3.0.0]] and com.google.inject
[HostBundleRevision[com.google.inject:3.0.0]] via two dependency chains.
Chain 1:
resource-console-web [HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]]
import: null
|
export: osgi.wiring.package=com.google.inject
com.google.inject [HostBundleRevision[com.google.inject:3.0.0]]
Chain 2:
resource-console-web [HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]]
import: null
|
export: osgi.wiring.package=com.saaconsultants.gwt.rpc.server.servlets;
uses:=com.google.inject
reims-gwt-rpc [HostBundleRevision[reims-gwt-rpc:1.0.0.SNAPSHOT]]
import: null
|
export: osgi.wiring.package=com.google.inject
com.google.inject [HostBundleRevision[com.google.inject:3.0.0]]
at
org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1142)
at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:197)
at org.jboss.osgi.resolver.felix.StatelessResolver.resolve(StatelessResolver.java:56)
at
org.jboss.osgi.framework.internal.ResolverPlugin.resolveAndApply(ResolverPlugin.java:152)
at
org.jboss.osgi.framework.internal.ResolverPlugin.resolveAndApply(ResolverPlugin.java:167)
at
org.jboss.osgi.framework.internal.AbstractBundleState.ensureResolved(AbstractBundleState.java:598)
at
org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:214)
at
org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:520)
at
org.apache.felix.webconsole.internal.core.BundlesServlet.doPost(BundlesServlet.java:331)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:437)
at
org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:384)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.ops4j.pax.web.service.internal.HttpServiceStarted$2.invoke(HttpServiceStarted.java:209)
at org.ops4j.pax.web.service.internal.$Proxy39.service(Unknown Source)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:547)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:480)
at
org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:70)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:520)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:227)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:941)
at
org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:117)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:409)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:186)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:875)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at
org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:74)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)
at org.eclipse.jetty.server.Server.handle(Server.java:349)
at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:441)
at
org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:936)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:801)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:224)
at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:51)
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
at java.lang.Thread.run(Thread.java:662)
2012-11-15 15:10:41,403 TRACE [org.jboss.osgi.framework](qtp4105020-187) Release
framework lock
{noformat}
It seems to be happening because the ResolverImpl.isCompatible() method is comparing two
capabilities; one is an AbstractBundleCapability and the other is a WrappedCapability that
contains the same instance of AbstractBundleCapability. The result of the comparison is
false.
As a quick hack I changed the equals method of WrappedCapability to
{noformat}
@Override
public boolean equals(Object obj)
{
return m_cap.equals(obj);
}
{noformat}
and that seemed to make it work and resolution was successful.
--
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
4168
days inactive
4173
days old
10 comments
2 participants
participants (2)
-
Paul Illingworth (JIRA) -
Thomas Diesler (JIRA)