Return-Path: Delivered-To: apmail-cxf-dev-archive@www.apache.org Received: (qmail 6280 invoked from network); 10 Apr 2009 12:29:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 10 Apr 2009 12:29:23 -0000 Received: (qmail 73587 invoked by uid 500); 10 Apr 2009 12:29:22 -0000 Delivered-To: apmail-cxf-dev-archive@cxf.apache.org Received: (qmail 73508 invoked by uid 500); 10 Apr 2009 12:29:22 -0000 Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cxf.apache.org Delivered-To: mailing list dev@cxf.apache.org Received: (qmail 73497 invoked by uid 99); 10 Apr 2009 12:29:22 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 Apr 2009 12:29:22 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [192.77.186.17] (HELO mx3.progress.com) (192.77.186.17) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 Apr 2009 12:29:14 +0000 Received: from mx3.progress.com (127.0.0.1) by mx3.progress.com (MlfMTA v3.2r9) id hrstpk0171st for ; Fri, 10 Apr 2009 08:28:24 -0400 (envelope-from ) Received: from progress.com ([192.233.92.16]) by mx3.progress.com (SonicWALL 6.2.2.1073) with ESMTP; Fri, 10 Apr 2009 08:23:48 -0400 Received: from NTEXFE01.bedford.progress.com (ntexfe01 [10.128.10.24]) by progress.com (8.13.8/8.13.8) with ESMTP id n3ACNm3J015126 for ; Fri, 10 Apr 2009 08:23:48 -0400 (EDT) Received: from sberyoz ([10.5.2.12]) by NTEXFE01.bedford.progress.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Apr 2009 08:23:48 -0400 Message-ID: <00d601c9b9d7$32fc1be0$0c02050a@emea.progress.com> From: "Sergey Beryozkin" To: References: Subject: Re: Distributed OSGi Discovery implementation in CXF Date: Fri, 10 Apr 2009 13:23:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-OriginalArrivalTime: 10 Apr 2009 12:23:48.0451 (UTC) FILETIME=[332DB330:01C9B9D7] X-Mlf-Version: 6.2.2.1073 X-Mlf-UniqueId: o200904101223480251605 X-Virus-Checked: Checked by ClamAV on apache.org Hi, > Hi all, > > Over the past while I have done some experimentation around a possible > implementation of the Distributed OSGi RFC 119 Discovery service. > > The current CXF-DOSGi codebase only contains the Distribution Software > (DSW) component, which means that you need to configure the location > of your remote services manually. Adding a Discovery service (as > specified in RFC 119) would enable dynamic discovery of remote > services as well. > > I've started using Apache Zookeeper as the underlying technology to > implement a Discovery service and at this stage I have it working, > although what I have is not completely finished. > > I think this could be a useful addition to the CXF DOSGi codebase, as > together with the DSW code that's already there it would provide the > implementation of the two core parts of RFC 119. > If folks agree that this is useful to have, I can start contributing > this to the http://svn.apache.org/repos/asf/cxf/dosgi/trunk/discovery > and continue working on it from that location. +1. It would make the CXf DOSGi implementation much more self-contained and ready to be used out of the box in distributed environments.... Would it still make sense to keep the Local Discovery service implementation ? For ex to test against multiple Discovery instances ? cheers, Sergey > > Thoughts anyone? > > Cheers, > > David