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 69.89.18.111 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=WWKsJWhMCogIpSa8qwq0aIIUXy2xNAxwsmC91tEkxXmDIAa5gsG0WLI0XsrRmGEraO2VXTS7JBqBEg0vAYHoIyl4W4j4aFCqKczvLbg1WvjzapZ5ctsnrPP6LPu5cQNy;
Message-ID: <4921C654.1060508@ungoverned.org>
Date: Mon, 17 Nov 2008 14:30:28 -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>
 <4921C43B.3020408@ungoverned.org>
In-Reply-To: <4921C43B.3020408@ungoverned.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


Richard S. Hall wrote:
>
>
> 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.

That should have said, "To be clear..."

-> richard

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