directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre-Arnaud Marcelot>
Subject Re: [Studio] OSGi and the codec
Date Thu, 10 Feb 2011 09:37:23 GMT
On 9 févr. 2011, at 19:38, 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,

Yeah indeed, that's why Maven doesn't complain with its usage as plain jar.

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

I already tried to require specifically the Felix bundle inside Shared bundles via the 'Require-Bundle'
policy but it didn't seem to solve anything...

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

Yeah, I think it can be a good solution. But I was trying in the first place to avoid having
two codec modules depending on the target.
This solution has to be tested.

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

View raw message