Hi guys,
yesterday we tried to deal with some existing issues related to the way
we use OSGi. There are a few that need to be improved or discussed. Here
is a brain dump about those things.
1) Currently, we have two modes. The first one is when the API is loaded
into an OSGi enabled application, and the secodn one is when we use the
API in an application which is not using an OSGi container.
In the second case, we use the StandaloneLdapCodecService to initialize
Felix, if it's not already done otherwie we just do nothing.
Beside the name (why is it a CodecService ? Because it just deal with
the codec atm, but at some point we will also load schema elements, so
we need to find a better name), one of the main issue is that the
bundles are loaded only when they are put into a directory.
In shared, it's not an issue, but when we use an application which does
not have an OSGi container started, then we have to copy the bundles
that are not loaded by default into a special directory. I suggest we
keep this mode, but that we also propose a mode in which the list of
bundles to load is provided, with their path, so we won't have to copy
the bundles.
2) We have a list of packages to load in the StandaloneLdapCodecService
class. If we move, or rename, one of those package, we will get an
error. Plus we will have to remember to update this list if we add some
new classes.
A TODO says that this list has to be generated from the Manifest. Yep.
Let's do that !
3) we have some issues in Eclipse, as we have to set some property in
the command line when running some of the tests. This is not convenient
at all, but unless we find a simple way to do it automatically, we are
quite dead. I would suggest as a bare minimum that we document this in
the development guide.
4) We have to start thinking about transforming ApacheDS to be OSGi
enbled. Not having done this job makes things more difficult. We wll
have to do it anyway, the question is : why wasting time trying to
workaround the issues we have, instead of spending this time to do the
job completely ?
I would like to get a API 1.0.0-M3 out asap now. A lot of work has been
done since 1.0.0-M2, and before moving to the next step, I think it
would be a good idea to cut a new milestone.
There is one more thing I think we should provide asap : a
Apacheds-2.0.0-M1. Many users are now complaining about the 1.5.7 bugs,
and we have no way to get them happy, bt telling them to patch the code
themselves, something which is frankly tedious.
This 2.0.0-M1 is not a feature not a code freeze, it's just a clear
signal that we now are ready to move toward to 2.0.0. The configuration
has been completely reviewed, it will depend on the 1.0.0 API, and many
bugs have been fixed.
I have no idea about how much time we will have to spend on 2.0.0 before
being able to announce a RC1, but at some point, it's a bit frustrating
to keep going at the current pace. What has been done since January on
the API has been just great. 3 releases have been delivered (I'm
including 1.0.0-M3), with a lot of cleanup, some big features addition,
and it was a pleasure to see things moving that fast. Lets follow the
same path for ADS !
Thanks !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
