[jboss-jira] [JBoss JIRA] (AS7-5958) Incorrect Candidate permutation failed due to a conflict between imports exception when using host and fragment bundles
Thomas Diesler (JIRA)
jira-events at lists.jboss.org
Thu Nov 15 10:55:22 EST 2012
[ https://issues.jboss.org/browse/AS7-5958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
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
More information about the jboss-jira
mailing list