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 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. >>> >>> >> >> 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 >
