[
https://jira.jboss.org/browse/JBOSGI-402?page=com.atlassian.jira.plugin.s...
]
David Bosschaert edited comment on JBOSGI-402 at 10/19/10 6:13 AM:
-------------------------------------------------------------------
After applying the Felix 3.0.4 resolver the test case still doesn't pass for us,
although the bundle does resolve for Felix (existing other tests do pass).
I stepped through the code and found the difference in the call to
ResultProcess.setModuleWires(). Our implementation fails where the Felix implementation
(ModuleImpl.setWires()) succeeds. Both are called from the same place seemingly with the
same arguments: FelixResolver.markResolvedModules().
Switching to another task now - this is where this work is now.
There are two failing test cases that expose the issue on jbosgi-framework and
jbosgi-resolver.
All changes that I made are on jbosgi402 branches on jbosgi-framework, jbosgi-resolver and
felix-framework (
http://github.com/jbosgi/felix-framework).
One interesting thing I noticed in Felix is that if I install both bundles that expose the
problem: slf4j-api and slf4j-log4j12 the latter (which is a fragment) reaches the
installed stated but not the resolved stated. However, the slf4j-api bundle (the host)
does move into the active state. This might be caused by the fact that the slf4j-log4j12
bundle is missing a dependency but it looks to me that the system is in an inconsistent
state.
was (Author: bosschaert):
After applying the Felix 3.0.4 resolver the test case still doesn't pass for us,
although the bundle does resolve for Felix (existing other tests do pass).
I stepped through the code and found the difference in the call to
ResultProcess.setModuleWires(). Our implementation fails where the Felix implementation
(ModuleImpl.setWires()) succeeds. Both are called from the same place:
FelixResolver.markResolvedModules().
Switching to another task now - this is where this work is now.
There are two failing test cases that expose the issue on jbosgi-framework and
jbosgi-resolver.
All changes that I made are on jbosgi402 branches on jbosgi-framework, jbosgi-resolver and
felix-framework (
http://github.com/jbosgi/felix-framework).
One interesting thing I noticed in Felix is that if I install both bundles that expose the
problem: slf4j-api and slf4j-log4j12 the latter (which is a fragment) reaches the
installed stated but not the resolved stated. However, the slf4j-api bundle (the host)
does move into the active state. This might be caused by the fact that the slf4j-log4j12
bundle is missing a dependency but it looks to me that the system is in an inconsistent
state.
Host importing package from Fragment doesn't resolve
----------------------------------------------------
Key: JBOSGI-402
URL:
https://jira.jboss.org/browse/JBOSGI-402
Project: JBoss OSGi
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: jboss-osgi-resolver
Affects Versions: JBossOSGi 1.0.0 Beta9
Reporter: David Bosschaert
Assignee: David Bosschaert
Fix For: JBossOSGi 1.0.0 Beta10
This issue arose when splitting up jbosgi-osgi-common into a number of proper bundles.
jbosgi-osgi-common contains
Bundle slf4j.api:
Export-Package: org.slf4j
Import-Package: org.slf4j.impl
There is also the slf4j-log4j12 fragment:
Fragment-Host: slf4j.api
Import-Package: org.slf4j
Export-Package: org.slf4j.impl
See testHostDependsOnFragmentPackage() in
http://github.com/jbosgi/jbosgi-resolver/blob/master/itest/src/test/java/...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira