I did not addressed the export of org.osgi.service.cm in fileinstall before 2.0.0 release. I've switch the log package export to an dynamic one, but cm package is much widely used so the change is a bit more difficult to address. Anyway, I've raised FELIX-1591 for that.
On Mon, Sep 14, 2009 at 15:54, Stuart McCulloch <[email protected]> wrote: > 2009/9/14 Atle Prange <[email protected]> > >> I have just upgraded to version 2.0.0 of the framework. I resolved the >> problem by removing the exports (and org.osgi contents) from these >> bundles and installed compendium 1.4.0. >> >> I don't knwo if the workaround works by chance or by design... >> > > it works 'by design' because that version of the compendium includes > the latest configadmin API - and removing the exports from the other > bundles leaves the compendium as the only source for that package, > so you now have a consistent class space > > but it's not ideal, as it means you need to install both the configadmin > bundle and the compendium - whereas before the configadmin bundle > was self-contained (people have different views on whether you should > ship the API with implementations or not: convenience vs. flexibility) > > removing the export from fileinstall, and switching it to use a dynamic > or optional import should also fix the problem - there also seems to be > a bug in the framework which needs to be addressed, although it won't > affect you once the export is removed from fileinstall > > the configadmin bundle shouldn't need any change to its exports > > >> -atle >> >> >> On Mon, 2009-09-14 at 11:33 +0200, Felix Meschberger wrote: >> > Hi, >> > >> > Stuart McCulloch schrieb: >> > > 2009/9/14 Felix Meschberger <[email protected]> >> > > >> > >> Hi, >> > >> >> > >> Could it be that your bundles resolve to different >> org.osgi.service.cm >> > >> packages ? >> > >> >> > > >> > > that's my suspicion... although it is also odd that the fileinstall >> service >> > > tracker >> > > received an event for a service that's not class-loader compatible with >> > > fileinstall >> > > - I would have expected the framework to filter this out and avoid the >> > > exception >> > >> > Definitely, I would say. >> > >> > Atle: what framework version are you using ? >> > >> > Regards >> > Felix >> > >> > >> > > >> > > >> > >> The configuadmin 1.2.4 exports the 1.3 version (and re-imports its own >> > >> export). >> > >> >> > >> If in the framework an older version of the cm package is exported, >> e.g. >> > >> from the system bundle, bundles may be wired to the old package and >> thus >> > >> you get the class cast exceptions. >> > >> >> > >> Best solution would be to remove the cm package export from that other >> > >> bundle if possible. >> > >> >> > >> Or you might just refresh the fileinstall bundle, which would then >> cause >> > >> the fileinstall bundle to wire to the new cm package version 1.3 >> export >> > >> from configadmin 1.2.4. >> > >> >> > >> Regards >> > >> Felix >> > >> >> > >> Atle Prange schrieb: >> > >>> Hi, >> > >>> >> > >>> when i install the configadmin bundle 1.2.4 i get >> ClassCastExceptions: >> > >>> >> > >>> java.lang.ClassCastException: >> > >>> >> > >>> org.apache.felix.cm.impl.ConfigurationAdminImpl cannot be cast to >> > >>> org.osgi.service.cm.ConfigurationAdmin >> > >>> at org.apache.felix.fileinstall.internal.FileInstall >> > >>> $1.addingService(FileInstall.java:79) >> > >>> at org.osgi.util.tracker.ServiceTracker >> > >>> $Tracked.customizerAdding(ServiceTracker.java:896) >> > >>> at >> > >>> >> > >> >> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261) >> > >>> at >> > >>> org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:233) >> > >>> at org.osgi.util.tracker.ServiceTracker >> > >>> $Tracked.serviceChanged(ServiceTracker.java:840) >> > >>> at >> > >>> >> > >> >> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:878) >> > >>> at >> > >>> >> > >> >> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:732) >> > >>> at >> > >>> >> > >> >> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:662) >> > >>> at >> > >> org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3603) >> > >>> at org.apache.felix.framework.Felix.access$000(Felix.java:40) >> > >>> at >> > >> org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:624) >> > >>> at >> > >>> >> > >> >> org.apache.felix.framework.ServiceRegistry.registerService(ServiceRegistry.java:90) >> > >>> at >> > >> org.apache.felix.framework.Felix.registerService(Felix.java:2716) >> > >>> at >> > >>> >> > >> >> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:252) >> > >>> at >> > >>> >> > >> >> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:230) >> > >>> at >> > >>> >> > >> >> org.apache.felix.cm.impl.ConfigurationManager.start(ConfigurationManager.java:237) >> > >>> at >> > >>> >> > >> >> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:667) >> > >>> at >> org.apache.felix.framework.Felix.activateBundle(Felix.java:1699) >> > >>> at >> org.apache.felix.framework.Felix.startBundle(Felix.java:1621) >> > >>> at >> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:890) >> > >>> at >> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:877) >> > >>> at >> > >>> >> > >> >> org.apache.felix.fileinstall.internal.DirectoryWatcher.start(DirectoryWatcher.java:819) >> > >>> at >> > >>> >> > >> >> org.apache.felix.fileinstall.internal.DirectoryWatcher.start(DirectoryWatcher.java:805) >> > >>> at >> > >>> >> > >> >> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:301) >> > >>> >> > >>> I assume this happens because both configadmin and fileinstall export >> > >>> the org.osgi.service.cm package. When configadmin tries to cast its >> own >> > >>> COnfigurationManagerImpl to ConfigurationManager, its sees >> fileinstalls >> > >>> exported interface, and throws a classcast exeption. >> > >>> >> > >>> Am i correct? >> > >>> >> > >>> Would a solution be to omit the interfaces from the bundles and >> rather >> > >>> import them from the a compendium bundle? >> > >>> >> > >>> -atle >> > >>> >> > >>> >> > >>> --------------------------------------------------------------------- >> > >>> To unsubscribe, e-mail: [email protected] >> > >>> For additional commands, e-mail: [email protected] >> > >>> >> > >>> >> > >> --------------------------------------------------------------------- >> > >> To unsubscribe, e-mail: [email protected] >> > >> For additional commands, e-mail: [email protected] >> > >> >> > >> >> > > >> > > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> > >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > -- > Cheers, Stuart > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
