On Mon, Nov 17, 2008 at 7:25 PM, Richard S. Hall <[EMAIL PROTECTED]> wrote: > Originally in R4 I am pretty sure this was not required, perhaps it changed > later, but I am still not 100% convinced. I don't think the TCK verifies it, > but I would have to double check. Regardless, Felix doesn't support dynamic > attachment at this point.
Hey, I am very pleased on how Felix works and, even as it is working know, it has everything I need. My mail was just a simple clarification. Regards, Lucas > > -> 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 >>>>>> 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 >>> >>> >
