On 9 févr. 2011, at 19:38, Alex Karasulu wrote: > On Wed, Feb 9, 2011 at 12:33 PM, Pierre-Arnaud Marcelot <[email protected]> > 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 Shared. >> >> 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.
