Return-Path: X-Original-To: apmail-hadoop-hdfs-dev-archive@minotaur.apache.org Delivered-To: apmail-hadoop-hdfs-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id DF1BAD4DA for ; Mon, 9 Jul 2012 18:45:28 +0000 (UTC) Received: (qmail 37578 invoked by uid 500); 9 Jul 2012 18:45:28 -0000 Delivered-To: apmail-hadoop-hdfs-dev-archive@hadoop.apache.org Received: (qmail 37528 invoked by uid 500); 9 Jul 2012 18:45:28 -0000 Mailing-List: contact hdfs-dev-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: hdfs-dev@hadoop.apache.org Delivered-To: mailing list hdfs-dev@hadoop.apache.org Received: (qmail 37520 invoked by uid 99); 9 Jul 2012 18:45:28 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Jul 2012 18:45:28 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [217.70.183.196] (HELO relay4-d.mail.gandi.net) (217.70.183.196) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Jul 2012 18:45:21 +0000 X-Originating-IP: 217.70.178.131 Received: from mfilter11-d.gandi.net (mfilter11-d.gandi.net [217.70.178.131]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 13C0F172098 for ; Mon, 9 Jul 2012 20:45:00 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter11-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter11-d.gandi.net (mfilter11-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id OoqCKOkRy-wz for ; Mon, 9 Jul 2012 20:44:58 +0200 (CEST) X-Originating-IP: 78.244.148.153 Received: from [192.168.134.5] (ser34-1-78-244-148-153.fbx.proxad.net [78.244.148.153]) (Authenticated sender: jb@nanthrax.net) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 8007417208F for ; Mon, 9 Jul 2012 20:44:58 +0200 (CEST) Message-ID: <4FFB26A5.9060802@nanthrax.net> Date: Mon, 09 Jul 2012 20:44:53 +0200 From: =?UTF-8?B?SmVhbi1CYXB0aXN0ZSBPbm9mcsOp?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: hdfs-dev@hadoop.apache.org Subject: Re: OSGi and classloaders References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org Thanks for the update guys. We are going to look for a way to handle configurations in an OSGi way=20 without changing the API/dependency. Regards JB On 07/09/2012 08:30 PM, Owen O'Malley wrote: > Changing the configurations is a big and very touchy job. It is touchy = in > that it is very exposed to the users and many many applications assume = the > configuration is dealt with in particular ways. It is a requirement to > maintain compatibility and thus that needs to be factored in to the wor= k. > Furthermore, you not only have the local configuration, but the way tha= t > configuration is done between the clients, servers, and mapreduce tasks= . > Even little changes in the past (eg. making a copy of a configuration a= t > one spot) have broken both users and frameworks built on top (eg. Pig, > Hive, Oozie). > > As Bobby said, Configuration is absolutely not a singleton. Many of the > servers (JobTracker, Oozie, etc.) use configurations to keep track of t= he > different contexts for each user. You could go to a dependency injectio= n > approach based on Guice to make it pluggable and yet context sensitive. > > -- Owen > --=20 Jean-Baptiste Onofr=C3=A9 jbonofre@apache.org http://blog.nanthrax.net Talend - http://www.talend.com