Return-Path: X-Original-To: apmail-camel-users-archive@www.apache.org Delivered-To: apmail-camel-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 57826980D for ; Thu, 21 Jun 2012 04:29:23 +0000 (UTC) Received: (qmail 30378 invoked by uid 500); 21 Jun 2012 04:29:22 -0000 Delivered-To: apmail-camel-users-archive@camel.apache.org Received: (qmail 30293 invoked by uid 500); 21 Jun 2012 04:29:20 -0000 Mailing-List: contact users-help@camel.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@camel.apache.org Delivered-To: mailing list users@camel.apache.org Received: (qmail 30265 invoked by uid 99); 21 Jun 2012 04:29:19 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 21 Jun 2012 04:29:19 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of szh.subs@gmail.com designates 209.85.217.173 as permitted sender) Received: from [209.85.217.173] (HELO mail-lb0-f173.google.com) (209.85.217.173) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 21 Jun 2012 04:29:12 +0000 Received: by lbok6 with SMTP id k6so1971466lbo.32 for ; Wed, 20 Jun 2012 21:28:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:x-priority:message-id:to:cc:subject:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=nCRKEf4LH6rz7j0JDEjlqyhzat+oSTxpbw1glIkwYzE=; b=JcO76v1Rbe0/wQdGkvAw7oaGRfTmIg8Xx0UYhVZc6b1T0dJE/f2xL1nu6C0giVYPef QcVvUPqQ2DMb4nu1LFkSo9eza0O7pvlmYC08ftD+Ugrsom5zaYvU/1Rdgj2WKlwvhIa2 ncsPjpeNZ63xGl3MyaLUWWn0ps1XHwW4toGB0+PYMsTgWg9cuA64gW5/iuw6+ycNf2Tn TwxeiqOO0nVKZTujCJrjhJRTGt1Q7NOjJjBirhWJbIlpVQUR9SWUXt/GixP9ZOB8Nir1 8jOA2MhtYi2S+x0OLiRQ8bro31oV3Tb7TxkLzsdwLnB3dgTDbKVNFmMUWRnbxX6Bi+j5 bk8A== Received: by 10.152.148.161 with SMTP id tt1mr25071157lab.4.1340252931098; Wed, 20 Jun 2012 21:28:51 -0700 (PDT) Received: from [192.168.1.2] ([81.200.28.84]) by mx.google.com with ESMTPS id gd9sm17651745lbb.15.2012.06.20.21.28.48 (version=SSLv3 cipher=OTHER); Wed, 20 Jun 2012 21:28:49 -0700 (PDT) Date: Thu, 21 Jun 2012 08:28:03 +0400 From: Sergey Zhemzhitsky X-Priority: 3 (Normal) Message-ID: <987004637.20120621082803@gmail.com> To: Christian Schneider CC: users@camel.apache.org Subject: Re: Camel OSGi services component In-Reply-To: <4FE18B98.4090603@die-schneider.net> References: <54095825.20120522215706@gmail.com> <4FE18B98.4090603@die-schneider.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Hello Christian, Firstly I thought about some kind of indirect dependency on camel, but I suppose that such an indirection will complicate the component with copying of headers, bodies, properties, etc. from and to a camel exchange in case of duplication of camel exchange api (lightweight analogues of camel exchanges). The self contained interface will be provided as some kind of additional module of the component, so there will be a dependency on the component and in my opinion there is no a big difference between depending on the camel api or the camel component api. What do you think about something like a bean binding (http://camel.apache.org/bean-binding.html) from the consumer side? In that case almost any interface can be used as published OSGi service to process exchanges. Regards, Sergey > Hi Sergey, > the component looks pretty good already. There is one thing though I > would like to discuss. > More or less the core of this component is the OSGi service we use to > communicate between the bundles. You currently use the camel Processor > interface for this. > While this is quite suitable for pure camel to camel communication I > wonder if we could come up with an interface that is not tied to camel. > The Processor interfaces indirectly references a lot of the camel core > code. I wonder if we could design a simple self contained interface that > would also be reuseable for other projects to do a generic communication > with camel. > Christian > Am 22.05.2012 19:57, schrieb szh.subs@gmail.com: >> Hi gurus, >> >> Recently I've published camel component that uses OSGi services to >> communicate between endpoints in different bundles. >> >> Here is the link: https://github.com/szhem/camel-osgi >> I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292 >> >> So I'd like to have some feedback if it seems to be useful. >> >> Regards, >> Sergey >> >>