directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: OSGi and the LDAP API
Date Thu, 19 May 2011 09:13:49 GMT
On 5/18/11 6:41 PM, Kiran Ayyagari wrote:
> On Wed, May 18, 2011 at 8:40 PM, Emmanuel Lecharny<>  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/ (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.

Emmanuel L├ęcharny

View raw message