Return-Path: Delivered-To: apmail-felix-dev-archive@www.apache.org Received: (qmail 46820 invoked from network); 8 Apr 2010 13:17:36 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 8 Apr 2010 13:17:36 -0000 Received: (qmail 98361 invoked by uid 500); 8 Apr 2010 13:17:36 -0000 Delivered-To: apmail-felix-dev-archive@felix.apache.org Received: (qmail 98314 invoked by uid 500); 8 Apr 2010 13:17:35 -0000 Mailing-List: contact dev-help@felix.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@felix.apache.org Delivered-To: mailing list dev@felix.apache.org Received: (qmail 98300 invoked by uid 99); 8 Apr 2010 13:17:35 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Apr 2010 13:17:35 +0000 X-ASF-Spam-Status: No, hits=-0.5 required=10.0 tests=AWL,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of heavy@ungoverned.org designates 67.222.54.6 as permitted sender) Received: from [67.222.54.6] (HELO outbound-mail-313.bluehost.com) (67.222.54.6) by apache.org (qpsmtpd/0.29) with SMTP; Thu, 08 Apr 2010 13:17:27 +0000 Received: (qmail 520 invoked by uid 0); 8 Apr 2010 13:17:06 -0000 Received: from unknown (HELO host118.hostmonster.com) (74.220.207.118) by cpoproxy3.bluehost.com with SMTP; 8 Apr 2010 13:17:06 -0000 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=FDBzZAdR3X1oBwnjS1+n5PKx/qXzDtQe0LN0z2Y9qBvQp20C8GEvi1E+GP37T0apqISUnsrXTg2vP0/JXXmX5bK4Jre8f5Sf8+10Dl2hObOXNAalYyl7ncmMldeQHsnT; Received: from adsl-99-62-222-230.dsl.sgnwmi.sbcglobal.net ([99.62.222.230] helo=heavyweight.glastender.com) by host118.hostmonster.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1NzrbW-0000lV-FG for dev@felix.apache.org; Thu, 08 Apr 2010 07:17:06 -0600 Message-ID: <4BBDD751.7020602@ungoverned.org> Date: Thu, 08 Apr 2010 09:17:05 -0400 From: "Richard S. Hall" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: dev@felix.apache.org Subject: Re: Fragment-Host's bundle-version not being honored in 2.0.4 References: <28170716.post@talk.nabble.com> In-Reply-To: <28170716.post@talk.nabble.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {1027:host118.hostmonster.com:ungovern:ungoverned.org} {sentby:smtp auth 99.62.222.230 authed with heavy@ungoverned.org} On 4/7/10 16:41, jspeton wrote: > According to this bug https://cwiki.apache.org/jira/browse/FELIX-1795 > bundle-version support in Fragment-Host header should work as of 2.0.2, yet > it is not being honored for me. > > Here is my situation: > 1. Two bundle hosts, with the same symbolic name, but with different > versions 1.6.1 and 1.6.2. > 2. Two bundle fragments, with the same symbolic name, and with the same > symbolic name fragment host from (1). The bundle-version of the two > fragments is 1.6.1 and 1.6.2 (they are kept in sync to avoid confusion). > > In other words, I am expecting that version 1.6.1 of the host will resolve > the 1.6.1 fragment, and the 1.6.2 host will resolve the 1.6.2 fragment. > > What I am finding is that the 1.6.2 fragment is resolving to both the 1.6.1 > and 1.6.2 hosts. I know the 1.6.1 class loader is correct, as is the 1.6.2, > but using getResourceAsStream from either host always gets me the 1.6.2 > version. Both bundle-version parameters are expressed as single versions, > e.g. bundle-version="1.6.2", although I have tried "[1.6.2,1.6.2]" as well > to no avail. > > Am I doing something wrong or is this feature still bugged? Why is the > 1.6.2 fragment in the classpath of the 1.6.1 classloader? > What is the version range in your Fragment-Host header? If your fragments match both hosts, then the resolver will try to attach the highest version fragment to each host. This is correct. If you only want your fragments to attach to a specific host version, then your Fragment-Host header should only match that version. -> richard > Many thanks! > Jean-Guy Speton > >