Return-Path: Delivered-To: apmail-cxf-users-archive@www.apache.org Received: (qmail 83263 invoked from network); 26 Mar 2010 11:38:38 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 26 Mar 2010 11:38:38 -0000 Received: (qmail 97384 invoked by uid 500); 26 Mar 2010 11:38:38 -0000 Delivered-To: apmail-cxf-users-archive@cxf.apache.org Received: (qmail 97328 invoked by uid 500); 26 Mar 2010 11:38:38 -0000 Mailing-List: contact users-help@cxf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@cxf.apache.org Delivered-To: mailing list users@cxf.apache.org Received: (qmail 97320 invoked by uid 99); 26 Mar 2010 11:38:38 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 26 Mar 2010 11:38:38 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FREEMAIL_FROM,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of david.bosschaert@gmail.com designates 74.125.82.41 as permitted sender) Received: from [74.125.82.41] (HELO mail-ww0-f41.google.com) (74.125.82.41) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 26 Mar 2010 11:38:31 +0000 Received: by wwb39 with SMTP id 39so326858wwb.0 for ; Fri, 26 Mar 2010 04:38:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:received:message-id:subject:to:content-type :content-transfer-encoding; bh=G15LH51/93hbhO5jtM0zmzs/uH40EsIiQyMMHJVU96w=; b=pnlZSsG8fUDKKZhifcXx6rVXfV0AmsfsTTG0HGmsnWoqrtvbvYaWGhrcnhHEeb1A6j CwBgeJDs5SWqDXG/jfNmQwoLVpl6OsOlVp8PeFqUP34PdFrZar+33QGnB4CHl/eHHEAh 6kgEhrQWakiHX7YGvLE7NzvR4N3WfR71bftJ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=VvGyBKSMlQwyLPURyKYvuQ2JJoGANsX9beCOmSmqnUj+i5OV9kEUcpPMYdY5WRCmQD fJETbpgvuagt62fdrpphSr2VK8h22fccM4OQbvub1ccNpVvwnufp2Ak8EwIzm26m6MIq dyhiGfYXZbru9qLAomZnJn9Q44ZUovdbbyIXw= MIME-Version: 1.0 Received: by 10.216.66.144 with HTTP; Fri, 26 Mar 2010 04:37:51 -0700 (PDT) In-Reply-To: References: From: David Bosschaert Date: Fri, 26 Mar 2010 11:37:51 +0000 Received: by 10.216.86.132 with SMTP id w4mr411857wee.87.1269603491127; Fri, 26 Mar 2010 04:38:11 -0700 (PDT) Message-ID: Subject: Re: Questions About the DOSGi Greeter Demo To: users@cxf.apache.org Content-Type: text/plain; charset=Big5 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org Just wanted to add a little bit of background on the semantics around addingService() In OSGi, every callback to addingService() represents a separate service in the OSGi Framework (either a local or a distributed service) and every removedService() call represents a service that has been removed. The bug you were seeing was caused by a bug in the cleanup of statically registered services, where the service should have been removed when a bundle containing the remote-services.xml file was stopped. This removal didn't happen but when that bundle was started again the service did get registered again hence the multiples... Hope that 1.2-SNAPSHOT version fixes it for you too. David 2010/3/25 David Bosschaert : > Hi Nick, > > I have been able to reproduce your problem with CXF-DOSGi 1.1. > The good news is that it seems to be fixed on trunk. Try installing > the single bundle distro from [1] and see if that helps. > > Hope this helps, > > David > > [1] https://repository.apache.org/content/groups/snapshots/org/apache/cxf= /dosgi/cxf-dosgi-ri-singlebundle-distribution/1.2-SNAPSHOT/cxf-dosgi-ri-sin= glebundle-distribution-1.2-SNAPSHOT.jar > > 2010/3/24 Pan Nick : >> >> Hi, >> I am new to DOSGi, and I have some question about the starter demo proje= ct hosted at http://cxf.apache.org/distributed-osgi-greeter-demo-walkthroug= h.html >> My client and server are running Felix 2.0.1. >> Interaction between them seems to be working fine (invoking services be= tween OSGi containers); however, I noticed that the addingService (functio= n calls of the ServiceTracker on client side) are executed multiple times w= hich leads to duplicates of the same OSGi service being added to the client= . More precisely, a service tracker is created within a client OSGi bundl= e to track an OSGi service offered by the server; however, the addingServic= e function of the tracker is run multiple times when the client bundle is a= ctivated. >> This can be prevented by adding a unique-check at the addingService(), b= ut I am wondering is the above scenario working as intended? If not, is any= one getting this as well? >> Thanks,Nick >> >> _________________________________________________________________ >> =B0=A3=A4F=B9q=A4l=ABH=BDc=A1A=A7=F3=A6=B3=B3\=A6h=A6=B3=A5=CE=AA=BA=A5\= =AF=E0=A1C=A7=D6=A8=D3=A8=CF=A5=CE=A7K=B6O=AA=BA Windows Live Hotmail=A1C >> https://signup.live.com/signup.aspx?id=3D60969 >