Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Received-SPF: pass (athena.apache.org: domain of mcculls@gmail.com designates
 74.125.46.153 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:references;
        b=aLug1yHloXPlmevwsjSciQkBOK+C/YMIhJSm9W1L6d3rWlNKsBlh+79MDTztoIRfvm
         Yke+hL0fDBkQ3Rfpidhi2Tc/9rC406Nszm1s1Li+xB9SsWxNqm77TYTdxeNR2HPqAclf
         gbE5MOnYYJRtrP9DYFEHntdyeNrAoduemvDG4=
Message-ID: <81f0d9c0811171131k66ccb5c1k3f94cd0823b49228@mail.gmail.com>
Date: Tue, 18 Nov 2008 03:31:52 +0800
From: "Stuart McCulloch" <mcculls@gmail.com>
To: dev@felix.apache.org
Subject: Re: Fragment-Host resolution fails (bug?)
In-Reply-To: <4921C43B.3020408@ungoverned.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_19136_16723987.1226950312113"
References: <120de6e60811170703o7a63b9b2kf3271d1436da4718@mail.gmail.com>
	 <4921B79B.3010003@ungoverned.org>
	 <120de6e60811171117v58ca9220ia7070785bab3166b@mail.gmail.com>
	 <4921C43B.3020408@ungoverned.org>

------=_Part_19136_16723987.1226950312113
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

2008/11/18 Richard S. Hall <heavy@ungoverned.org>

>
> 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 thos=
e
>>>
>>>
>> 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:
      =95 fragment-attachment =96 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:
         =95 always =96 Fragments can attach at any time while the host is
resolved or during the process of resolving.
         =95 never =96 No fragments are allowed.
         =95 resolve-time =96 Fragments must only be attached during resolv=
ing."

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 th=
e
> first place.
>
> -> richard
>
>
>  Thanks,
>> w
>>
>> On Mon, Nov 17, 2008 at 7:27 PM, Richard S. Hall <heavy@ungoverned.org
>> >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 ar=
e
>>> 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=3Dorg.apache.log4j.
>>>> However, I would keep getting the error:
>>>>
>>>> org.osgi.framework.BundleException: Unresolved constraint in bundle 21=
:
>>>> host; (bundle-symbolic-name=3Dorg.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 =3D .
>>>> Bundle-RequiredExecutionEnvironment =3D J2SE-1.4
>>>> Export-Package =3D
>>>>
>>>> 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.a=
pache.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 =3D 1.2.13.v200806030600
>>>> Manifest-Version =3D 1.0
>>>> Bundle-Vendor =3D Eclipse.org
>>>> Bundle-ManifestVersion =3D 2
>>>> Eclipse-BuddyPolicy =3D registered
>>>> Bundle-Name =3D Apache Jakarta log4j Plug-in
>>>> Bundle-Localization =3D plugin
>>>> Bundle-SymbolicName =3D 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 =3D m_factory.getModules();
>>>>       for (int modIdx =3D 0; (hostReq !=3D 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 =3D
>>>> modules[modIdx].getDefinition().getCapabilities();
>>>>               for (int capIdx =3D 0; (caps !=3D 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
>>>>
>>>>
>>>>
>>>
>>
>>
>


--=20
Cheers, Stuart

------=_Part_19136_16723987.1226950312113--