directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Endi Sukma Dewata" <end...@vergenet.com>
Subject RE: Restructuring Partition API
Date Wed, 04 May 2005 17:43:38 GMT
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


Mime
View raw message