OSGi and the LDAP API

[Emmanuel Lecharny <el...@gmail.com>]

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

Re: OSGi and the LDAP API

[Emmanuel Lecharny <el...@gmail.com>]

On 5/18/11 6:41 PM, Kiran Ayyagari wrote:
> On Wed, May 18, 2011 at 8:40 PM, Emmanuel Lecharny<el...@gmail.com>  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

Re: OSGi and the LDAP API

[Kiran Ayyagari <ka...@apache.org>]

On Wed, May 18, 2011 at 8:40 PM, Emmanuel Lecharny <el...@gmail.com> 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.

> 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
>
>

thanks for taking care of this Emmanuel

-- 
Kiran Ayyagari