You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Endi Sukma Dewata <en...@vergenet.com> on 2005/05/04 01:52:07 UTC
Restructuring Partition API
Hi,
I'm proposing some changes to the Partition API. The changes include:
* Moving partition-related classes to
org.apache.ldap.server.partition. This is to provide a cleaner Partition
API, separate from other classes.
* Renaming interface ContextPartition to Partition. This is just to
avoid confusion with the new class called PartitionContext. See next item.
* 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).
* 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.
* Creating a new class AbstractPartition that implements Partition.
This becomes the base class for all partitions.
* 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).
Note that these changes won't be backward compatible, so those who have
implemented custom partition would need to fix their code a little bit. But
things should become simpler now, you don't have to implement an interface
anymore, you can just extend from the base class.
Any suggestions? Comments? Please let me know if this is ok. I will submit a
patch that includes these changes and also the documentations (xdocs).
Thanks a lot.
--
Endi S. Dewata
Re: Restructuring Partition API
Posted by Alex Karasulu <ao...@bellsouth.net>.
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
Re: Restructuring Partition API
Posted by Alex Karasulu <ao...@bellsouth.net>.
Endi Sukma Dewata wrote:
>Oops.. I wasn't finished typing.
>
>
>
>>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.
>>
>>
>
>It should read:
>
>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 directory with its hierarchical structure, dn, normalized
>dn, alias, etc. It's not a general purpose database, not all custom
>partition will want to use it. In that case the custom partition can inherit
>directly from the AbstractPartition.
>
>
This makes much more sense. Again I'll look through all this stuff once
again. You make many good points.
Thanks,
Alex
RE: Restructuring Partition API
Posted by Endi Sukma Dewata <en...@vergenet.com>.
Oops.. I wasn't finished typing.
> 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.
It should read:
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 directory with its hierarchical structure, dn, normalized
dn, alias, etc. It's not a general purpose database, not all custom
partition will want to use it. In that case the custom partition can inherit
directly from the AbstractPartition.
--
Endi S. Dewata
RE: Restructuring Partition API
Posted by Endi Sukma Dewata <en...@vergenet.com>.
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
Re: Restructuring Partition API
Posted by Alex Karasulu <ao...@bellsouth.net>.
Endi Sukma Dewata wrote:
> Hi,
>
> I’m proposing some changes to the Partition API. The changes include:
>
Hi Endi.
> * Moving partition-related classes to
> org.apache.ldap.server.partition. This is to provide a cleaner
> Partition API, separate from other classes.
>
+1
> * Renaming interface ContextPartition to Partition. This is just
> to avoid confusion with the new class called PartitionContext.
> See next item.
>
> * 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?
> * 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?
> * 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?
> Note that these changes won’t be backward compatible, so those who
> have implemented custom partition would need to fix their code a
> little bit. But things should become simpler now, you don’t have to
> implement an interface anymore, you can just extend from the base class.
>
Any thoughts from others regarding these changes?
> Any suggestions? Comments? Please let me know if this is ok. I will
> submit a patch that includes these changes and also the documentations
> (xdocs). Thanks a lot.
>
Alex