You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Atle Prange <at...@gmail.com> on 2009/09/14 09:48:09 UTC
Configadmin and fileinstall
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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Configadmin and fileinstall
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/9/14 Felix Meschberger <fm...@gmail.com>
> Hi,
>
> Stuart McCulloch schrieb:
> >> 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?
> >>
> >
> > fileinstall and configadmin both export and import the
> > org.osgi.service.cmpackage:
> >
> > fileinstall exports it with version 1.2 and imports a range of "[1.2,
> 2)"
> >
> > the new configadmin exports version 1.3 and imports "1.3" or later
>
> Hmm, should fileinstall really export configadmin ? I would rather
> suggest fileinstall would import configadmin optionally and act
> accordingly if the configadmin package would not be available ...
>
yep, we had a similar discussion about its use of the logging API
as you say, it shouldn't really be exporting these API packages
to begin with - and should use an optional (or dynamic) import
> so the problem basically is the new configadmin bundle is incompatible
> with
> > the earlier API,
> > if it was able to import (and work) with the 1.2 level then you wouldn't
> see
> > the cast exception
>
> Well, the OSGi CPEG obviously decided to bumpt the configadmin package
> version to 1.3 (FELIX-1219 [1])
>
and that's fine, I misread the exception and thought it occurred in
the configadmin code - but it's actually fileinstall who's at fault by
exporting the API
> >
> > Would a solution be to omit the interfaces from the bundles and rather
> >> import them from the a compendium bundle?
>
> I think in this concrete case, the configadmin bundle could happily life
> with 1.2 API because the API itself has not changed codewise (it is just
> bumped because of support of multi-value service.pid property).
>
> Still, I think the compendium service bundle should probably export the
> implemented API (cm in the case of configadmin).
>
> But consumer bundles should probably not export that API because it
> leads to various issues. Of course this makes consumer bundles a bit
> more complicated if the respective API is not availalbe in the framework
> ... but this is also the case for any API used not just OSGi compendium
> API.
>
+1 consumers shouldn't export the API (it's different of course for
providers)
> Regards
> Felix
>
> [1] https://issues.apache.org/jira/browse/FELIX-1219
>
> >
> > -atle
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers, Stuart
Re: Configadmin and fileinstall
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Stuart McCulloch schrieb:
>> 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?
>>
>
> fileinstall and configadmin both export and import the
> org.osgi.service.cmpackage:
>
> fileinstall exports it with version 1.2 and imports a range of "[1.2, 2)"
>
> the new configadmin exports version 1.3 and imports "1.3" or later
Hmm, should fileinstall really export configadmin ? I would rather
suggest fileinstall would import configadmin optionally and act
accordingly if the configadmin package would not be available ...
> so the problem basically is the new configadmin bundle is incompatible with
> the earlier API,
> if it was able to import (and work) with the 1.2 level then you wouldn't see
> the cast exception
Well, the OSGi CPEG obviously decided to bumpt the configadmin package
version to 1.3 (FELIX-1219 [1])
>
> Would a solution be to omit the interfaces from the bundles and rather
>> import them from the a compendium bundle?
I think in this concrete case, the configadmin bundle could happily life
with 1.2 API because the API itself has not changed codewise (it is just
bumped because of support of multi-value service.pid property).
Still, I think the compendium service bundle should probably export the
implemented API (cm in the case of configadmin).
But consumer bundles should probably not export that API because it
leads to various issues. Of course this makes consumer bundles a bit
more complicated if the respective API is not availalbe in the framework
... but this is also the case for any API used not just OSGi compendium API.
Regards
Felix
[1] https://issues.apache.org/jira/browse/FELIX-1219
>
> -atle
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Configadmin and fileinstall
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/9/14 Atle Prange <at...@gmail.com>
> 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?
>
fileinstall and configadmin both export and import the
org.osgi.service.cmpackage:
fileinstall exports it with version 1.2 and imports a range of "[1.2, 2)"
the new configadmin exports version 1.3 and imports "1.3" or later
here's what I think is happening:
fileinstall is resolved before the configadmin bundle is installed, so it
gets org.osgi.service.cm
from itself at the 1.2 version level (or from the compendium bundle if
that was already installed)
when configadmin is installed, it needs the later version (1.3) which is
only available from itself
(your compendium bundle probably exports 1.2 which is the current
released version of the API)
so fileinstall and configadmin have different sources of
org.osgi.service.cm => cast exception!
if you refresh fileinstall (ie. use the OSGi console to do "refresh <id>"
where <id> is the bundle id
of fileinstall) then you should see fileinstall restart and re-install
configadmin without any exception
this is because the refreshed fileinstall now sees the later
org.osgi.service.cm (the 1.3 version)
and gets wired to that instead of its own 1.2 copy, or the version from the
compendium bundle
so the problem basically is the new configadmin bundle is incompatible with
the earlier API,
if it was able to import (and work) with the 1.2 level then you wouldn't see
the cast exception
Would a solution be to omit the interfaces from the bundles and rather
> import them from the a compendium bundle?
>
this wouldn't help in this situation because the compendium bundle you have
at the moment
probably doesn't contain the latest org.osgi.service.cm API (as this is
still being finalized for
the next release of the spec) which is what the configadmin bundle actually
needs
this problem is more of a versioning / compatibility issue...
-atle
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers, Stuart
Re: Configadmin and fileinstall
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <mc...@gmail.com> wrote:
> 2009/9/14 Atle Prange <at...@gmail.com>
>
>> 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 <fm...@gmail.com>
>> > >
>> > >> 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: users-unsubscribe@felix.apache.org
>> > >>> For additional commands, e-mail: users-help@felix.apache.org
>> > >>>
>> > >>>
>> > >> ---------------------------------------------------------------------
>> > >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> > >> For additional commands, e-mail: users-help@felix.apache.org
>> > >>
>> > >>
>> > >
>> > >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> > For additional commands, e-mail: users-help@felix.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
>
> --
> Cheers, Stuart
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Configadmin and fileinstall
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/9/14 Atle Prange <at...@gmail.com>
> 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 <fm...@gmail.com>
> > >
> > >> 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: users-unsubscribe@felix.apache.org
> > >>> For additional commands, e-mail: users-help@felix.apache.org
> > >>>
> > >>>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > >> For additional commands, e-mail: users-help@felix.apache.org
> > >>
> > >>
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers, Stuart
Re: Configadmin and fileinstall
Posted by Atle Prange <at...@gmail.com>.
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...
-atle
On Mon, 2009-09-14 at 11:33 +0200, Felix Meschberger wrote:
> Hi,
>
> Stuart McCulloch schrieb:
> > 2009/9/14 Felix Meschberger <fm...@gmail.com>
> >
> >> 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: users-unsubscribe@felix.apache.org
> >>> For additional commands, e-mail: users-help@felix.apache.org
> >>>
> >>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Configadmin and fileinstall
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Stuart McCulloch schrieb:
> 2009/9/14 Felix Meschberger <fm...@gmail.com>
>
>> 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: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Configadmin and fileinstall
Posted by Karl Pauls <ka...@gmail.com>.
On Mon, Sep 14, 2009 at 11:50 AM, Stuart McCulloch <mc...@gmail.com> wrote:
> 2009/9/14 Felix Meschberger <fm...@gmail.com>
>
>> Hi,
>>
>> Neil Bartlett schrieb:
>> > On Mon, Sep 14, 2009 at 10:16 AM, Stuart McCulloch <mc...@gmail.com>
>> wrote:
>> >> 2009/9/14 Felix Meschberger <fm...@gmail.com>
>> >> 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
>> >
>> > Is it possible that FileInstall is calling
>> > BundleContext.getAllServiceReferences() or ServiceTracker.open(true)?
>>
>> No, it seems to do ServiceTracker.open(), which is equivalent to
>> ServiceTracker.open(false). So this should be save ...
>>
>
> I think there's a bug in our ServiceReference.isAssignableTo
> implementation...
>
> the javadoc for this method states:
>
> "This method performs the following checks:
>
> 1. Get the package name from the specified class name.
> 2. For the bundle that registered the service referenced by this
> ServiceReference (registrant bundle);
> find the source for the package. If no source is found then return
> true if the registrant bundle is
> equal to the specified bundle; otherwise return false.
> 3. If the package source of the registrant bundle is equal to the package
> source of the specified
> bundle then return true; otherwise return false."
>
> whereas our implementation does:
>
> // There are three situations that may occur here:
> // 1. The requester does not have a wire for the package.
> // 2. The provider does not have a wire for the package.
> // 3. Both have a wire for the package.
> // For case 1, we do not filter the service reference since we
> // assume that the bundle is using reflection or that it won't
> // use that class at all since it does not import it. For
> // case 2, we have to try to load the class from the class
> // loader of the service object and then compare the class
> // loaders to determine if we should filter the service
> // refernce. In case 3, we simply compare the exporting
> // modules from the package wiring to determine if we need
> // to filter the service reference.
>
> assume both the provider and requester have no wire for the package
> (as happens when a bundle uses it's own export, as in this situation)
>
> the javadoc says isAssignableTo should return false, because the
> provider has no wire and the provider != requester - but we'll return
> true because the requester has no wire and we do that check first
>
> WDYT?
Hm, you might be right. At one point we had a wire for internal
packages too (as this was the current state of the draft spec at this
time). However, this has changed again and now there is no wire in
this case anymore. We will have to look into this.
regards,
Karl
> (ps. I ran the same test on Equinox and no exception occurred)
>
> Regards
>> Felix
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
>
> --
> Cheers, Stuart
>
--
Karl Pauls
karlpauls@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Configadmin and fileinstall
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/9/14 Richard S. Hall <he...@ungoverned.org>
> Could we get a JIRA issue opened on this? It does sound like a bug...
>
done: http://issues.apache.org/jira/browse/FELIX-1600
> -> richard
> On 9/14/09 5:50, Stuart McCulloch wrote:
>
>> 2009/9/14 Felix Meschberger<fm...@gmail.com>
>>
>>
>>
>>> Hi,
>>>
>>> Neil Bartlett schrieb:
>>>
>>>
>>>> On Mon, Sep 14, 2009 at 10:16 AM, Stuart McCulloch<mc...@gmail.com>
>>>>
>>>>
>>> wrote:
>>>
>>>
>>>> 2009/9/14 Felix Meschberger<fm...@gmail.com>
>>>>> 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
>>>>>
>>>>>
>>>> Is it possible that FileInstall is calling
>>>> BundleContext.getAllServiceReferences() or ServiceTracker.open(true)?
>>>>
>>>>
>>> No, it seems to do ServiceTracker.open(), which is equivalent to
>>> ServiceTracker.open(false). So this should be save ...
>>>
>>>
>>>
>> I think there's a bug in our ServiceReference.isAssignableTo
>> implementation...
>>
>> the javadoc for this method states:
>>
>> "This method performs the following checks:
>>
>> 1. Get the package name from the specified class name.
>> 2. For the bundle that registered the service referenced by this
>> ServiceReference (registrant bundle);
>> find the source for the package. If no source is found then return
>> true if the registrant bundle is
>> equal to the specified bundle; otherwise return false.
>> 3. If the package source of the registrant bundle is equal to the
>> package
>> source of the specified
>> bundle then return true; otherwise return false."
>>
>> whereas our implementation does:
>>
>> // There are three situations that may occur here:
>> // 1. The requester does not have a wire for the package.
>> // 2. The provider does not have a wire for the package.
>> // 3. Both have a wire for the package.
>> // For case 1, we do not filter the service reference since we
>> // assume that the bundle is using reflection or that it won't
>> // use that class at all since it does not import it. For
>> // case 2, we have to try to load the class from the class
>> // loader of the service object and then compare the class
>> // loaders to determine if we should filter the service
>> // refernce. In case 3, we simply compare the exporting
>> // modules from the package wiring to determine if we need
>> // to filter the service reference.
>>
>> assume both the provider and requester have no wire for the package
>> (as happens when a bundle uses it's own export, as in this situation)
>>
>> the javadoc says isAssignableTo should return false, because the
>> provider has no wire and the provider != requester - but we'll return
>> true because the requester has no wire and we do that check first
>>
>> WDYT?
>>
>> (ps. I ran the same test on Equinox and no exception occurred)
>>
>> Regards
>>
>>
>>> Felix
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers, Stuart
Re: Configadmin and fileinstall
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Could we get a JIRA issue opened on this? It does sound like a bug...
-> richard
On 9/14/09 5:50, Stuart McCulloch wrote:
> 2009/9/14 Felix Meschberger<fm...@gmail.com>
>
>
>> Hi,
>>
>> Neil Bartlett schrieb:
>>
>>> On Mon, Sep 14, 2009 at 10:16 AM, Stuart McCulloch<mc...@gmail.com>
>>>
>> wrote:
>>
>>>> 2009/9/14 Felix Meschberger<fm...@gmail.com>
>>>> 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
>>>>
>>> Is it possible that FileInstall is calling
>>> BundleContext.getAllServiceReferences() or ServiceTracker.open(true)?
>>>
>> No, it seems to do ServiceTracker.open(), which is equivalent to
>> ServiceTracker.open(false). So this should be save ...
>>
>>
> I think there's a bug in our ServiceReference.isAssignableTo
> implementation...
>
> the javadoc for this method states:
>
> "This method performs the following checks:
>
> 1. Get the package name from the specified class name.
> 2. For the bundle that registered the service referenced by this
> ServiceReference (registrant bundle);
> find the source for the package. If no source is found then return
> true if the registrant bundle is
> equal to the specified bundle; otherwise return false.
> 3. If the package source of the registrant bundle is equal to the package
> source of the specified
> bundle then return true; otherwise return false."
>
> whereas our implementation does:
>
> // There are three situations that may occur here:
> // 1. The requester does not have a wire for the package.
> // 2. The provider does not have a wire for the package.
> // 3. Both have a wire for the package.
> // For case 1, we do not filter the service reference since we
> // assume that the bundle is using reflection or that it won't
> // use that class at all since it does not import it. For
> // case 2, we have to try to load the class from the class
> // loader of the service object and then compare the class
> // loaders to determine if we should filter the service
> // refernce. In case 3, we simply compare the exporting
> // modules from the package wiring to determine if we need
> // to filter the service reference.
>
> assume both the provider and requester have no wire for the package
> (as happens when a bundle uses it's own export, as in this situation)
>
> the javadoc says isAssignableTo should return false, because the
> provider has no wire and the provider != requester - but we'll return
> true because the requester has no wire and we do that check first
>
> WDYT?
>
> (ps. I ran the same test on Equinox and no exception occurred)
>
> Regards
>
>> Felix
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Configadmin and fileinstall
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/9/14 Felix Meschberger <fm...@gmail.com>
> Hi,
>
> Neil Bartlett schrieb:
> > On Mon, Sep 14, 2009 at 10:16 AM, Stuart McCulloch <mc...@gmail.com>
> wrote:
> >> 2009/9/14 Felix Meschberger <fm...@gmail.com>
> >> 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
> >
> > Is it possible that FileInstall is calling
> > BundleContext.getAllServiceReferences() or ServiceTracker.open(true)?
>
> No, it seems to do ServiceTracker.open(), which is equivalent to
> ServiceTracker.open(false). So this should be save ...
>
I think there's a bug in our ServiceReference.isAssignableTo
implementation...
the javadoc for this method states:
"This method performs the following checks:
1. Get the package name from the specified class name.
2. For the bundle that registered the service referenced by this
ServiceReference (registrant bundle);
find the source for the package. If no source is found then return
true if the registrant bundle is
equal to the specified bundle; otherwise return false.
3. If the package source of the registrant bundle is equal to the package
source of the specified
bundle then return true; otherwise return false."
whereas our implementation does:
// There are three situations that may occur here:
// 1. The requester does not have a wire for the package.
// 2. The provider does not have a wire for the package.
// 3. Both have a wire for the package.
// For case 1, we do not filter the service reference since we
// assume that the bundle is using reflection or that it won't
// use that class at all since it does not import it. For
// case 2, we have to try to load the class from the class
// loader of the service object and then compare the class
// loaders to determine if we should filter the service
// refernce. In case 3, we simply compare the exporting
// modules from the package wiring to determine if we need
// to filter the service reference.
assume both the provider and requester have no wire for the package
(as happens when a bundle uses it's own export, as in this situation)
the javadoc says isAssignableTo should return false, because the
provider has no wire and the provider != requester - but we'll return
true because the requester has no wire and we do that check first
WDYT?
(ps. I ran the same test on Equinox and no exception occurred)
Regards
> Felix
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers, Stuart
Re: Configadmin and fileinstall
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Neil Bartlett schrieb:
> On Mon, Sep 14, 2009 at 10:16 AM, Stuart McCulloch <mc...@gmail.com> wrote:
>> 2009/9/14 Felix Meschberger <fm...@gmail.com>
>> 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
>
> Is it possible that FileInstall is calling
> BundleContext.getAllServiceReferences() or ServiceTracker.open(true)?
No, it seems to do ServiceTracker.open(), which is equivalent to
ServiceTracker.open(false). So this should be save ...
Regards
Felix
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Configadmin and fileinstall
Posted by Neil Bartlett <nj...@gmail.com>.
On Mon, Sep 14, 2009 at 10:16 AM, Stuart McCulloch <mc...@gmail.com> wrote:
> 2009/9/14 Felix Meschberger <fm...@gmail.com>
> 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
Is it possible that FileInstall is calling
BundleContext.getAllServiceReferences() or ServiceTracker.open(true)?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Configadmin and fileinstall
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/9/14 Felix Meschberger <fm...@gmail.com>
> 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
> 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: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers, Stuart
Re: Configadmin and fileinstall
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Could it be that your bundles resolve to different org.osgi.service.cm
packages ?
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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org