-> richard
Lucas Galfaso wrote:
Hi All, 6.1.12.34 public static final String FRAGMENT_ATTACHMENT_DIRECTIVE = "fragment-attachment" Manifest header directive (named "fragment-attachment") identifying if and when a fragment may attach to a host bundle. The default value is "always". So the answer is not as happy as you thought. Regards, Lucas On Mon, Nov 17, 2008 at 5:31 PM, Stuart McCulloch <[EMAIL PROTECTED]> wrote:2008/11/18 Richard S. Hall <[EMAIL PROTECTED]>Walid "jo" Gedeon wrote:Hello Richard,I think the logic is correct. You cannot dynamically attach a fragment toan alreadyresolved host. Thus, the potential hosts for the fragment are only thosethat are notyet resolved.Hmm... ok, I wasnt aware of that.To be clear, the spec is purposely vague here. So, it doesn't forbid or mandate dynamic attachment.yes, looking at the core OSGi spec, page 48: "Before a bundle is resolved, all its Fragments must be attached." but earlier on in the spec, page 36, I found: "The framework must recognize the following directives for the Bundle-SymbolicName header: • fragment-attachment – Defines how fragments are allowed to be attached, see the fragments in Fragment Bundles on page 68. The following values are valid for this directive: • always – Fragments can attach at any time while the host is resolved or during the process of resolving. • never – No fragments are allowed. • resolve-time – Fragments must only be attached during resolving." though it doesn't state what the default setting is (perhaps 'resolve-time' ?) anyway, I don't think we support the "fragment-attachment" directive in Felix yet...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?Install the host and all fragments then start the host. That is all you need to do. All fragments will be attached when resolving the host. You don't need to start fragments, because they don't have an activator in the first place. -> richard 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-- Cheers, Stuart
