You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Trustin Lee <tr...@gmail.com> on 2005/06/22 16:41:51 UTC
[apacheds] A final summary for the changes in 'db_refactor' branch before merging it back.
[apacheds] A final summary for the changes in 'db_refactor' branch before
merging it back.
Hi folks,
Here's a summary of the changes in 'db_refactor' branch. Please follow this
message browsing your working in your IDE. That will help you much more to
understand this.
The changes in context partitions
=================================
* Moved all classes related with context partitions to
org.apache.ldap.server.partition.
* BackingStore is removed and merged into ContextPartition. I found no
reason to keep BackingStore. Merging it into ContextPartition also was OK.
* PartitionNexus is renamed to ContextPartitionNexus, and became an abstract
class to provide some static methods moved from SystemPartition.
* RootNexus is renamed to DefaultContextPartitionNexus
* ContextPartitions now have better two lifecycle methods: init(
ContextFactoryConfiguration, ContextPartitionConfiguration ) and destroy().
* ContextFactoryConfiguration doesn't set up or tear down partitions now.
DefaultContextPartitionNexus.init() and destroy() does.
ContextFactoryConfiguration now simply calls
DefaultContextPartitionNexus.init() to start up all application partitions.
* SystemPartition is removed thanks to introduction of JdbmContextPartition.
Because SystemPartition doesn't need to instantiate JdbmDatabase anymore, it
became to have only static methods and constants. I moved those static
members to ContextPartitionNexus which is now an abstract class.
The changes in 'db' package
===========================
* Database interface is removed.
* BTree-specific classes are moved to
org.apache.ldap.server.partition.impl.btree.
* org.apache.server.db.gui is renamed to
org.apache.ldap.server.partition.impl.btree.gui.
* JDBM implementation package is renamed to
org.apache.ldap.server.partition.impl.btree.jdbm
* JdbmDatabase is renamed to JdbmContextPartition, which is a
ContextPartition, not Database anymore.
* JdbmDatabase extends BTreeContextPartition which implements
ContextPartition and merges AbstractDatabase.
* Some classes independent from BTree implementations
(ResultFilteringEnumeration, SearchResultFilter, SearchResultEnumeration)
are moved to org.apache.ldap.server.enumeration.
The changes in 'interceptor' package
====================================
* Interceptor.init() and destroy() method is more useful now.
* InterceptorContext is deprecated by ContextFactoryConfiguration and
InterceptorConfiguration, and removed.
* Invocation object is not used anymore; Interceptor provides all
interception methods that matches to ContextPartitionNexus method by method.
BaseInterceptor also has changed to follow this change.
The changes in 'invocation' package
===================================
* Because Interceptor doesn't use Invocation class anymore, its duty has
changed to representation of 'the invocation from JNDI context to
ContextPartition'. Invocation is pushed to InvocationStack when an
invocation from JNDI context (ServerDirContext) occurs, and popped from
InvocationStack when the invocation ends.
* Added InvocationStack to represent recursive calls to
ContextPartitionNexus. Actually it has been done by an AspectJ class in
ApacheDS in conjunction with Invocation. Now, Invocation doesn't manage
context stacks anymore. Instead, target JNDI context property is added to
Invocation to represent which JNDI context the invocation came from, and
Invocation (instead of Context) is pushed to and popped from
InvocationStack. InvocationStack is managed by its internal instance map
whose key is 'current thread'. I didn't use ThreadLocals to manage resources
more explicitly, so the content of InvocationStack is explicitly pushed and
popped by ContextPartitionNexusProxy.
* The change above helped me to removed dependency to AspectJ, and it means
that ApacheDS now compiles OK in Java 5.
The changes in 'authn' package
==============================
* Authenticator.init() and destroy() method is more useful now.
* AuthenticatorContext is deprecated by ContextFactoryConfiguration and
AuthenticatorConfiguration, and removed.
What didn't change
==================
* All tests still pass.
* Most part of ContextPartition is retained.
* You can configure ApacheDS as before.
TODO
====
* Rewrite JavaDocs
* Improve more by others' feedback.
* Transaction API (perhaps we have to merge now and branch again for it)
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: [apacheds] A final summary for the changes in 'db_refactor' branch before merging it back.
Posted by Trustin Lee <tr...@gmail.com>.
Thanks for reviewing, Alex. I've just merged it into trunk.
Revision number before merging is: 201549
Trustin
2005/6/24, Alex Karasulu <ao...@bellsouth.net>:
>
> As usual Trustin it looks great. Let's merge it.
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: [apacheds] A final summary for the changes in 'db_refactor' branch
before merging it back.
Posted by Alex Karasulu <ao...@bellsouth.net>.
Trustin Lee wrote:
> [apacheds] A final summary for the changes in 'db_refactor' branch
> before merging it back.
>
As usual Trustin it looks great. Let's merge it.
Thanks,
Alex
Re: [apacheds] A final summary for the changes in 'db_refactor' branch
before merging it back.
Posted by Alex Karasulu <ao...@bellsouth.net>.
Soren Hilmer wrote:
>On Thursday 23 June 2005 18:09, Alex Karasulu wrote:
>
>
>>Soren Hilmer wrote:
>>
>>
>>>Hi,
>>>
>>>Do you have a timeframe for the "merging-back" activity?
>>>I am asking because I am going to make a "SleepyCat Berkeley DB Java
>>>Edition" backend implementation, and would like to do that against this
>>>new implementation, so I will not have to do it twice.
>>>
>>>Have you considered using this (BD JE) backend instead of JDBM? As far as
>>>I can understand it, the licensing seams okay, and it is a bit more
>>>mature (has transactions for one).
>>>
>>>
>>Yes a few times. JE actually appear after we had implemented a
>>partition using JDBM. I think the biggest impediment to JE may be due
>>to licensing. It is not ASL 2.0 compatible.
>>
>>
>
>I am not sure the license is incompatible with ASL-2.0. I read it to be very
>similar to the BouncyCastle license, and at least Apache-James includes
>BouncyCastle. But I'm not a lawyer so...
>
>Anyway for what it is worth, I'm going to make the JE backend, and will submit
>the work. You can then use it, if you like.
>
>
That would be great. I hope it is the case. We would welcome the
addition of a JE based partition to Directory.
Thanks Soren,
Alex
Re: [apacheds] A final summary for the changes in 'db_refactor' branch before merging it back.
Posted by Soren Hilmer <so...@tietoenator.com>.
On Thursday 23 June 2005 18:09, Alex Karasulu wrote:
> Soren Hilmer wrote:
> >Hi,
> >
> >Do you have a timeframe for the "merging-back" activity?
> >I am asking because I am going to make a "SleepyCat Berkeley DB Java
> > Edition" backend implementation, and would like to do that against this
> > new implementation, so I will not have to do it twice.
> >
> >Have you considered using this (BD JE) backend instead of JDBM? As far as
> > I can understand it, the licensing seams okay, and it is a bit more
> > mature (has transactions for one).
>
> Yes a few times. JE actually appear after we had implemented a
> partition using JDBM. I think the biggest impediment to JE may be due
> to licensing. It is not ASL 2.0 compatible.
I am not sure the license is incompatible with ASL-2.0. I read it to be very
similar to the BouncyCastle license, and at least Apache-James includes
BouncyCastle. But I'm not a lawyer so...
Anyway for what it is worth, I'm going to make the JE backend, and will submit
the work. You can then use it, if you like.
--Søren
>
> Alex
--
Søren Hilmer, M.Sc.
R&D manager Phone: +45 72 30 64 00
TietoEnator IT+ A/S Fax: +45 72 30 64 02
Ved Lunden 12 Direct: +45 72 30 64 57
DK-8230 Åbyhøj Email: soren.hilmer <at> tietoenator.com
Re: [apacheds] A final summary for the changes in 'db_refactor' branch
before merging it back.
Posted by Alex Karasulu <ao...@bellsouth.net>.
Soren Hilmer wrote:
>Hi,
>
>Do you have a timeframe for the "merging-back" activity?
>I am asking because I am going to make a "SleepyCat Berkeley DB Java Edition"
>backend implementation, and would like to do that against this new
>implementation, so I will not have to do it twice.
>
>Have you considered using this (BD JE) backend instead of JDBM? As far as I
>can understand it, the licensing seams okay, and it is a bit more mature (has
>transactions for one).
>
>
Yes a few times. JE actually appear after we had implemented a
partition using JDBM. I think the biggest impediment to JE may be due
to licensing. It is not ASL 2.0 compatible.
Alex
Re: [apacheds] A final summary for the changes in 'db_refactor' branch before merging it back.
Posted by Trustin Lee <tr...@gmail.com>.
Hi Soren,
2005/6/23, Soren Hilmer <so...@tietoenator.com>:
>
> Do you have a timeframe for the "merging-back" activity?
> I am asking because I am going to make a "SleepyCat Berkeley DB Java
> Edition"
> backend implementation, and would like to do that against this new
> implementation, so I will not have to do it twice.
I hope it is merged back before this week ends.
Have you considered using this (BD JE) backend instead of JDBM? As far as I
> can understand it, the licensing seams okay, and it is a bit more mature
> (has
> transactions for one).
Yes we did. We didn't have much time to make one yet. :)
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: [apacheds] A final summary for the changes in 'db_refactor' branch before merging it back.
Posted by Soren Hilmer <so...@tietoenator.com>.
Hi,
Do you have a timeframe for the "merging-back" activity?
I am asking because I am going to make a "SleepyCat Berkeley DB Java Edition"
backend implementation, and would like to do that against this new
implementation, so I will not have to do it twice.
Have you considered using this (BD JE) backend instead of JDBM? As far as I
can understand it, the licensing seams okay, and it is a bit more mature (has
transactions for one).
--Søren
On Wednesday 22 June 2005 16:41, Trustin Lee wrote:
> [apacheds] A final summary for the changes in 'db_refactor' branch before
> merging it back.
>
> Hi folks,
>
> Here's a summary of the changes in 'db_refactor' branch. Please follow this
> message browsing your working in your IDE. That will help you much more to
> understand this.
>
> The changes in context partitions
> =================================
> * Moved all classes related with context partitions to
> org.apache.ldap.server.partition.
> * BackingStore is removed and merged into ContextPartition. I found no
> reason to keep BackingStore. Merging it into ContextPartition also was OK.
> * PartitionNexus is renamed to ContextPartitionNexus, and became an
> abstract class to provide some static methods moved from SystemPartition.
> * RootNexus is renamed to DefaultContextPartitionNexus
> * ContextPartitions now have better two lifecycle methods: init(
> ContextFactoryConfiguration, ContextPartitionConfiguration ) and destroy().
> * ContextFactoryConfiguration doesn't set up or tear down partitions now.
> DefaultContextPartitionNexus.init() and destroy() does.
> ContextFactoryConfiguration now simply calls
> DefaultContextPartitionNexus.init() to start up all application partitions.
> * SystemPartition is removed thanks to introduction of
> JdbmContextPartition. Because SystemPartition doesn't need to instantiate
> JdbmDatabase anymore, it became to have only static methods and constants.
> I moved those static members to ContextPartitionNexus which is now an
> abstract class.
>
> The changes in 'db' package
> ===========================
> * Database interface is removed.
> * BTree-specific classes are moved to
> org.apache.ldap.server.partition.impl.btree.
> * org.apache.server.db.gui is renamed to
> org.apache.ldap.server.partition.impl.btree.gui.
> * JDBM implementation package is renamed to
> org.apache.ldap.server.partition.impl.btree.jdbm
> * JdbmDatabase is renamed to JdbmContextPartition, which is a
> ContextPartition, not Database anymore.
> * JdbmDatabase extends BTreeContextPartition which implements
> ContextPartition and merges AbstractDatabase.
> * Some classes independent from BTree implementations
> (ResultFilteringEnumeration, SearchResultFilter, SearchResultEnumeration)
> are moved to org.apache.ldap.server.enumeration.
>
> The changes in 'interceptor' package
> ====================================
> * Interceptor.init() and destroy() method is more useful now.
> * InterceptorContext is deprecated by ContextFactoryConfiguration and
> InterceptorConfiguration, and removed.
> * Invocation object is not used anymore; Interceptor provides all
> interception methods that matches to ContextPartitionNexus method by
> method. BaseInterceptor also has changed to follow this change.
>
> The changes in 'invocation' package
> ===================================
> * Because Interceptor doesn't use Invocation class anymore, its duty has
> changed to representation of 'the invocation from JNDI context to
> ContextPartition'. Invocation is pushed to InvocationStack when an
> invocation from JNDI context (ServerDirContext) occurs, and popped from
> InvocationStack when the invocation ends.
> * Added InvocationStack to represent recursive calls to
> ContextPartitionNexus. Actually it has been done by an AspectJ class in
> ApacheDS in conjunction with Invocation. Now, Invocation doesn't manage
> context stacks anymore. Instead, target JNDI context property is added to
> Invocation to represent which JNDI context the invocation came from, and
> Invocation (instead of Context) is pushed to and popped from
> InvocationStack. InvocationStack is managed by its internal instance map
> whose key is 'current thread'. I didn't use ThreadLocals to manage
> resources more explicitly, so the content of InvocationStack is explicitly
> pushed and popped by ContextPartitionNexusProxy.
> * The change above helped me to removed dependency to AspectJ, and it means
> that ApacheDS now compiles OK in Java 5.
>
> The changes in 'authn' package
> ==============================
> * Authenticator.init() and destroy() method is more useful now.
> * AuthenticatorContext is deprecated by ContextFactoryConfiguration and
> AuthenticatorConfiguration, and removed.
>
> What didn't change
> ==================
> * All tests still pass.
> * Most part of ContextPartition is retained.
> * You can configure ApacheDS as before.
>
> TODO
> ====
> * Rewrite JavaDocs
> * Improve more by others' feedback.
> * Transaction API (perhaps we have to merge now and branch again for it)
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
--
Søren Hilmer, M.Sc.
R&D manager Phone: +45 72 30 64 00
TietoEnator IT+ A/S Fax: +45 72 30 64 02
Ved Lunden 12 Direct: +45 72 30 64 57
DK-8230 Åbyhøj Email: soren.hilmer <at> tietoenator.com
Re: [apacheds] A final summary for the changes in 'db_refactor' branch before merging it back.
Posted by Trustin Lee <tr...@gmail.com>.
Today, I added a class AbstractContextPartition that will help users
implement their own implementations. Most methods are implemented by
default:
http://svn.apache.org/viewcvs.cgi/directory/apacheds/branches/db_refactor/core/src/main/java/org/apache/ldap/server/partition/AbstractContextPartition.java?rev=193074&view=markup
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: [apacheds] A final summary for the changes in 'db_refactor' branch before merging it back.
Posted by Trustin Lee <tr...@gmail.com>.
I'm sorry for some grammar errors. Please let me know if there are more.
Here's a summary of the changes in 'db_refactor' branch. Please follow this
> message browsing your working in your IDE. That will help you much more to
> understand this.
>
'working' -> 'working copy'
* The change above helped me to removed dependency to AspectJ, and it means
> that ApacheDS now compiles OK in Java 5.
>
'to removed' -> 'to remove'
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/