directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [Studio] OSGi and the codec
Date Thu, 10 Feb 2011 11:33:13 GMT
On Wed, Feb 9, 2011 at 8:38 PM, Alex Karasulu <> wrote:
> On Wed, Feb 9, 2011 at 12:33 PM, Pierre-Arnaud Marcelot <> wrote:
>> Hi Alex,
>> I still have no clue on how to resolve the issue.
> :(
>> While looking at the code of the codec in the 'DefaultLdapCodecService' class I saw
we're accessing the "org.apache.felix.framework.*" packages to launch a new Felix instance.
>> Looking back at the Manifest of the 'org.apache.felix.framework' bundle (attached
at [1]), I found that this packages is marked as private:
>>> Private-Package: org.apache.felix.framework,[...]
> This does not matter in standalone mode outside of an OSGi container,
> but yes as you say they will not resolve inside eclipse.
>> That might be the cause of Studio issues.
> Can be one part of it but I think its also due to a collision in some
> common org.osgi pacakages that you quote below. This is why we have to
> put the "provided" scope on various maven OSGi artifacts.
>> As well as the fact that both Eclipse and this Felix bundle embeds and exports 'org.osgi.*'
packages, making it complicated for bundles importing such packages to select which bundle
to use.
> I think this is the primary issue.
>> For those who are not aware of the situation, in the 'm1' branch Studio cannot be
launched anymore. Most of our plugins are being "invalidated" and not resolved by Eclipse
OSGI container.
>> The situation is the consequence of the introduction of Felix in the codec part of
>> I will try to dig some more.
> I think we need two different codec implementations. Have you given my
> thought below any consideration?
>>> If you cannot find a solution to our new problem, we may have to write
>>> a separate codec service implementation just for Studio. Unfortunately
>>> this means we're probably going to need 2 separate modules instead of
>>> a single ldap-codec. Let me break down what I am thinking:
>>> ldap-codec => For Studio and Future Pure OSGi Environments
>>>    1 - pure OSGi codec service bundle
>>>    2 - bundle activator registers the codec service within any OSGi environment
>>>    3 - studio must accesses codec service running inside equinox
>>>    4 - might need some extra (custom) goooo inside the MANIFEST.MF to
>>> work in eclipse/equinox environment
>>> ldap-codec-standalone => For Present Client and Server (ApacheDS)
>>>    1 - a bundle, but no activator
>>>    2 - default service implementation embeds Felix
>>>    3 - starts up the codec bundle first, whose activator registers
>>> the pure OSGi codec service in Felix
>>>    4 - gets handle on the service inside Felix
>>>    5 - then discovers, and starts up extension plugins
>>>    6 - default implementation not the same as service inside Felix,
>>> default implementation wraps service inside Felix
> So we will have 2 separate implementations of the LdapServiceCodec
> interface. One running inside the OSGi container as a pure OSGi
> service, and does not embed Felix: inside the shared-ldap-codec.jar
> bundle.
> The other embeds Felix and does not run inside an OSGi container. It
> should not even be inside a bundle: the
> shared-ldap-codec-standalone.jar simple jar file.
>>> OK so this is a bit involved. If you cannot figure something out
>>> tomorrow maybe we have no choice but to pursue this approach. In step
>>> 3 in first block above:
>>>    3 - studio must accesses codec service running inside equinox
>>> I presume this is possible but it will take know how in studio. I'm
>>> sure it's really easy to access a registered service. Never done it
>>> myself so would need your feedback here.

Another update: Pierre already knows of [0] but please see it for
changes if you're not up to speed with the topic.

I moved the old DefaultLdapCodecService implementation embedding Felix
over to StandaloneLdapCodecService. The present
DefaultLdapCodecService does not embed Felix. Currently Studio builds
fine using it but it's still not showing the ldap perspective.

I have some more work to do here but don't want to commit until I can
push it through.

[0] -

View raw message