From dev-return-41007-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Wed May 16 03:58:45 2012 Return-Path: X-Original-To: apmail-directory-dev-archive@www.apache.org Delivered-To: apmail-directory-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 81D63C174 for ; Wed, 16 May 2012 03:58:45 +0000 (UTC) Received: (qmail 67150 invoked by uid 500); 16 May 2012 03:58:44 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 66807 invoked by uid 500); 16 May 2012 03:58:38 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 66761 invoked by uid 99); 16 May 2012 03:58:37 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 May 2012 03:58:37 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of gokturk.gezer@gmail.com designates 209.85.210.50 as permitted sender) Received: from [209.85.210.50] (HELO mail-pz0-f50.google.com) (209.85.210.50) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 May 2012 03:58:30 +0000 Received: by danh15 with SMTP id h15so490996dan.37 for ; Tue, 15 May 2012 20:58:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=BUCf4QWwr3ny0b3u9ho7+Bc5mx9y8D2xEKvNPLFttfk=; b=tbE0T8UJnaoPoWCAlsAcF6FccfhrUhf9I0OY6ytV3BrwTrSivL4Lkp/rQNTeAqDNnW J5Z3AUIf98x7/pUOx4qECLKOvHwCQhk4CYguzos0l/I1uVqUBYhtWlXuPC2kha//bgHi Ar4gRV2ClIi1tFwBYayUdd/EgrbOSRvv5bolOJlG74UnJHcUfFRxERplVVgfWuHRl2GY ud9RcSfJPeMCLJnMb9CVUy990ofCJIW/SZ6+oiUi1no3gkexUxG33OadmWPlhwF5sCVP rOdIGRSg3GDUA4eaiMrFKVkYv+2Aws9xZMgugDNPh5IQP4su09thnc3PZXHcUrhKUmq1 kNRg== MIME-Version: 1.0 Received: by 10.68.223.138 with SMTP id qu10mr12187796pbc.124.1337140690669; Tue, 15 May 2012 20:58:10 -0700 (PDT) Received: by 10.68.64.74 with HTTP; Tue, 15 May 2012 20:58:10 -0700 (PDT) Date: Wed, 16 May 2012 06:58:10 +0300 Message-ID: Subject: Problem of JDBM being hard(impossible) to reconfigure once it is initialized From: =?UTF-8?B?R8O2a3TDvHJrIEdlemVy?= To: Apache Directory Developers List Content-Type: multipart/alternative; boundary=047d7b2ee645e1d0a304c01f531b X-Virus-Checked: Checked by ClamAV on apache.org --047d7b2ee645e1d0a304c01f531b Content-Type: text/plain; charset=UTF-8 Hi Everyone, As i told you in OSGI branch update, JDBM is so immutable in runtime. Almost every setter calls checkInitialized() method first which throws an exception when its already initialized. We have to change that behavior in as much aspects of it as we can. Otherwise there is no point in going into OSGI. However i can't always be sure what my changes might lead on runtime. I need some serious help here, especially from those are actively working on JDBM, otherwise i'll jump into trial and error cycle which will probably last long. Here is the current configuration points for JdbmPartition: - cacheSize(int) - optimizerEnabled(boolean) - partitionPath(File) - suffixDn(Dn) - syncOnWrite(boolean) - indexedAttributes(List) Currently none of them is reconfigurable, once the partition is initialized. However i need to know which are actually reconfigurable among these ones. And which are not really reconfigurable and why? Every reconfiguration will invoke some setter method at desired configuration point. So i guess we can make this reconfigurations work actually based on it's initialized or not, rather than throwing an exception blindly. For your information, as we have the lifecycle control capability of components created from within ApacheDS, we can implement some fancy stuff. Like re-instantiating a component when one of its immutable property is changed, or stop it and remove from DirectoryService when one of its immutable property is changed to prevent accepting operations while reconfiguring. These migtht be implemented in case there is " no possibility! " to handle reconfigurations in live and initialized JdbmPartition reference. I appreciate every single idea on this matter ! Thanks, Gokturk --047d7b2ee645e1d0a304c01f531b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Everyone,

As i told you in OSGI branch update, JDBM i= s so immutable in runtime. Almost every setter calls checkInitialized() met= hod first which throws an exception when its already initialized.

We have to change that behavior in as much aspects of it as = we can. Otherwise there is no point in going into OSGI. However i can't= always be sure what my changes might lead on runtime. I need some serious = help here, especially from those are actively working on JDBM, otherwise i&= #39;ll jump into trial and error cycle which will probably last long.

Here is the current configuration points for JdbmPartit= ion:
  • cacheSize(int)
  • optimizerEnabled(boolean)
  • partitionPath(File)
  • suffixDn(Dn)
  • syncOnWrite(boolean)<= /li>
  • indexedAttributes(List<Index>)
Currently none of th= em is reconfigurable, once the partition is initialized. However i need to = know which are actually reconfigurable among these ones. And which are not = really reconfigurable and why?

Every reconfiguration will invoke some setter met= hod at desired configuration point. So i guess we can make this reconfigura= tions work actually based on it's initialized or not, rather than throw= ing an exception blindly.

For your information, as we have the lifecycle control = capability of components created from within ApacheDS, we can implement som= e fancy stuff. Like re-instantiating a component when one of its immutable = property is changed, or stop it and remove from DirectoryService when one o= f its immutable property is changed to prevent accepting operations while r= econfiguring. These migtht be implemented in case there is " no possib= ility! " to handle reconfigurations in live and initialized JdbmPartit= ion reference.

I appreciate every single idea on this matter !

Thanks,
Gokturk
--047d7b2ee645e1d0a304c01f531b--