From dev-return-5740-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Wed May 04 17:43:47 2005 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 98897 invoked from network); 4 May 2005 17:43:46 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 4 May 2005 17:43:46 -0000 Received: (qmail 3209 invoked by uid 500); 4 May 2005 17:45:48 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 3149 invoked by uid 500); 4 May 2005 17:45:48 -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 3133 invoked by uid 99); 4 May 2005 17:45:47 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from mail.vergenet.com (HELO mail.vergenet.com) (216.140.187.25) by apache.org (qpsmtpd/0.28) with ESMTP; Wed, 04 May 2005 10:45:47 -0700 Received: from endi (unknown [192.168.0.51]) by mail.vergenet.com (Postfix) with ESMTP id 3A2A813FA6 for ; Wed, 4 May 2005 12:23:52 -0500 (CDT) From: "Endi Sukma Dewata" To: "'Apache Directory Developers List'" Subject: RE: Restructuring Partition API Date: Wed, 4 May 2005 12:43:38 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <42783CF5.4030301@bellsouth.net> Thread-Index: AcVQU/mZF4Vp1bLUTCecsEKOPHpDwAAbtv2Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 Message-Id: <20050504172352.3A2A813FA6@mail.vergenet.com> X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Alex Karasulu wrote: > > * Creating new interfaces PartitionConfig and PartitionContext. > > This is similar to ServletConfig and ServletContext. The > > PartitionConfig holds the configuration information for each > > partition. The PartitionContext provides information about the > > context in which the partition is running (i.e. the server). > > > Why may I ask is the PartitionContext needed? What kind of info besides > the dn of the context for the partition is needed? Actually the dn of the context will be provided by PartitionConfig, along with the Partition's initialization parameters (if any). You can supply the initialization parameters in a .properties file. With the PartitionContext you can get the server's work directory, bootstrap registries, and global registries. These info are actually needed to initialize ApplicationPartition and SystemPartition. Please let me know if we're not supposed to expose them to the partition. If in the future we want to supply more info about the server to the partition, we can just add more methods in the PartitionContext, we don't have to modify the Partition interface. > > * Creating new class GenericPartitionConfig and > > GenericPartitionContext. These classes provide the default > > implementation of PartitionConfig and PartitionContext. These > > classes are only used internally, they won't be exposed in the > API. > > > Ok yah makes sense once its clear for why we want a PartitionContext. > > > * Creating a new class AbstractPartition that implements > > Partition. This becomes the base class for all partitions. > > > Hmm what goes into AbstractPartition - what can we stuff in there now > that you move JDBM stuff down an extra notch in inheritance hierarchy? The AbstractPartition will only provide an empty or trivial implementation of the Partition interface. It's being provided more for convenience, the subclass only needs to implement the methods it wants to use. The AbstractDbPartition will become the base class for partitions that store the data in a Database (e.g. JDBM). I found that the Database interface is tightly related to Any custom partition that doesn't want to use JDBM can't use this class, it needs to use the AbstractPartition. > > * Renaming AbstractContextPartition to AbstractDbPartition and > > make it extends the AbstractPartition. This becomes the base > > class for all partitions using the JDBM database (e.g. > > ApplicationPartition and SystemPartition). > > > How about calling it AbstractJdbmPartition? Hmm... would there be any other Database implementation (other than JDBM)? While making these changes, I was able to move the JdbmDatabase instantiation inside the SystemPartition and ApplicationPartition. So, basically any subclass of AbstractDbPartition would have a control of what type of Database it wants to use. It might be better to keep the super class's name generic. Is AbstractDatabasePartition better? Thanks. -- Endi S. Dewata