On 5/18/11 6:41 PM, Kiran Ayyagari wrote:
On Wed, May 18, 2011 at 8:40 PM, Emmanuel Lecharny<[email protected]> wrote:
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.
this is an interesting development
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.
as we know, for sure system needs a hint to start with to find the
extensions (both default and custom)
in addition to the above options I would like to add one
i.e to keep a special empty marker file in the jar which hints the
system to search for extensions
e.x META-INF/has-custom-extensions.mf (think of WEB-INF/web.xml
for which web containers look before deciding to deploy or not)
if this file is present then we will scan all the classes inside
the jar for possible extension implementations
this is just a variant of the above techniques with only advantage
of avoiding any hand edited information in the file.
Sure. What has been implemented in trunk was an automatic discovery
mechanism, we can most certainly have such a mechanism, but I would
suggest that it should be done after 1.0.0-M4.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
