Hello Richard, > I think the logic is correct. You cannot dynamically attach a fragment to an already > resolved host. Thus, the potential hosts for the fragment are only those that are not > yet resolved. Hmm... ok, I wasnt aware of that.
> Are you resolving the host first before installing the fragment? Yes I am. So the steps would be: - install log4j -> Installed - install config fragment -> Installed - start config fragment -> Active (log4j now resolved) - start log4j -> Active. But what would happen if the host bundle has many fragments? Thanks, w On Mon, Nov 17, 2008 at 7:27 PM, Richard S. Hall <[EMAIL PROTECTED]>wrote: > I think the logic is correct. You cannot dynamically attach a fragment to > an already resolved host. Thus, the potential hosts for the fragment are > only those that are not yet resolved. > > Are you resolving the host first before installing the fragment? > > -> richard > > Walid "jo" Gedeon wrote: > >> Hello all, >> >> I was struggling to get a fragment installed for log4j configuration, >> setup as a fragment with host=org.apache.log4j. >> However, I would keep getting the error: >> >> org.osgi.framework.BundleException: Unresolved constraint in bundle 21: >> host; (bundle-symbolic-name=org.apache.log4j) >> >> (bundle 21 is my log4jconfig-fragment), and the log4j bundle (7) seems >> correctly installed: >> >> -> headers 7 >> >> Apache Jakarta log4j Plug-in (7) >> -------------------------------- >> Bundle-ClassPath = . >> Bundle-RequiredExecutionEnvironment = J2SE-1.4 >> Export-Package = >> org.apache.log4j,org.apache.log4j.chainsaw,org.apache.log4j.config,org.apache.log4j.helpers,org.apache.log4j.jdbc,org.apache.log4j.jmx,org.apac >> >> he.log4j.lf5,org.apache.log4j.lf5.config,org.apache.log4j.lf5.util,org.apache.log4j.lf5.viewer,org.apache.log4j.lf5.viewer.categoryexplorer,org.apache.log4j.lf5 >> .viewer.configure,org.apache.log4j.lf5.viewer.images,org.apache.log4j.net< >> http://org.apache.log4j.net >> >,org.apache.log4j.nt,org.apache.log4j.or,org.apache.log4j.or.jms, >> org.apache.log4j.or.sa <http://org.apache.log4j.or.sa> >> >> x,org.apache.log4j.spi,org.apache.log4j.varia,org.apache.log4j.xml >> Bundle-Version = 1.2.13.v200806030600 >> Manifest-Version = 1.0 >> Bundle-Vendor = Eclipse.org >> Bundle-ManifestVersion = 2 >> Eclipse-BuddyPolicy = registered >> Bundle-Name = Apache Jakarta log4j Plug-in >> Bundle-Localization = plugin >> Bundle-SymbolicName = org.apache.log4j >> >> In all case, stepping through the code (in >> org.apache.felix.framework.searchpolicy.R4SearchPolicyCore), it looks like >> the boolean checks have been reversed? >> >> private List getPotentialHosts(IModule fragment) >> { // ... >> IModule[] modules = m_factory.getModules(); >> for (int modIdx = 0; (hostReq != null) && (modIdx < >> modules.length); modIdx++) >> { >> if (!fragment.equals(modules[modIdx]) && >> !isResolved(modules[modIdx])) { ... >> I'm thinking this should be if >> (!fragment.equals(modules[modIdx]) && isResolved(modules[modIdx])) { >> the host bundle is resolved and it's not the same as the fragment bundle, >> and can be selected as a potential host: >> ICapability[] caps = >> modules[modIdx].getDefinition().getCapabilities(); >> for (int capIdx = 0; (caps != null) && (capIdx < >> caps.length); capIdx++) >> { >> if >> (caps[capIdx].getNamespace().equals(ICapability.HOST_NAMESPACE) >> && hostReq.isSatisfied(caps[capIdx]) >> && !modules[modIdx].isStale()) >> { >> hostList.add(modules[modIdx]); >> break; >> } >> } >> >> I've attached a patch for that change... Do you guys agree? or did I >> misunderstand some part of the logic? >> I can raise a defect and attach the patch if no one disagrees. >> >> Cheers, >> w >> >
