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 heavy@ungoverned.org
 designates 67.222.39.29 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=ungoverned.org;
	h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User;
	b=FuHLZZm8BaibCAkhzmbemsBUgdJJ4o4i5fWUALqezVxOMDb0KFiMAe5lBYAHhOu2e95vlhuSaBCXCl5XuSbjmWJ/i2ujBhlsIBgGnF7zFN2MPbA+wZKCV6lOL7YVapri;
Message-ID: <4921C43B.3020408@ungoverned.org>
Date: Mon, 17 Nov 2008 14:21:31 -0500
From: "Richard S. Hall" <heavy@ungoverned.org>
User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914)
MIME-Version: 1.0
To: dev@felix.apache.org
Subject: Re: Fragment-Host resolution fails (bug?)
References: <120de6e60811170703o7a63b9b2kf3271d1436da4718@mail.gmail.com>
	 <4921B79B.3010003@ungoverned.org>
 <120de6e60811171117v58ca9220ia7070785bab3166b@mail.gmail.com>
In-Reply-To: <120de6e60811171117v58ca9220ia7070785bab3166b@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


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

So be clear, the spec is purposely vague here. So, it doesn't forbid or 
mandate dynamic attachment.

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