Hi guys,
I'm done with my experiment, and so far, it's going well. I have run all
the tests against the shared-osgi branch, and after a few fixes, got a
build successful.
Now, I still have an issue, which was already present with the previous
code base. Let me explain...
First, the modifications I made were mostly to remove everything related
to Felix in the branch. Not that it was bad, but we have to move them
into ApacheDS, with the exact same logic (ie, check if we already are
embeded into an OSGi capable application, and if not, start Felix).
I now load the controls and extended operations by using some system
property variables, and it's statically done in the FrameworkRunner and
frameworkSuite classes, so that the tests can pass with success. In
Shared, it's loaded into the AbstractCodecServiceTest class.
So far, so good, except that we don't load those controls when we run an
application, and I'm wondering what's the best way to do that. The base
idea is to add the new Control/ExtendedOp... FQCN in the system property
variables too, but we don't want the user to have to do that for all the
existing controls. Plus we need to differenciate the internal extension
points (those we define in the API) with the user own extension points.
One solution might be to have a property file to hold those FQCN, but
that doe snot please me a lot. We can also statically define those
default extension points in the code, which is probably a bit stiff.
Defining them in a pom.xml is also an option, but considering that they
won't change a lot, i'm not sure it worth the effort
Another tricky aspect is that if we use system properties, we need to be
sure that when defining a new value, it does not replace the existing one.
Last, not least, we currently use Factories for all the
Controls/ExtendedOps, and I'm not sure it's necessary. Those factories
are defined because we want to store the LdapApiService reference into
the loaded element : why do we want to do that ? (this is a question, I
don't see the reason behind this decision). Another option would be to
instanciate the classes directly, but I know Alex will say that's bad
taste :) I don't disagree, but I want to be sure we aren't doing
something useless here.
Ok, I'll wait until tomorrow before committing/merging what I've done
into the trunk, and I'll try to do it as one big (or maybe 3) so that we
can easily revert.
Feel free to provide any feedback.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
