>
> Justin
>
> On 4/21/10 10:15 AM, Vidar Ramdal wrote:
>> I'm trying to set up my own launchpad build, using maven-launchpad-plugin.
>>
>> I'm having trouble getting all Felix components to play nice together.
>> All components fail to start. The log shows:
>>
>> 21.04.2010 15:50:39.094 *INFO* [FelixDispatchQueue]
>> org.apache.felix.metatype BundleEvent STARTED
>> 21.04.2010 15:50:39.118 *INFO* [FelixStartLevel] org.apache.felix.scr
>> Service [Declarative Services Management Agent,29] ServiceEvent
>> REGISTERED
>> 21.04.2010 15:50:39.119 *INFO* [FelixStartLevel] org.apache.felix.scr
>> Service [Declarative Services Configuration Support Listener,30]
>> ServiceEvent REGISTERED
>> 21.04.2010 15:50:39.127 *WARN* [FelixStartLevel]
>> org.apache.felix.configadmin Service
>> [org.apache.felix.cm.ConfigurationAdmin,26] Service
>> org.apache.felix.scr.impl.config.scrconfiguratio...@55d7fc31 is not a
>> ManagedService
>> 21.04.2010 15:50:39.128 *INFO* [FelixStartLevel] org.apache.felix.scr
>> Service [org.apache.felix.scr.ScrService,31] ServiceEvent REGISTERED
>> 21.04.2010 15:50:39.131 *INFO* [FelixStartLevel] org.apache.felix.scr
>> Version = 1.4.0
>> 21.04.2010 15:50:39.156 *ERROR* [FelixStartLevel]
>> org.apache.sling.jcr.webconsole
>> [org.apache.sling.jcr.webconsole.internal.NamespaceConfigurationPrinter]
>> Cannot register Component (java.lang.ClassCastException:
>> org.apache.felix.cm.impl.ConfigurationAdminImpl cannot be cast to
>> org.osgi.service.cm.ConfigurationAdmin) java.lang.ClassCastException:
>> org.apache.felix.cm.impl.ConfigurationAdminImpl cannot be cast to
>> org.osgi.service.cm.ConfigurationAdmin
>>       at 
>> org.apache.felix.scr.impl.config.ConfigurationComponentRegistry.createComponentHolder(ConfigurationComponentRegistry.java:104)
>>       at 
>> org.apache.felix.scr.impl.BundleComponentActivator.loadDescriptor(BundleComponentActivator.java:244)
>>       at 
>> org.apache.felix.scr.impl.BundleComponentActivator.initialize(BundleComponentActivator.java:147)
>>       at 
>> org.apache.felix.scr.impl.BundleComponentActivator.<init>(BundleComponentActivator.java:111)
>>       at 
>> org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:238)
>>       at 
>> org.apache.felix.scr.impl.Activator.loadAllComponents(Activator.java:194)
>>       at org.apache.felix.scr.impl.Activator.start(Activator.java:108)
>>       at 
>> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:589)
>>       at org.apache.felix.framework.Felix.startBundle(Felix.java:1458)
>>       at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:984)
>>       at 
>> org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:263)
>>       at java.lang.Thread.run(Thread.java:637)
>>
>>
>> The stacktrace is repeated for each component as they try to start.
>>
>> From what I can see, the org.osgi.service.cm package is exported by
>> two bundles: The System bundle, and the org.apache.felix.configadmin
>> bundle.
>> When I disable the org.apache.felix.configadmin the log messages go
>> away, but now all components that try to use ConfigAdmin fails
>> (naturally).
>>
>> Is there a way to resolve this?

On Wed, Apr 21, 2010 at 4:28 PM, Justin Edelson <justinedel...@gmail.com> wrote:
> org.osgi.service.cm should not be exported by the system bundle. These
> should be the only org.osgi.* packages exported by the system bundle:
>
> org.osgi.framework,version=1.5.0
> org.osgi.framework.hooks.service,version=1.0.0
> org.osgi.framework.launch,version=1.0.0
> org.osgi.service.packageadmin,version=1.2.0
> org.osgi.service.startlevel,version=1.1.0
> org.osgi.service.url,version=1.0.0
> org.osgi.util.tracker,version=1.4.0
>
> I'd suggest taking a look at your sling.properties file and see if
> you're specifying that org.osgi.service.cm be exported from the system
> bundle.

In sling.properties, org.osgi.service.cm is listed on the
osgi-compendium-services line, which is again referenced from
org.osgi.framework.system.packages=${osgi-core-packages},
${osgi-compendium-services}, ${jre-${java.specification.version}}
${org.apache.sling.launcher.system.packages}

I guess this means it is exported?

Also, the values of the sling.properties is overwritten on each
startup, by values from the launchpad base bundle. Is there an easy
way to avoid that, without hacking launchpad base?

-- 
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Reply via email to