directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: Restructuring Partition API
Date Thu, 05 May 2005 14:09:05 GMT
Endi Sukma Dewata wrote:

>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.
>  
>
Ok that makes sense.

>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.
>  
>
You're right they can be exposed to the partition yes. Is a 
PartitionContext still worth having even if most of the info in there is 
applicable to every partition? Also if you are making this seem like 
servlets I've always wondered why there was overlap of ServletConfig w/ 
ServletContext. Looks to me like the ServletContext should be enough. 
Does this still apply to our situation with ParititionContext?

>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.
>  
>
Are we changing the Partition interface to add new things to a 
partition? I thought we added more to the constructors of implementations.

<snip/>

>>>    * 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)?
>  
>
Database interface is a misnomer. Should really have been named BTree 
database. I was thinking of doing something wiith JE at some point.

>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?
>  
>
Let me take a closer look at the code and review what your 
recommendations here. I'll get back to you.

Thanks,
Alex


Mime
View raw message