You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Dan Gravell <el...@googlemail.com> on 2012/06/30 18:09:39 UTC
Help me understand ClassCastException after update
My OSGi adventure continues...
I have a bundle "Client" and bundle "Server". In Client's activator it
invokes code in Server, returning an object from Server, let's call it
server.A. A is defined in Server. Client then registers A as a service:
context.registerService(A.class, (A) serverClass.getA(), new Hashtable());
This works when it is first run.
If I then update Client and Server bundles, the Client Activator gets run
again. This time I get a ClassCastException saying "server.A cannot be cast
to server.A".
So I guess the classloaders are different for the A that is returned by
Server to the one Client sees. Given both bundles were updated at the same
time, why is this?
I make use of package versioning, if this is important. A's package,
server, was not updated, and its version was not incremented. Was the code
in Client using the old version of server.A?
I guess registering A as a service in Client, rather than Server, is
opposed to most sample code I see but is it the cause of the problem? If
classloaders work on a per package level then it won't help will it?
Thanks,
Dan
Re: Help me understand ClassCastException after update
Posted by Dan Gravell <el...@googlemail.com>.
Yeah, I think it must be something like that.
As posted above, I do a refresh, but after the update. The update is
performed by OBR to deploy() the latest bundle, which sucks in the
dependencies and performs the Activator restart which then fails with the
original CCE. The bundle appears not to be a STARTED state after the
Activator failure, and so when I try to do the refresh:
context.getBundle(0).adapt(FrameworkWiring.class).resolveBundles(null);
That fails with:
java.lang.IllegalStateException: Invalid BundleContext.
at
org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContextImpl.java:514)
at
org.apache.felix.framework.BundleContextImpl.getBundle(BundleContextImpl.java:173)
But I might be doing this wrong. This is called from a bundle that is
itself updated, so maybe that BundleContext is now stale? Or maybe it's
just the fact that the newly updated bundle is not STARTED because of the
CCE.
Dan
On Sat, Jun 30, 2012 at 5:46 PM, Richard S. Hall <he...@ungoverned.org>wrote:
> Updating the service doesn't completely get rid of its old exports, you
> need to refresh it to do that. Most likely if you updated the client first,
> then it gets wired to the old export and stays that way after you update
> the server. Regardless, if you want to make sure you don't have any old
> "stale" versions causing you confusion, you have to do a "refresh" after a
> series of updates and uninstalls.
>
> -> richard
>
>
> On 6/30/12 12:09, Dan Gravell wrote:
>
>> My OSGi adventure continues...
>>
>> I have a bundle "Client" and bundle "Server". In Client's activator it
>> invokes code in Server, returning an object from Server, let's call it
>> server.A. A is defined in Server. Client then registers A as a service:
>>
>> context.registerService(A.**class, (A) serverClass.getA(), new
>> Hashtable());
>>
>> This works when it is first run.
>>
>> If I then update Client and Server bundles, the Client Activator gets run
>> again. This time I get a ClassCastException saying "server.A cannot be
>> cast
>> to server.A".
>>
>> So I guess the classloaders are different for the A that is returned by
>> Server to the one Client sees. Given both bundles were updated at the same
>> time, why is this?
>>
>> I make use of package versioning, if this is important. A's package,
>> server, was not updated, and its version was not incremented. Was the code
>> in Client using the old version of server.A?
>>
>> I guess registering A as a service in Client, rather than Server, is
>> opposed to most sample code I see but is it the cause of the problem? If
>> classloaders work on a per package level then it won't help will it?
>>
>> Thanks,
>> Dan
>>
>>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Help me understand ClassCastException after update
Posted by Dan Gravell <el...@googlemail.com>.
Gah, I've just seen it again. Please bear with me. This time I got a list
of the BundleEvents concerning the two bundles.
Remember: com.elsten.bliss.bundle invokes code in com.elsten.bliss.platform
and then uses the return types to register services.
STOPPED com.elsten.bliss.platform [25]
UNRESOLVED com.elsten.bliss.platform [25]
UPDATED com.elsten.bliss.platform [25]
STOPPED com.elsten.bliss.bundle [31]
UNRESOLVED com.elsten.bliss.bundle [31]
UPDATED com.elsten.bliss.bundle [31]
RESOLVED com.elsten.bliss.platform [25]
STARTED com.elsten.bliss.platform [25]
RESOLVED com.elsten.bliss.bundle [31]
STOPPED com.elsten.bliss.bundle [31]ERROR:
Resolver: Start error - com.elsten.bliss.bundle
org.osgi.framework.BundleException: Activator start error in bundle
com.elsten.bliss.bundle [31].
at org.apache.felix.framework.Felix.activateBundle(Felix.java:2027)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1895)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:931)
at
org.apache.felix.bundlerepository.impl.ResolverImpl.deploy(ResolverImpl.java:630)
at com.elsten.bliss.updater.OnlineUpdater$2.run(OnlineUpdater.java:62)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
Caused by: java.lang.ClassCastException:
com.elsten.bliss.music.policy2.PerFixLicensedPolicyCommandExecutor cannot
be cast to
com.elsten.bliss.music.policy2.PerFixLicensedPolicyCommandExecutor
at com.elsten.osgi.Activator.start(Activator.java:39)
at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:641)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1977)
... 8 more
I'll refer to com.elsten.bliss.bundle as .bundle
and com.elsten.bliss.platform as .platform from now...
What I don't understand is that the BundleEvents show that both bundles
went through the stop, update, start (only for .bundle to fail to start)
cycle. So I don't understand why .bundle would have a reference to an old
version of the class in .platform, thus causing the CCE.
If .platform did its own service registration I guess this wouldn't happen
because then there's no real wiring to do?
Dan
Re: Help me understand ClassCastException after update
Posted by "Richard S. Hall" <he...@ungoverned.org>.
When a bundle is stopped, it should stop all of its thread before
returning from stop()...even if those threads have been started by
libraries being used by the bundle and not the bundle directly.
-> richard
On 7/3/12 5:15, Dan Gravell wrote:
> Well that's interesting.
>
> I added a bundle listener before my deploy call, and also changed the
> deploy to run inside a thread. And now it works. Every time. I guess it's
> running it in a separate thread that works?
>
> I do still get these NPEs:
>
> Exception in thread "pool-66-thread-2" java.lang.NullPointerException
> at
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1432)
> at
> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
> at
> net.liftweb.actor.LAScheduler$$anonfun$9$$anon$2$$anon$3.run(LiftActor.scala:66)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> Exception in thread "pool-66-thread-4" java.lang.NullPointerException
> at
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1432)
> at
> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
> at
> net.liftweb.actor.LAScheduler$$anonfun$9$$anon$2$$anon$3.run(LiftActor.scala:66)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
>
> ... however I think they may be related to old threads from the closed-down
> old instance of the UI. They appear to be benign if unsightly.
>
> For the refresh call, I have written my BundleListener so that it counts up
> the Bundles that go into STOPPED state and then once each of them are
> STARTED again I run the refresh. I suppose another way of doing it would be
> to get the Requirements from the Resolver and wait for them to be UPDATED.
> The way I'm currently doing it may conflict if other bundles were being
> STARTED and STOPPED at the same time, but this is a simple,
> single-user-and-app environment rather than an app server or anything like
> that so I'm happy with that for now (unless anyone sees any obvious flaws
> I'm missing).
>
> Dan
>
> On Tue, Jul 3, 2012 at 9:17 AM, Dan Gravell
> <el...@googlemail.com>wrote:
>
>> Thanks for the offer Richard. I'm going to do some more digging on the
>> threading side of things, as you advised in your follow up. At the same
>> time I also discovered
>> http://blog.osgi.org/2007/07/best-practice-with-depressed-bundles.html last
>> night which made me think I need to think more about the threading going
>> on. There are a number of threads in my app including from the UI which the
>> source of the deploy() call. The UI is web based; the actual call comes
>> from a Scala actor (it's using the Lift framework).
>>
>> If I make no further progress I'll try to create a few bundle for you to
>> take a look at. Assume you need the source too...
>>
>> Dan
>>
>>
>> On Mon, Jul 2, 2012 at 8:46 PM, Richard S. Hall <he...@ungoverned.org>wrote:
>>
>>> Seems like this could take forever...perhaps you can create a scaled down
>>> example you can email me to reproduce the issue.
>>>
>>> -> richard
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Help me understand ClassCastException after update
Posted by Dan Gravell <el...@googlemail.com>.
Well that's interesting.
I added a bundle listener before my deploy call, and also changed the
deploy to run inside a thread. And now it works. Every time. I guess it's
running it in a separate thread that works?
I do still get these NPEs:
Exception in thread "pool-66-thread-2" java.lang.NullPointerException
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1432)
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
at
net.liftweb.actor.LAScheduler$$anonfun$9$$anon$2$$anon$3.run(LiftActor.scala:66)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
Exception in thread "pool-66-thread-4" java.lang.NullPointerException
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1432)
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
at
net.liftweb.actor.LAScheduler$$anonfun$9$$anon$2$$anon$3.run(LiftActor.scala:66)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
... however I think they may be related to old threads from the closed-down
old instance of the UI. They appear to be benign if unsightly.
For the refresh call, I have written my BundleListener so that it counts up
the Bundles that go into STOPPED state and then once each of them are
STARTED again I run the refresh. I suppose another way of doing it would be
to get the Requirements from the Resolver and wait for them to be UPDATED.
The way I'm currently doing it may conflict if other bundles were being
STARTED and STOPPED at the same time, but this is a simple,
single-user-and-app environment rather than an app server or anything like
that so I'm happy with that for now (unless anyone sees any obvious flaws
I'm missing).
Dan
On Tue, Jul 3, 2012 at 9:17 AM, Dan Gravell
<el...@googlemail.com>wrote:
> Thanks for the offer Richard. I'm going to do some more digging on the
> threading side of things, as you advised in your follow up. At the same
> time I also discovered
> http://blog.osgi.org/2007/07/best-practice-with-depressed-bundles.html last
> night which made me think I need to think more about the threading going
> on. There are a number of threads in my app including from the UI which the
> source of the deploy() call. The UI is web based; the actual call comes
> from a Scala actor (it's using the Lift framework).
>
> If I make no further progress I'll try to create a few bundle for you to
> take a look at. Assume you need the source too...
>
> Dan
>
>
> On Mon, Jul 2, 2012 at 8:46 PM, Richard S. Hall <he...@ungoverned.org>wrote:
>
>> Seems like this could take forever...perhaps you can create a scaled down
>> example you can email me to reproduce the issue.
>>
>> -> richard
>
>
Re: Help me understand ClassCastException after update
Posted by Dan Gravell <el...@googlemail.com>.
Thanks for the offer Richard. I'm going to do some more digging on the
threading side of things, as you advised in your follow up. At the same
time I also discovered
http://blog.osgi.org/2007/07/best-practice-with-depressed-bundles.html last
night which made me think I need to think more about the threading going
on. There are a number of threads in my app including from the UI which the
source of the deploy() call. The UI is web based; the actual call comes
from a Scala actor (it's using the Lift framework).
If I make no further progress I'll try to create a few bundle for you to
take a look at. Assume you need the source too...
Dan
On Mon, Jul 2, 2012 at 8:46 PM, Richard S. Hall <he...@ungoverned.org>wrote:
> Seems like this could take forever...perhaps you can create a scaled down
> example you can email me to reproduce the issue.
>
> -> richard
Re: Help me understand ClassCastException after update
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Seems like this could take forever...perhaps you can create a scaled
down example you can email me to reproduce the issue.
-> richard
On 7/2/12 12:07, Dan Gravell wrote:
> Oh I'm ~95% certain I'm doing something wrong ;) I haven't seen a
> walkthrough yet of writing this kind of code, so I've been going by the
> OSGi spec, Javadocs and piecing together other mailing list posts to try to
> work out what I need to call. Hence my other question about how update is
> "meant to be done" in multi bundle environments. Any link to non trivial
> examples are gratefully appreciated.
>
> Anyway, these errors appear before refreshBundles is called... they are as
> a result of the OBR deploy call.
>
> Although I refactored the updater into its own bundle, the update routine
> is being called from a bundle that is being updated, specifically the user
> interface where the user clicks 'Update'.
>
> The NPE stack trace shows the UI being used before update. The same thread
> from the old UI has updated the bundle and started the new bundle, but I
> guess that means the same classes for the old UI are being used, hence the
> casting problems?
>
> However, I can't *not* update the UI, it's a core part of my app that I
> want to update, but the UI has to be used to perform the update. How would
> one go about this?
>
> Apologies for such noob questions.
>
> Dan
>
> On Mon, Jul 2, 2012 at 4:45 PM, Richard S. Hall <he...@ungoverned.org>wrote:
>
>> I would venture to guess you are still doing something wrong...keep in
>> mind that the call to refreshBundles() is asynchronous, so you shouldn't
>> immediately try to start or do anything with your bundles. You need to give
>> a listener to refresh so you know when it is done.
>>
>> -> richard
>>
>>
>> On 7/2/12 11:35, Dan Gravell wrote:
>>
>>> So, I refactored the updater to a different bundle. Unfortunately I get
>>> the
>>> same problem. In two different runs I observed two different issues, one
>>> the CCE shown before, the other the LinkageError also shown before:
>>>
>>> ERROR: Resolver: Start error - com.elsten.bliss.bundle
>>> org.osgi.framework.**BundleException: Activator start error in bundle
>>> com.elsten.bliss.bundle [42].
>>> at org.apache.felix.framework.**Felix.activateBundle(Felix.**java:2027)
>>> at org.apache.felix.framework.**Felix.startBundle(Felix.java:**1895)
>>> at org.apache.felix.framework.**BundleImpl.start(BundleImpl.**java:944)
>>> at org.apache.felix.framework.**BundleImpl.start(BundleImpl.**java:931)
>>> at
>>> org.apache.felix.**bundlerepository.impl.**ResolverImpl.deploy(**
>>> ResolverImpl.java:630)
>>> at com.elsten.bliss.updater.**OnlineUpdater.updateTo(**
>>> OnlineUpdater.java:48)
>>> at com.elsten.bliss.ui.model.**Updater$.update(Updater.scala:**17)
>>> at
>>> com.elsten.bliss.ui.comet.**Update$$anonfun$lowPriority$1$**
>>> $anonfun$apply$1.apply$mcV$sp(**Update.scala:75)
>>> at
>>> com.elsten.bliss.ui.comet.**Update$$anonfun$lowPriority$1$**
>>> $anonfun$apply$2.apply$mcV$sp(**Update.scala:72)
>>> at
>>> com.elsten.bliss.ui.comet.**Update$$anonfun$lowPriority$1$**
>>> $anonfun$apply$2.apply(Update.**scala:72)
>>> at
>>> com.elsten.bliss.ui.comet.**Update$$anonfun$lowPriority$1$**
>>> $anonfun$apply$2.apply(Update.**scala:72)
>>> at
>>> scala.concurrent.ThreadRunner$**$anon$1$$anonfun$run$1.apply(**
>>> ThreadRunner.scala:37)
>>> at
>>> scala.concurrent.ThreadRunner.**scala$concurrent$ThreadRunner$**
>>> $tryCatch(ThreadRunner.scala:**31)
>>> at scala.concurrent.ThreadRunner$**$anon$1.run(ThreadRunner.**scala:37)
>>> at java.lang.Thread.run(Thread.**java:679)
>>> Caused by: java.lang.LinkageError: loader constraint violation: when
>>> resolving method
>>> "com.elsten.bliss.main.Main.**getLicenceStore()Lcom/elsten/**
>>> bliss/licence/**PerFixLicenceStore;"
>>> the class loader (instance of
>>> org/apache/felix/framework/**BundleWiringImpl$**BundleClassLoaderJava5)
>>> of the
>>> current class, com/elsten/osgi/Activator, and the class loader (instance
>>> of
>>> org/apache/felix/framework/**BundleWiringImpl$**BundleClassLoaderJava5)
>>> for
>>> resolved class, com/elsten/bliss/main/Main, have different Class objects
>>> for the type com/elsten/bliss/licence/**PerFixLicenceStore used in the
>>> signature
>>> at com.elsten.osgi.Activator.**start(Activator.java:38)
>>> at
>>> org.apache.felix.framework.**util.SecureAction.**
>>> startActivator(SecureAction.**java:641)
>>> at org.apache.felix.framework.**Felix.activateBundle(Felix.**java:1977)
>>> ... 14 more
>>>
>>> I also get this NPE just before which doesn't appear to be related to
>>> anything directly called by *me*:
>>>
>>> Exception in thread "pool-43-thread-5" java.lang.NullPointerException
>>> at
>>> org.apache.felix.framework.**BundleWiringImpl.**
>>> findClassOrResourceByDelegatio**n(BundleWiringImpl.java:1432)
>>> at
>>> org.apache.felix.framework.**BundleWiringImpl.access$400(**
>>> BundleWiringImpl.java:72)
>>> at
>>> org.apache.felix.framework.**BundleWiringImpl$**
>>> BundleClassLoader.loadClass(**BundleWiringImpl.java:1843)
>>> at java.lang.ClassLoader.**loadClass(ClassLoader.java:**266)
>>> at
>>> net.liftweb.actor.LAScheduler$**$anonfun$9$$anon$2$$anon$3.**
>>> run(LiftActor.scala:66)
>>> at
>>> java.util.concurrent.**ThreadPoolExecutor.runWorker(**
>>> ThreadPoolExecutor.java:1110)
>>> at
>>> java.util.concurrent.**ThreadPoolExecutor$Worker.run(**
>>> ThreadPoolExecutor.java:603)
>>> at java.lang.Thread.run(Thread.**java:679)
>>>
>>> I also observed my bundles being stopped and restarted several times after
>>> these problems arise.
>>>
>>> I'm beginning to wonder whether forcing a restart of the VM might be
>>> easier?
>>>
>>> Maybe the number of packages I have is too large, thereby making version
>>> clashes more likely?
>>>
>>> Dan
>>>
>>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@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: Help me understand ClassCastException after update
Posted by "Richard S. Hall" <he...@ungoverned.org>.
p.s. If I had to guess, I'd say that there are some threads that do not
get stopped when you stop your bundle for the update. If any threads
continue to run after a bundle's stop() method is called, then you can
have all sorts of fun.
On 7/2/12 12:07, Dan Gravell wrote:
> Oh I'm ~95% certain I'm doing something wrong ;) I haven't seen a
> walkthrough yet of writing this kind of code, so I've been going by the
> OSGi spec, Javadocs and piecing together other mailing list posts to try to
> work out what I need to call. Hence my other question about how update is
> "meant to be done" in multi bundle environments. Any link to non trivial
> examples are gratefully appreciated.
>
> Anyway, these errors appear before refreshBundles is called... they are as
> a result of the OBR deploy call.
>
> Although I refactored the updater into its own bundle, the update routine
> is being called from a bundle that is being updated, specifically the user
> interface where the user clicks 'Update'.
>
> The NPE stack trace shows the UI being used before update. The same thread
> from the old UI has updated the bundle and started the new bundle, but I
> guess that means the same classes for the old UI are being used, hence the
> casting problems?
>
> However, I can't *not* update the UI, it's a core part of my app that I
> want to update, but the UI has to be used to perform the update. How would
> one go about this?
>
> Apologies for such noob questions.
>
> Dan
>
> On Mon, Jul 2, 2012 at 4:45 PM, Richard S. Hall <he...@ungoverned.org>wrote:
>
>> I would venture to guess you are still doing something wrong...keep in
>> mind that the call to refreshBundles() is asynchronous, so you shouldn't
>> immediately try to start or do anything with your bundles. You need to give
>> a listener to refresh so you know when it is done.
>>
>> -> richard
>>
>>
>> On 7/2/12 11:35, Dan Gravell wrote:
>>
>>> So, I refactored the updater to a different bundle. Unfortunately I get
>>> the
>>> same problem. In two different runs I observed two different issues, one
>>> the CCE shown before, the other the LinkageError also shown before:
>>>
>>> ERROR: Resolver: Start error - com.elsten.bliss.bundle
>>> org.osgi.framework.**BundleException: Activator start error in bundle
>>> com.elsten.bliss.bundle [42].
>>> at org.apache.felix.framework.**Felix.activateBundle(Felix.**java:2027)
>>> at org.apache.felix.framework.**Felix.startBundle(Felix.java:**1895)
>>> at org.apache.felix.framework.**BundleImpl.start(BundleImpl.**java:944)
>>> at org.apache.felix.framework.**BundleImpl.start(BundleImpl.**java:931)
>>> at
>>> org.apache.felix.**bundlerepository.impl.**ResolverImpl.deploy(**
>>> ResolverImpl.java:630)
>>> at com.elsten.bliss.updater.**OnlineUpdater.updateTo(**
>>> OnlineUpdater.java:48)
>>> at com.elsten.bliss.ui.model.**Updater$.update(Updater.scala:**17)
>>> at
>>> com.elsten.bliss.ui.comet.**Update$$anonfun$lowPriority$1$**
>>> $anonfun$apply$1.apply$mcV$sp(**Update.scala:75)
>>> at
>>> com.elsten.bliss.ui.comet.**Update$$anonfun$lowPriority$1$**
>>> $anonfun$apply$2.apply$mcV$sp(**Update.scala:72)
>>> at
>>> com.elsten.bliss.ui.comet.**Update$$anonfun$lowPriority$1$**
>>> $anonfun$apply$2.apply(Update.**scala:72)
>>> at
>>> com.elsten.bliss.ui.comet.**Update$$anonfun$lowPriority$1$**
>>> $anonfun$apply$2.apply(Update.**scala:72)
>>> at
>>> scala.concurrent.ThreadRunner$**$anon$1$$anonfun$run$1.apply(**
>>> ThreadRunner.scala:37)
>>> at
>>> scala.concurrent.ThreadRunner.**scala$concurrent$ThreadRunner$**
>>> $tryCatch(ThreadRunner.scala:**31)
>>> at scala.concurrent.ThreadRunner$**$anon$1.run(ThreadRunner.**scala:37)
>>> at java.lang.Thread.run(Thread.**java:679)
>>> Caused by: java.lang.LinkageError: loader constraint violation: when
>>> resolving method
>>> "com.elsten.bliss.main.Main.**getLicenceStore()Lcom/elsten/**
>>> bliss/licence/**PerFixLicenceStore;"
>>> the class loader (instance of
>>> org/apache/felix/framework/**BundleWiringImpl$**BundleClassLoaderJava5)
>>> of the
>>> current class, com/elsten/osgi/Activator, and the class loader (instance
>>> of
>>> org/apache/felix/framework/**BundleWiringImpl$**BundleClassLoaderJava5)
>>> for
>>> resolved class, com/elsten/bliss/main/Main, have different Class objects
>>> for the type com/elsten/bliss/licence/**PerFixLicenceStore used in the
>>> signature
>>> at com.elsten.osgi.Activator.**start(Activator.java:38)
>>> at
>>> org.apache.felix.framework.**util.SecureAction.**
>>> startActivator(SecureAction.**java:641)
>>> at org.apache.felix.framework.**Felix.activateBundle(Felix.**java:1977)
>>> ... 14 more
>>>
>>> I also get this NPE just before which doesn't appear to be related to
>>> anything directly called by *me*:
>>>
>>> Exception in thread "pool-43-thread-5" java.lang.NullPointerException
>>> at
>>> org.apache.felix.framework.**BundleWiringImpl.**
>>> findClassOrResourceByDelegatio**n(BundleWiringImpl.java:1432)
>>> at
>>> org.apache.felix.framework.**BundleWiringImpl.access$400(**
>>> BundleWiringImpl.java:72)
>>> at
>>> org.apache.felix.framework.**BundleWiringImpl$**
>>> BundleClassLoader.loadClass(**BundleWiringImpl.java:1843)
>>> at java.lang.ClassLoader.**loadClass(ClassLoader.java:**266)
>>> at
>>> net.liftweb.actor.LAScheduler$**$anonfun$9$$anon$2$$anon$3.**
>>> run(LiftActor.scala:66)
>>> at
>>> java.util.concurrent.**ThreadPoolExecutor.runWorker(**
>>> ThreadPoolExecutor.java:1110)
>>> at
>>> java.util.concurrent.**ThreadPoolExecutor$Worker.run(**
>>> ThreadPoolExecutor.java:603)
>>> at java.lang.Thread.run(Thread.**java:679)
>>>
>>> I also observed my bundles being stopped and restarted several times after
>>> these problems arise.
>>>
>>> I'm beginning to wonder whether forcing a restart of the VM might be
>>> easier?
>>>
>>> Maybe the number of packages I have is too large, thereby making version
>>> clashes more likely?
>>>
>>> Dan
>>>
>>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@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: Help me understand ClassCastException after update
Posted by Dan Gravell <el...@googlemail.com>.
Oh I'm ~95% certain I'm doing something wrong ;) I haven't seen a
walkthrough yet of writing this kind of code, so I've been going by the
OSGi spec, Javadocs and piecing together other mailing list posts to try to
work out what I need to call. Hence my other question about how update is
"meant to be done" in multi bundle environments. Any link to non trivial
examples are gratefully appreciated.
Anyway, these errors appear before refreshBundles is called... they are as
a result of the OBR deploy call.
Although I refactored the updater into its own bundle, the update routine
is being called from a bundle that is being updated, specifically the user
interface where the user clicks 'Update'.
The NPE stack trace shows the UI being used before update. The same thread
from the old UI has updated the bundle and started the new bundle, but I
guess that means the same classes for the old UI are being used, hence the
casting problems?
However, I can't *not* update the UI, it's a core part of my app that I
want to update, but the UI has to be used to perform the update. How would
one go about this?
Apologies for such noob questions.
Dan
On Mon, Jul 2, 2012 at 4:45 PM, Richard S. Hall <he...@ungoverned.org>wrote:
> I would venture to guess you are still doing something wrong...keep in
> mind that the call to refreshBundles() is asynchronous, so you shouldn't
> immediately try to start or do anything with your bundles. You need to give
> a listener to refresh so you know when it is done.
>
> -> richard
>
>
> On 7/2/12 11:35, Dan Gravell wrote:
>
>> So, I refactored the updater to a different bundle. Unfortunately I get
>> the
>> same problem. In two different runs I observed two different issues, one
>> the CCE shown before, the other the LinkageError also shown before:
>>
>> ERROR: Resolver: Start error - com.elsten.bliss.bundle
>> org.osgi.framework.**BundleException: Activator start error in bundle
>> com.elsten.bliss.bundle [42].
>> at org.apache.felix.framework.**Felix.activateBundle(Felix.**java:2027)
>> at org.apache.felix.framework.**Felix.startBundle(Felix.java:**1895)
>> at org.apache.felix.framework.**BundleImpl.start(BundleImpl.**java:944)
>> at org.apache.felix.framework.**BundleImpl.start(BundleImpl.**java:931)
>> at
>> org.apache.felix.**bundlerepository.impl.**ResolverImpl.deploy(**
>> ResolverImpl.java:630)
>> at com.elsten.bliss.updater.**OnlineUpdater.updateTo(**
>> OnlineUpdater.java:48)
>> at com.elsten.bliss.ui.model.**Updater$.update(Updater.scala:**17)
>> at
>> com.elsten.bliss.ui.comet.**Update$$anonfun$lowPriority$1$**
>> $anonfun$apply$1.apply$mcV$sp(**Update.scala:75)
>> at
>> com.elsten.bliss.ui.comet.**Update$$anonfun$lowPriority$1$**
>> $anonfun$apply$2.apply$mcV$sp(**Update.scala:72)
>> at
>> com.elsten.bliss.ui.comet.**Update$$anonfun$lowPriority$1$**
>> $anonfun$apply$2.apply(Update.**scala:72)
>> at
>> com.elsten.bliss.ui.comet.**Update$$anonfun$lowPriority$1$**
>> $anonfun$apply$2.apply(Update.**scala:72)
>> at
>> scala.concurrent.ThreadRunner$**$anon$1$$anonfun$run$1.apply(**
>> ThreadRunner.scala:37)
>> at
>> scala.concurrent.ThreadRunner.**scala$concurrent$ThreadRunner$**
>> $tryCatch(ThreadRunner.scala:**31)
>> at scala.concurrent.ThreadRunner$**$anon$1.run(ThreadRunner.**scala:37)
>> at java.lang.Thread.run(Thread.**java:679)
>> Caused by: java.lang.LinkageError: loader constraint violation: when
>> resolving method
>> "com.elsten.bliss.main.Main.**getLicenceStore()Lcom/elsten/**
>> bliss/licence/**PerFixLicenceStore;"
>> the class loader (instance of
>> org/apache/felix/framework/**BundleWiringImpl$**BundleClassLoaderJava5)
>> of the
>> current class, com/elsten/osgi/Activator, and the class loader (instance
>> of
>> org/apache/felix/framework/**BundleWiringImpl$**BundleClassLoaderJava5)
>> for
>> resolved class, com/elsten/bliss/main/Main, have different Class objects
>> for the type com/elsten/bliss/licence/**PerFixLicenceStore used in the
>> signature
>> at com.elsten.osgi.Activator.**start(Activator.java:38)
>> at
>> org.apache.felix.framework.**util.SecureAction.**
>> startActivator(SecureAction.**java:641)
>> at org.apache.felix.framework.**Felix.activateBundle(Felix.**java:1977)
>> ... 14 more
>>
>> I also get this NPE just before which doesn't appear to be related to
>> anything directly called by *me*:
>>
>> Exception in thread "pool-43-thread-5" java.lang.NullPointerException
>> at
>> org.apache.felix.framework.**BundleWiringImpl.**
>> findClassOrResourceByDelegatio**n(BundleWiringImpl.java:1432)
>> at
>> org.apache.felix.framework.**BundleWiringImpl.access$400(**
>> BundleWiringImpl.java:72)
>> at
>> org.apache.felix.framework.**BundleWiringImpl$**
>> BundleClassLoader.loadClass(**BundleWiringImpl.java:1843)
>> at java.lang.ClassLoader.**loadClass(ClassLoader.java:**266)
>> at
>> net.liftweb.actor.LAScheduler$**$anonfun$9$$anon$2$$anon$3.**
>> run(LiftActor.scala:66)
>> at
>> java.util.concurrent.**ThreadPoolExecutor.runWorker(**
>> ThreadPoolExecutor.java:1110)
>> at
>> java.util.concurrent.**ThreadPoolExecutor$Worker.run(**
>> ThreadPoolExecutor.java:603)
>> at java.lang.Thread.run(Thread.**java:679)
>>
>> I also observed my bundles being stopped and restarted several times after
>> these problems arise.
>>
>> I'm beginning to wonder whether forcing a restart of the VM might be
>> easier?
>>
>> Maybe the number of packages I have is too large, thereby making version
>> clashes more likely?
>>
>> Dan
>>
>>
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Help me understand ClassCastException after update
Posted by "Richard S. Hall" <he...@ungoverned.org>.
I would venture to guess you are still doing something wrong...keep in
mind that the call to refreshBundles() is asynchronous, so you shouldn't
immediately try to start or do anything with your bundles. You need to
give a listener to refresh so you know when it is done.
-> richard
On 7/2/12 11:35, Dan Gravell wrote:
> So, I refactored the updater to a different bundle. Unfortunately I get the
> same problem. In two different runs I observed two different issues, one
> the CCE shown before, the other the LinkageError also shown before:
>
> ERROR: Resolver: Start error - com.elsten.bliss.bundle
> org.osgi.framework.BundleException: Activator start error in bundle
> com.elsten.bliss.bundle [42].
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:2027)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:1895)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:931)
> at
> org.apache.felix.bundlerepository.impl.ResolverImpl.deploy(ResolverImpl.java:630)
> at com.elsten.bliss.updater.OnlineUpdater.updateTo(OnlineUpdater.java:48)
> at com.elsten.bliss.ui.model.Updater$.update(Updater.scala:17)
> at
> com.elsten.bliss.ui.comet.Update$$anonfun$lowPriority$1$$anonfun$apply$1.apply$mcV$sp(Update.scala:75)
> at
> com.elsten.bliss.ui.comet.Update$$anonfun$lowPriority$1$$anonfun$apply$2.apply$mcV$sp(Update.scala:72)
> at
> com.elsten.bliss.ui.comet.Update$$anonfun$lowPriority$1$$anonfun$apply$2.apply(Update.scala:72)
> at
> com.elsten.bliss.ui.comet.Update$$anonfun$lowPriority$1$$anonfun$apply$2.apply(Update.scala:72)
> at
> scala.concurrent.ThreadRunner$$anon$1$$anonfun$run$1.apply(ThreadRunner.scala:37)
> at
> scala.concurrent.ThreadRunner.scala$concurrent$ThreadRunner$$tryCatch(ThreadRunner.scala:31)
> at scala.concurrent.ThreadRunner$$anon$1.run(ThreadRunner.scala:37)
> at java.lang.Thread.run(Thread.java:679)
> Caused by: java.lang.LinkageError: loader constraint violation: when
> resolving method
> "com.elsten.bliss.main.Main.getLicenceStore()Lcom/elsten/bliss/licence/PerFixLicenceStore;"
> the class loader (instance of
> org/apache/felix/framework/BundleWiringImpl$BundleClassLoaderJava5) of the
> current class, com/elsten/osgi/Activator, and the class loader (instance of
> org/apache/felix/framework/BundleWiringImpl$BundleClassLoaderJava5) for
> resolved class, com/elsten/bliss/main/Main, have different Class objects
> for the type com/elsten/bliss/licence/PerFixLicenceStore used in the
> signature
> at com.elsten.osgi.Activator.start(Activator.java:38)
> at
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:641)
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:1977)
> ... 14 more
>
> I also get this NPE just before which doesn't appear to be related to
> anything directly called by *me*:
>
> Exception in thread "pool-43-thread-5" java.lang.NullPointerException
> at
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1432)
> at
> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
> at
> net.liftweb.actor.LAScheduler$$anonfun$9$$anon$2$$anon$3.run(LiftActor.scala:66)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
>
> I also observed my bundles being stopped and restarted several times after
> these problems arise.
>
> I'm beginning to wonder whether forcing a restart of the VM might be easier?
>
> Maybe the number of packages I have is too large, thereby making version
> clashes more likely?
>
> Dan
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Help me understand ClassCastException after update
Posted by Dan Gravell <el...@googlemail.com>.
So, I refactored the updater to a different bundle. Unfortunately I get the
same problem. In two different runs I observed two different issues, one
the CCE shown before, the other the LinkageError also shown before:
ERROR: Resolver: Start error - com.elsten.bliss.bundle
org.osgi.framework.BundleException: Activator start error in bundle
com.elsten.bliss.bundle [42].
at org.apache.felix.framework.Felix.activateBundle(Felix.java:2027)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1895)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:931)
at
org.apache.felix.bundlerepository.impl.ResolverImpl.deploy(ResolverImpl.java:630)
at com.elsten.bliss.updater.OnlineUpdater.updateTo(OnlineUpdater.java:48)
at com.elsten.bliss.ui.model.Updater$.update(Updater.scala:17)
at
com.elsten.bliss.ui.comet.Update$$anonfun$lowPriority$1$$anonfun$apply$1.apply$mcV$sp(Update.scala:75)
at
com.elsten.bliss.ui.comet.Update$$anonfun$lowPriority$1$$anonfun$apply$2.apply$mcV$sp(Update.scala:72)
at
com.elsten.bliss.ui.comet.Update$$anonfun$lowPriority$1$$anonfun$apply$2.apply(Update.scala:72)
at
com.elsten.bliss.ui.comet.Update$$anonfun$lowPriority$1$$anonfun$apply$2.apply(Update.scala:72)
at
scala.concurrent.ThreadRunner$$anon$1$$anonfun$run$1.apply(ThreadRunner.scala:37)
at
scala.concurrent.ThreadRunner.scala$concurrent$ThreadRunner$$tryCatch(ThreadRunner.scala:31)
at scala.concurrent.ThreadRunner$$anon$1.run(ThreadRunner.scala:37)
at java.lang.Thread.run(Thread.java:679)
Caused by: java.lang.LinkageError: loader constraint violation: when
resolving method
"com.elsten.bliss.main.Main.getLicenceStore()Lcom/elsten/bliss/licence/PerFixLicenceStore;"
the class loader (instance of
org/apache/felix/framework/BundleWiringImpl$BundleClassLoaderJava5) of the
current class, com/elsten/osgi/Activator, and the class loader (instance of
org/apache/felix/framework/BundleWiringImpl$BundleClassLoaderJava5) for
resolved class, com/elsten/bliss/main/Main, have different Class objects
for the type com/elsten/bliss/licence/PerFixLicenceStore used in the
signature
at com.elsten.osgi.Activator.start(Activator.java:38)
at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:641)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1977)
... 14 more
I also get this NPE just before which doesn't appear to be related to
anything directly called by *me*:
Exception in thread "pool-43-thread-5" java.lang.NullPointerException
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1432)
at
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
at
net.liftweb.actor.LAScheduler$$anonfun$9$$anon$2$$anon$3.run(LiftActor.scala:66)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
I also observed my bundles being stopped and restarted several times after
these problems arise.
I'm beginning to wonder whether forcing a restart of the VM might be easier?
Maybe the number of packages I have is too large, thereby making version
clashes more likely?
Dan
Re: Help me understand ClassCastException after update
Posted by Dan Gravell <el...@googlemail.com>.
>
> Your code below is doing a "resolveBundles()", not "refreshBundles()"...
:-X
And yes, that's what I said below. You cannot do this code in the bundle
> being updated. You need to be doing it from a separate bundle that is NOT
> being updated.
> Bundles are not supposed to change their own state.
I'll factor this stuff out. My plan is to expose the ability to update my
app in a Service, which is then looked up in my UI. I'll create a separate
bundle purely for the updater which registers itself in its Activator upon
start.
Thanks for your time!
Dan
Re: Help me understand ClassCastException after update
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Your code below is doing a "resolveBundles()", not "refreshBundles()"...
-> richard
On 7/1/12 9:57, Dan Gravell wrote:
> Thanks. That makes sense, but the call to refresh via the 'context' occurs
> after the deploy, and so after where all the CCE and LinkageErrors occur. I
> just realised I hadn't pasted that stack trace yet...:
>
> ERROR: Resolver: Start error - com.elsten.bliss.bundle
> org.osgi.framework.BundleException: Activator start error in bundle
> com.elsten.bliss.bundle [42].
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:2027)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:1895)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:931)
> at
> org.apache.felix.bundlerepository.impl.ResolverImpl.deploy(ResolverImpl.java:630)
> at com.elsten.osgi.OnlineUpdater.updateTo(OnlineUpdater.java:48)
> [...]
> Caused by: java.lang.ClassCastException:
> com.elsten.bliss.music.policy2.PerFixLicensedPolicyCommandExecutor cannot
> be cast to
> com.elsten.bliss.music.policy2.PerFixLicensedPolicyCommandExecutor
> at com.elsten.osgi.Activator.start(Activator.java:42)
> at
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:641)
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:1977)
> ... 14 more
>
> Or is it also the case that the bundle cannot update (deploy) itself by
> running the update code within itself?
>
> Dan
>
> On Sun, Jul 1, 2012 at 2:50 PM, Richard S. Hall <he...@ungoverned.org>wrote:
>
>> On 7/1/12 9:38, Dan Gravell wrote:
>>
>>> Thanks Richard...
>>>
>>> On Sun, Jul 1, 2012 at 2:15 PM, Richard S. Hall <heavy@ungoverned.org
>>>> wrote:
>>> I have to imagine the simple solution for your scenario is to deploy your
>>>> client and your server (with OBR or not), then to perform a refresh
>>>> afterwards.
>>>>
>>>> ... but this is what I'm doing isn't it? Here's my actual code to
>>> deploy:
>>>
>>> final Resource bundleResource =
>>> FelixObrUtils.**getLatestBundleResource(**repoAdminSupplier);
>>> Resolver resolver = repoAdminSupplier.get().**resolver();
>>> resolver.add(bundleResource);
>>> if (resolver.resolve()) {
>>> listener.installBundleStart();
>>> resolver.deploy(Resolver.**START);
>>> // null to resolve all unresolved bundles
>>> context.getBundle(0).adapt(**FrameworkWiring.class).**
>>> resolveBundles(null);
>>> listener.**installBundleComplete();
>>> } else {
>>> // handling code...
>>> }
>>>
>>> FelixObrUtils.**getLatestBundleResource looks inside the RepositoryAdmin
>>> and
>>> returns the highest versioned Resource with the symbolic name
>>> "com.elsten.bliss.bundle". This is resolved (which should bring in the new
>>> dependencies) and then deployed.
>>>
>>> This code is itself running inside com.elsten.bliss.bundle.
>>>
>>> Thanks for the info about refreshing and the BundleContext. I always
>>> guessed that approach was a bit suspect. What is the correct way of
>>> retrieving the FrameworkWiring without the BundleContext?
>>>
>> For the above to work, the "context" must be from a bundle that hasn't
>> been updated. So, if you have three bundles: updater, client, and server.
>> And updater is doing the above code to update server and client, then it
>> should work.
>>
>> -> richard
>>
>>
>>> Dan
>>>
>>>
>>> If we release a modified version of OBR that automatically refreshes,
>>>> then
>>>> you shouldn't need to manually perform the refresh afterwards.
>>>>
>>>> -> richard
>>>>
>>>> I'm using OBR, and the Client is marked as
>>>>
>>>>> requiring a package on Server that was updated. Therefore I expected
>>>>> Server
>>>>> to be updated before Client (although this assumption might be wrong).
>>>>> In
>>>>> OBR API terms I am *only* calling deploy() on the Client BundleResource.
>>>>>
>>>>> The other, separate, package named 'server' within the Server bundle
>>>>> that
>>>>> contains type A was not updated and the requirement was not updated.
>>>>>
>>>>> When one package is updated but the other isn't within a bundle I
>>>>> assumed
>>>>> the classloader would be refreshed for the entire bundle, so affecting
>>>>> both
>>>>> packages, by virtue of the bundle being updated.
>>>>>
>>>>> So I ran an experiment. In bundle "Server", I updated the exported
>>>>> version
>>>>> of package "server". I then updated bundle "Server"'s version to ensure
>>>>> it
>>>>> would be updated. In "Client"'s manifest I changed the version
>>>>> requirement
>>>>> to reflect the new version of "server". I also updated "Client"'s
>>>>> version
>>>>> (although that uses the .qualifier PDE build approach, so a regeneration
>>>>> of
>>>>> the build script was all that was required).
>>>>>
>>>>> This time I get a different error message:
>>>>>
>>>>> ERROR: Resolver: Start error - com.elsten.bliss.bundle
>>>>> org.osgi.framework.****BundleException: Activator start error in
>>>>> bundle com.elsten.bliss.bundle [42].
>>>>> at org.apache.felix.framework.****Felix.activateBundle(Felix.****
>>>>> java:2027)
>>>>> at org.apache.felix.framework.****Felix.startBundle(Felix.java:***
>>>>> *1895)
>>>>> at org.apache.felix.framework.****BundleImpl.start(BundleImpl.****
>>>>> java:944)
>>>>> at org.apache.felix.framework.****BundleImpl.start(BundleImpl.****
>>>>> java:931)
>>>>> at
>>>>> org.apache.felix.****bundlerepository.impl.****ResolverImpl.deploy(**
>>>>>
>>>>> ResolverImpl.java:630)
>>>>> [...]
>>>>> Caused by: java.lang.LinkageError: loader constraint violation: when
>>>>> resolving method
>>>>> "com.elsten.bliss.main.Main.****getLicenceStore()Lcom/elsten/****
>>>>> bliss/licence/****PerFixLicenceStore;"
>>>>>
>>>>> the class loader (instance of
>>>>> org/apache/felix/framework/****BundleWiringImpl$****
>>>>> BundleClassLoaderJava5)
>>>>>
>>>>> of the
>>>>> current class, com/elsten/osgi/Activator, and the class loader (instance
>>>>> of
>>>>> org/apache/felix/framework/****BundleWiringImpl$****
>>>>> BundleClassLoaderJava5)
>>>>>
>>>>> for
>>>>> resolved class, com/elsten/bliss/main/Main, have different Class objects
>>>>> for the type com/elsten/bliss/licence/****PerFixLicenceStore used in
>>>>> the
>>>>> signature
>>>>> at com.elsten.osgi.Activator.****start(Activator.java:40)
>>>>> at
>>>>> org.apache.felix.framework.****util.SecureAction.**
>>>>> startActivator(SecureAction.****java:641)
>>>>> at org.apache.felix.framework.****Felix.activateBundle(Felix.****
>>>>> java:1977)
>>>>>
>>>>>
>>>>> This is a problem with a line preceeding the one that I originally had a
>>>>> problem for. But again, it's for a type in a package I didn't update,
>>>>> but
>>>>> within the bundle I did update.
>>>>>
>>>>> Apologies for my obfuscated bundle and package naming before. I should
>>>>> explain how the actual names in the output above map to what I've
>>>>> described
>>>>> so far:
>>>>>
>>>>> Bundle com.elsten.bliss.bundle (nee "Client") has packages:
>>>>> com.elsten.osgi [the actual name for the 'client' package. The package
>>>>> containing the Activator that runs a class in com.elsten.bliss.main and
>>>>> uses the result to register services]
>>>>>
>>>>> Bundle com.elsten.bliss.platform (nee "Server") has packages:
>>>>> com.elsten.bliss.main [the package containing the class that provides
>>>>> the
>>>>> services to 'client']
>>>>> com.elsten.bliss.licence [the package containing the type showing the
>>>>> new
>>>>> problem]
>>>>> com.elsten.bliss.music.policy2 [the actual name for the 'server'
>>>>> package]
>>>>>
>>>>> So then I updated com.elsten.bliss.licence's version, containing bundle
>>>>> version, import version, and containing bundle of the import's version.
>>>>> I
>>>>> ran the update again. This time there were no errors! Although refresh
>>>>> still failed:
>>>>>
>>>>> java.lang.****IllegalStateException: Invalid BundleContext.
>>>>> at
>>>>> org.apache.felix.framework.****BundleContextImpl.****checkValidity(**
>>>>> BundleContextImpl.java:514)
>>>>> at
>>>>> org.apache.felix.framework.****BundleContextImpl.getBundle(**
>>>>> BundleContextImpl.java:173)
>>>>> at com.elsten.osgi.OnlineUpdater.****updateTo(OnlineUpdater.java:**
>>>>> **51)
>>>>>
>>>>>
>>>>> This suggests the bundle did not restart. But I stopped the JVM and
>>>>> didn't
>>>>> note whether the application was still usable, so I ran the test again,
>>>>> removing felix-cache and performing the update against the same bundles.
>>>>> This time I get a *different* result:
>>>>>
>>>>> ERROR: Resolver: Start error - com.elsten.bliss.bundle
>>>>> org.osgi.framework.****BundleException: Uses constraint violation.
>>>>> Unable
>>>>>
>>>>> to
>>>>> resolve bundle revision com.elsten.bliss.platform [11.1] because it is
>>>>> exposed to package 'com.elsten.musicbrainz' from bundle revisions
>>>>> com.elsten.musicbrainz [30.1] and com.elsten.musicbrainz [30.0] via two
>>>>> dependency chains.
>>>>>
>>>>> Chain 1:
>>>>> com.elsten.bliss.platform [11.1]
>>>>> import: (&(osgi.wiring.package=com.****
>>>>> elsten.musicbrainz)(version>=****
>>>>> 1.0.2))
>>>>> |
>>>>> export: osgi.wiring.package=com.****elsten.musicbrainz
>>>>>
>>>>> com.elsten.musicbrainz [30.1]
>>>>>
>>>>> Chain 2:
>>>>> com.elsten.bliss.platform [11.1]
>>>>> import:
>>>>> (&(osgi.wiring.package=com.****elsten.musicbrainz.model)(****
>>>>> version>=1.0.1))
>>>>> |
>>>>> export: osgi.wiring.package=com.****elsten.musicbrainz.model;
>>>>> uses:=com.elsten.musicbrainz
>>>>> export: osgi.wiring.package=com.****elsten.musicbrainz
>>>>> com.elsten.musicbrainz [30.0]
>>>>> at org.apache.felix.framework.****Felix.resolveBundleRevision(**
>>>>> Felix.java:3832)
>>>>> at org.apache.felix.framework.****Felix.startBundle(Felix.java:***
>>>>> *1868)
>>>>> at org.apache.felix.framework.****BundleImpl.start(BundleImpl.****
>>>>> java:944)
>>>>> at org.apache.felix.framework.****BundleImpl.start(BundleImpl.****
>>>>> java:931)
>>>>> at
>>>>> org.apache.felix.****bundlerepository.impl.****ResolverImpl.deploy(**
>>>>>
>>>>> ResolverImpl.java:630)
>>>>>
>>>>> Crap. So now I am getting different errors on different invocations too.
>>>>> Maybe it was a timing issue - on the re-run I probably ran the update
>>>>> sooner after starting. These "Uses constraint violation"s are normally
>>>>> fixed by package versioning, or so I thought, but in this case all
>>>>> versions
>>>>> of these bundles dictate package versions. So I don't know where to go
>>>>> from
>>>>> there.
>>>>>
>>>>> I'm also beginning to think using Require-Bundle may be better for my
>>>>> sanity, assuming it allows coarser grained control of versioning.
>>>>>
>>>>> Serves me right for working on a Sunday I suppose.
>>>>>
>>>>> Dan
>>>>>
>>>>> On Sat, Jun 30, 2012 at 5:46 PM, Richard S. Hall <heavy@ungoverned.org
>>>>>
>>>>>> wrote:
>>>>>>
>>>>> Updating the service doesn't completely get rid of its old exports,
>>>>> you
>>>>>
>>>>>> need to refresh it to do that. Most likely if you updated the client
>>>>>> first,
>>>>>> then it gets wired to the old export and stays that way after you
>>>>>> update
>>>>>> the server. Regardless, if you want to make sure you don't have any old
>>>>>> "stale" versions causing you confusion, you have to do a "refresh"
>>>>>> after
>>>>>> a
>>>>>> series of updates and uninstalls.
>>>>>>
>>>>>> -> richard
>>>>>>
>>>>>>
>>>>>> On 6/30/12 12:09, Dan Gravell wrote:
>>>>>>
>>>>>> My OSGi adventure continues...
>>>>>>
>>>>>>> I have a bundle "Client" and bundle "Server". In Client's activator it
>>>>>>> invokes code in Server, returning an object from Server, let's call it
>>>>>>> server.A. A is defined in Server. Client then registers A as a
>>>>>>> service:
>>>>>>>
>>>>>>> context.registerService(A.******class, (A) serverClass.getA(), new
>>>>>>>
>>>>>>>
>>>>>>> Hashtable());
>>>>>>>
>>>>>>> This works when it is first run.
>>>>>>>
>>>>>>> If I then update Client and Server bundles, the Client Activator gets
>>>>>>> run
>>>>>>> again. This time I get a ClassCastException saying "server.A cannot be
>>>>>>> cast
>>>>>>> to server.A".
>>>>>>>
>>>>>>> So I guess the classloaders are different for the A that is returned
>>>>>>> by
>>>>>>> Server to the one Client sees. Given both bundles were updated at the
>>>>>>> same
>>>>>>> time, why is this?
>>>>>>>
>>>>>>> I make use of package versioning, if this is important. A's package,
>>>>>>> server, was not updated, and its version was not incremented. Was the
>>>>>>> code
>>>>>>> in Client using the old version of server.A?
>>>>>>>
>>>>>>> I guess registering A as a service in Client, rather than Server, is
>>>>>>> opposed to most sample code I see but is it the cause of the problem?
>>>>>>> If
>>>>>>> classloaders work on a per package level then it won't help will it?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Dan
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------******--------------------------**
>>>>>>> --**
>>>>>>>
>>>>>> --**---------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.****apac**he.org<
>>>>>> http://apache.org**>
>>>>>> <users-unsubscribe@**felix.**apache.org <http://felix.apache.org><
>>>>>> users-unsubscribe@**felix.apache.org<us...@felix.apache.org>
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> ------------------------------****----------------------------**
>>>> --**---------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.**apac**he.org<http://apache.org>
>>>> <us...@felix.apache.org>
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@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: Help me understand ClassCastException after update
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 7/1/12 9:57, Dan Gravell wrote:
>
> Or is it also the case that the bundle cannot update (deploy) itself by
> running the update code within itself?
And yes, that's what I said below. You cannot do this code in the bundle
being updated. You need to be doing it from a separate bundle that is
NOT being updated.
Bundles are not supposed to change their own state.
-> richard
>
> Dan
>
> On Sun, Jul 1, 2012 at 2:50 PM, Richard S. Hall <he...@ungoverned.org>wrote:
>
>> On 7/1/12 9:38, Dan Gravell wrote:
>>
>>> Thanks Richard...
>>>
>>> On Sun, Jul 1, 2012 at 2:15 PM, Richard S. Hall <heavy@ungoverned.org
>>>> wrote:
>>> I have to imagine the simple solution for your scenario is to deploy your
>>>> client and your server (with OBR or not), then to perform a refresh
>>>> afterwards.
>>>>
>>>> ... but this is what I'm doing isn't it? Here's my actual code to
>>> deploy:
>>>
>>> final Resource bundleResource =
>>> FelixObrUtils.**getLatestBundleResource(**repoAdminSupplier);
>>> Resolver resolver = repoAdminSupplier.get().**resolver();
>>> resolver.add(bundleResource);
>>> if (resolver.resolve()) {
>>> listener.installBundleStart();
>>> resolver.deploy(Resolver.**START);
>>> // null to resolve all unresolved bundles
>>> context.getBundle(0).adapt(**FrameworkWiring.class).**
>>> resolveBundles(null);
>>> listener.**installBundleComplete();
>>> } else {
>>> // handling code...
>>> }
>>>
>>> FelixObrUtils.**getLatestBundleResource looks inside the RepositoryAdmin
>>> and
>>> returns the highest versioned Resource with the symbolic name
>>> "com.elsten.bliss.bundle". This is resolved (which should bring in the new
>>> dependencies) and then deployed.
>>>
>>> This code is itself running inside com.elsten.bliss.bundle.
>>>
>>> Thanks for the info about refreshing and the BundleContext. I always
>>> guessed that approach was a bit suspect. What is the correct way of
>>> retrieving the FrameworkWiring without the BundleContext?
>>>
>> For the above to work, the "context" must be from a bundle that hasn't
>> been updated. So, if you have three bundles: updater, client, and server.
>> And updater is doing the above code to update server and client, then it
>> should work.
>>
>> -> richard
>>
>>
>>> Dan
>>>
>>>
>>> If we release a modified version of OBR that automatically refreshes,
>>>> then
>>>> you shouldn't need to manually perform the refresh afterwards.
>>>>
>>>> -> richard
>>>>
>>>> I'm using OBR, and the Client is marked as
>>>>
>>>>> requiring a package on Server that was updated. Therefore I expected
>>>>> Server
>>>>> to be updated before Client (although this assumption might be wrong).
>>>>> In
>>>>> OBR API terms I am *only* calling deploy() on the Client BundleResource.
>>>>>
>>>>> The other, separate, package named 'server' within the Server bundle
>>>>> that
>>>>> contains type A was not updated and the requirement was not updated.
>>>>>
>>>>> When one package is updated but the other isn't within a bundle I
>>>>> assumed
>>>>> the classloader would be refreshed for the entire bundle, so affecting
>>>>> both
>>>>> packages, by virtue of the bundle being updated.
>>>>>
>>>>> So I ran an experiment. In bundle "Server", I updated the exported
>>>>> version
>>>>> of package "server". I then updated bundle "Server"'s version to ensure
>>>>> it
>>>>> would be updated. In "Client"'s manifest I changed the version
>>>>> requirement
>>>>> to reflect the new version of "server". I also updated "Client"'s
>>>>> version
>>>>> (although that uses the .qualifier PDE build approach, so a regeneration
>>>>> of
>>>>> the build script was all that was required).
>>>>>
>>>>> This time I get a different error message:
>>>>>
>>>>> ERROR: Resolver: Start error - com.elsten.bliss.bundle
>>>>> org.osgi.framework.****BundleException: Activator start error in
>>>>> bundle com.elsten.bliss.bundle [42].
>>>>> at org.apache.felix.framework.****Felix.activateBundle(Felix.****
>>>>> java:2027)
>>>>> at org.apache.felix.framework.****Felix.startBundle(Felix.java:***
>>>>> *1895)
>>>>> at org.apache.felix.framework.****BundleImpl.start(BundleImpl.****
>>>>> java:944)
>>>>> at org.apache.felix.framework.****BundleImpl.start(BundleImpl.****
>>>>> java:931)
>>>>> at
>>>>> org.apache.felix.****bundlerepository.impl.****ResolverImpl.deploy(**
>>>>>
>>>>> ResolverImpl.java:630)
>>>>> [...]
>>>>> Caused by: java.lang.LinkageError: loader constraint violation: when
>>>>> resolving method
>>>>> "com.elsten.bliss.main.Main.****getLicenceStore()Lcom/elsten/****
>>>>> bliss/licence/****PerFixLicenceStore;"
>>>>>
>>>>> the class loader (instance of
>>>>> org/apache/felix/framework/****BundleWiringImpl$****
>>>>> BundleClassLoaderJava5)
>>>>>
>>>>> of the
>>>>> current class, com/elsten/osgi/Activator, and the class loader (instance
>>>>> of
>>>>> org/apache/felix/framework/****BundleWiringImpl$****
>>>>> BundleClassLoaderJava5)
>>>>>
>>>>> for
>>>>> resolved class, com/elsten/bliss/main/Main, have different Class objects
>>>>> for the type com/elsten/bliss/licence/****PerFixLicenceStore used in
>>>>> the
>>>>> signature
>>>>> at com.elsten.osgi.Activator.****start(Activator.java:40)
>>>>> at
>>>>> org.apache.felix.framework.****util.SecureAction.**
>>>>> startActivator(SecureAction.****java:641)
>>>>> at org.apache.felix.framework.****Felix.activateBundle(Felix.****
>>>>> java:1977)
>>>>>
>>>>>
>>>>> This is a problem with a line preceeding the one that I originally had a
>>>>> problem for. But again, it's for a type in a package I didn't update,
>>>>> but
>>>>> within the bundle I did update.
>>>>>
>>>>> Apologies for my obfuscated bundle and package naming before. I should
>>>>> explain how the actual names in the output above map to what I've
>>>>> described
>>>>> so far:
>>>>>
>>>>> Bundle com.elsten.bliss.bundle (nee "Client") has packages:
>>>>> com.elsten.osgi [the actual name for the 'client' package. The package
>>>>> containing the Activator that runs a class in com.elsten.bliss.main and
>>>>> uses the result to register services]
>>>>>
>>>>> Bundle com.elsten.bliss.platform (nee "Server") has packages:
>>>>> com.elsten.bliss.main [the package containing the class that provides
>>>>> the
>>>>> services to 'client']
>>>>> com.elsten.bliss.licence [the package containing the type showing the
>>>>> new
>>>>> problem]
>>>>> com.elsten.bliss.music.policy2 [the actual name for the 'server'
>>>>> package]
>>>>>
>>>>> So then I updated com.elsten.bliss.licence's version, containing bundle
>>>>> version, import version, and containing bundle of the import's version.
>>>>> I
>>>>> ran the update again. This time there were no errors! Although refresh
>>>>> still failed:
>>>>>
>>>>> java.lang.****IllegalStateException: Invalid BundleContext.
>>>>> at
>>>>> org.apache.felix.framework.****BundleContextImpl.****checkValidity(**
>>>>> BundleContextImpl.java:514)
>>>>> at
>>>>> org.apache.felix.framework.****BundleContextImpl.getBundle(**
>>>>> BundleContextImpl.java:173)
>>>>> at com.elsten.osgi.OnlineUpdater.****updateTo(OnlineUpdater.java:**
>>>>> **51)
>>>>>
>>>>>
>>>>> This suggests the bundle did not restart. But I stopped the JVM and
>>>>> didn't
>>>>> note whether the application was still usable, so I ran the test again,
>>>>> removing felix-cache and performing the update against the same bundles.
>>>>> This time I get a *different* result:
>>>>>
>>>>> ERROR: Resolver: Start error - com.elsten.bliss.bundle
>>>>> org.osgi.framework.****BundleException: Uses constraint violation.
>>>>> Unable
>>>>>
>>>>> to
>>>>> resolve bundle revision com.elsten.bliss.platform [11.1] because it is
>>>>> exposed to package 'com.elsten.musicbrainz' from bundle revisions
>>>>> com.elsten.musicbrainz [30.1] and com.elsten.musicbrainz [30.0] via two
>>>>> dependency chains.
>>>>>
>>>>> Chain 1:
>>>>> com.elsten.bliss.platform [11.1]
>>>>> import: (&(osgi.wiring.package=com.****
>>>>> elsten.musicbrainz)(version>=****
>>>>> 1.0.2))
>>>>> |
>>>>> export: osgi.wiring.package=com.****elsten.musicbrainz
>>>>>
>>>>> com.elsten.musicbrainz [30.1]
>>>>>
>>>>> Chain 2:
>>>>> com.elsten.bliss.platform [11.1]
>>>>> import:
>>>>> (&(osgi.wiring.package=com.****elsten.musicbrainz.model)(****
>>>>> version>=1.0.1))
>>>>> |
>>>>> export: osgi.wiring.package=com.****elsten.musicbrainz.model;
>>>>> uses:=com.elsten.musicbrainz
>>>>> export: osgi.wiring.package=com.****elsten.musicbrainz
>>>>> com.elsten.musicbrainz [30.0]
>>>>> at org.apache.felix.framework.****Felix.resolveBundleRevision(**
>>>>> Felix.java:3832)
>>>>> at org.apache.felix.framework.****Felix.startBundle(Felix.java:***
>>>>> *1868)
>>>>> at org.apache.felix.framework.****BundleImpl.start(BundleImpl.****
>>>>> java:944)
>>>>> at org.apache.felix.framework.****BundleImpl.start(BundleImpl.****
>>>>> java:931)
>>>>> at
>>>>> org.apache.felix.****bundlerepository.impl.****ResolverImpl.deploy(**
>>>>>
>>>>> ResolverImpl.java:630)
>>>>>
>>>>> Crap. So now I am getting different errors on different invocations too.
>>>>> Maybe it was a timing issue - on the re-run I probably ran the update
>>>>> sooner after starting. These "Uses constraint violation"s are normally
>>>>> fixed by package versioning, or so I thought, but in this case all
>>>>> versions
>>>>> of these bundles dictate package versions. So I don't know where to go
>>>>> from
>>>>> there.
>>>>>
>>>>> I'm also beginning to think using Require-Bundle may be better for my
>>>>> sanity, assuming it allows coarser grained control of versioning.
>>>>>
>>>>> Serves me right for working on a Sunday I suppose.
>>>>>
>>>>> Dan
>>>>>
>>>>> On Sat, Jun 30, 2012 at 5:46 PM, Richard S. Hall <heavy@ungoverned.org
>>>>>
>>>>>> wrote:
>>>>>>
>>>>> Updating the service doesn't completely get rid of its old exports,
>>>>> you
>>>>>
>>>>>> need to refresh it to do that. Most likely if you updated the client
>>>>>> first,
>>>>>> then it gets wired to the old export and stays that way after you
>>>>>> update
>>>>>> the server. Regardless, if you want to make sure you don't have any old
>>>>>> "stale" versions causing you confusion, you have to do a "refresh"
>>>>>> after
>>>>>> a
>>>>>> series of updates and uninstalls.
>>>>>>
>>>>>> -> richard
>>>>>>
>>>>>>
>>>>>> On 6/30/12 12:09, Dan Gravell wrote:
>>>>>>
>>>>>> My OSGi adventure continues...
>>>>>>
>>>>>>> I have a bundle "Client" and bundle "Server". In Client's activator it
>>>>>>> invokes code in Server, returning an object from Server, let's call it
>>>>>>> server.A. A is defined in Server. Client then registers A as a
>>>>>>> service:
>>>>>>>
>>>>>>> context.registerService(A.******class, (A) serverClass.getA(), new
>>>>>>>
>>>>>>>
>>>>>>> Hashtable());
>>>>>>>
>>>>>>> This works when it is first run.
>>>>>>>
>>>>>>> If I then update Client and Server bundles, the Client Activator gets
>>>>>>> run
>>>>>>> again. This time I get a ClassCastException saying "server.A cannot be
>>>>>>> cast
>>>>>>> to server.A".
>>>>>>>
>>>>>>> So I guess the classloaders are different for the A that is returned
>>>>>>> by
>>>>>>> Server to the one Client sees. Given both bundles were updated at the
>>>>>>> same
>>>>>>> time, why is this?
>>>>>>>
>>>>>>> I make use of package versioning, if this is important. A's package,
>>>>>>> server, was not updated, and its version was not incremented. Was the
>>>>>>> code
>>>>>>> in Client using the old version of server.A?
>>>>>>>
>>>>>>> I guess registering A as a service in Client, rather than Server, is
>>>>>>> opposed to most sample code I see but is it the cause of the problem?
>>>>>>> If
>>>>>>> classloaders work on a per package level then it won't help will it?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Dan
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------******--------------------------**
>>>>>>> --**
>>>>>>>
>>>>>> --**---------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.****apac**he.org<
>>>>>> http://apache.org**>
>>>>>> <users-unsubscribe@**felix.**apache.org <http://felix.apache.org><
>>>>>> users-unsubscribe@**felix.apache.org<us...@felix.apache.org>
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> ------------------------------****----------------------------**
>>>> --**---------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.**apac**he.org<http://apache.org>
>>>> <us...@felix.apache.org>
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@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: Help me understand ClassCastException after update
Posted by Dan Gravell <el...@googlemail.com>.
Thanks. That makes sense, but the call to refresh via the 'context' occurs
after the deploy, and so after where all the CCE and LinkageErrors occur. I
just realised I hadn't pasted that stack trace yet...:
ERROR: Resolver: Start error - com.elsten.bliss.bundle
org.osgi.framework.BundleException: Activator start error in bundle
com.elsten.bliss.bundle [42].
at org.apache.felix.framework.Felix.activateBundle(Felix.java:2027)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1895)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:931)
at
org.apache.felix.bundlerepository.impl.ResolverImpl.deploy(ResolverImpl.java:630)
at com.elsten.osgi.OnlineUpdater.updateTo(OnlineUpdater.java:48)
[...]
Caused by: java.lang.ClassCastException:
com.elsten.bliss.music.policy2.PerFixLicensedPolicyCommandExecutor cannot
be cast to
com.elsten.bliss.music.policy2.PerFixLicensedPolicyCommandExecutor
at com.elsten.osgi.Activator.start(Activator.java:42)
at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:641)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1977)
... 14 more
Or is it also the case that the bundle cannot update (deploy) itself by
running the update code within itself?
Dan
On Sun, Jul 1, 2012 at 2:50 PM, Richard S. Hall <he...@ungoverned.org>wrote:
>
> On 7/1/12 9:38, Dan Gravell wrote:
>
>> Thanks Richard...
>>
>> On Sun, Jul 1, 2012 at 2:15 PM, Richard S. Hall <heavy@ungoverned.org
>> >wrote:
>>
>> I have to imagine the simple solution for your scenario is to deploy your
>>> client and your server (with OBR or not), then to perform a refresh
>>> afterwards.
>>>
>>> ... but this is what I'm doing isn't it? Here's my actual code to
>> deploy:
>>
>> final Resource bundleResource =
>> FelixObrUtils.**getLatestBundleResource(**repoAdminSupplier);
>> Resolver resolver = repoAdminSupplier.get().**resolver();
>> resolver.add(bundleResource);
>> if (resolver.resolve()) {
>> listener.installBundleStart();
>> resolver.deploy(Resolver.**START);
>> // null to resolve all unresolved bundles
>> context.getBundle(0).adapt(**FrameworkWiring.class).**
>> resolveBundles(null);
>> listener.**installBundleComplete();
>> } else {
>> // handling code...
>> }
>>
>> FelixObrUtils.**getLatestBundleResource looks inside the RepositoryAdmin
>> and
>> returns the highest versioned Resource with the symbolic name
>> "com.elsten.bliss.bundle". This is resolved (which should bring in the new
>> dependencies) and then deployed.
>>
>> This code is itself running inside com.elsten.bliss.bundle.
>>
>> Thanks for the info about refreshing and the BundleContext. I always
>> guessed that approach was a bit suspect. What is the correct way of
>> retrieving the FrameworkWiring without the BundleContext?
>>
>
> For the above to work, the "context" must be from a bundle that hasn't
> been updated. So, if you have three bundles: updater, client, and server.
> And updater is doing the above code to update server and client, then it
> should work.
>
> -> richard
>
>
>> Dan
>>
>>
>> If we release a modified version of OBR that automatically refreshes,
>>> then
>>> you shouldn't need to manually perform the refresh afterwards.
>>>
>>> -> richard
>>>
>>> I'm using OBR, and the Client is marked as
>>>
>>>> requiring a package on Server that was updated. Therefore I expected
>>>> Server
>>>> to be updated before Client (although this assumption might be wrong).
>>>> In
>>>> OBR API terms I am *only* calling deploy() on the Client BundleResource.
>>>>
>>>> The other, separate, package named 'server' within the Server bundle
>>>> that
>>>> contains type A was not updated and the requirement was not updated.
>>>>
>>>> When one package is updated but the other isn't within a bundle I
>>>> assumed
>>>> the classloader would be refreshed for the entire bundle, so affecting
>>>> both
>>>> packages, by virtue of the bundle being updated.
>>>>
>>>> So I ran an experiment. In bundle "Server", I updated the exported
>>>> version
>>>> of package "server". I then updated bundle "Server"'s version to ensure
>>>> it
>>>> would be updated. In "Client"'s manifest I changed the version
>>>> requirement
>>>> to reflect the new version of "server". I also updated "Client"'s
>>>> version
>>>> (although that uses the .qualifier PDE build approach, so a regeneration
>>>> of
>>>> the build script was all that was required).
>>>>
>>>> This time I get a different error message:
>>>>
>>>> ERROR: Resolver: Start error - com.elsten.bliss.bundle
>>>> org.osgi.framework.****BundleException: Activator start error in
>>>> bundle com.elsten.bliss.bundle [42].
>>>> at org.apache.felix.framework.****Felix.activateBundle(Felix.****
>>>> java:2027)
>>>> at org.apache.felix.framework.****Felix.startBundle(Felix.java:***
>>>> *1895)
>>>> at org.apache.felix.framework.****BundleImpl.start(BundleImpl.****
>>>> java:944)
>>>> at org.apache.felix.framework.****BundleImpl.start(BundleImpl.****
>>>> java:931)
>>>> at
>>>> org.apache.felix.****bundlerepository.impl.****ResolverImpl.deploy(**
>>>>
>>>> ResolverImpl.java:630)
>>>> [...]
>>>> Caused by: java.lang.LinkageError: loader constraint violation: when
>>>> resolving method
>>>> "com.elsten.bliss.main.Main.****getLicenceStore()Lcom/elsten/****
>>>> bliss/licence/****PerFixLicenceStore;"
>>>>
>>>> the class loader (instance of
>>>> org/apache/felix/framework/****BundleWiringImpl$****
>>>> BundleClassLoaderJava5)
>>>>
>>>> of the
>>>> current class, com/elsten/osgi/Activator, and the class loader (instance
>>>> of
>>>> org/apache/felix/framework/****BundleWiringImpl$****
>>>> BundleClassLoaderJava5)
>>>>
>>>> for
>>>> resolved class, com/elsten/bliss/main/Main, have different Class objects
>>>> for the type com/elsten/bliss/licence/****PerFixLicenceStore used in
>>>> the
>>>> signature
>>>> at com.elsten.osgi.Activator.****start(Activator.java:40)
>>>> at
>>>> org.apache.felix.framework.****util.SecureAction.**
>>>> startActivator(SecureAction.****java:641)
>>>> at org.apache.felix.framework.****Felix.activateBundle(Felix.****
>>>> java:1977)
>>>>
>>>>
>>>> This is a problem with a line preceeding the one that I originally had a
>>>> problem for. But again, it's for a type in a package I didn't update,
>>>> but
>>>> within the bundle I did update.
>>>>
>>>> Apologies for my obfuscated bundle and package naming before. I should
>>>> explain how the actual names in the output above map to what I've
>>>> described
>>>> so far:
>>>>
>>>> Bundle com.elsten.bliss.bundle (nee "Client") has packages:
>>>> com.elsten.osgi [the actual name for the 'client' package. The package
>>>> containing the Activator that runs a class in com.elsten.bliss.main and
>>>> uses the result to register services]
>>>>
>>>> Bundle com.elsten.bliss.platform (nee "Server") has packages:
>>>> com.elsten.bliss.main [the package containing the class that provides
>>>> the
>>>> services to 'client']
>>>> com.elsten.bliss.licence [the package containing the type showing the
>>>> new
>>>> problem]
>>>> com.elsten.bliss.music.policy2 [the actual name for the 'server'
>>>> package]
>>>>
>>>> So then I updated com.elsten.bliss.licence's version, containing bundle
>>>> version, import version, and containing bundle of the import's version.
>>>> I
>>>> ran the update again. This time there were no errors! Although refresh
>>>> still failed:
>>>>
>>>> java.lang.****IllegalStateException: Invalid BundleContext.
>>>> at
>>>> org.apache.felix.framework.****BundleContextImpl.****checkValidity(**
>>>> BundleContextImpl.java:514)
>>>> at
>>>> org.apache.felix.framework.****BundleContextImpl.getBundle(**
>>>> BundleContextImpl.java:173)
>>>> at com.elsten.osgi.OnlineUpdater.****updateTo(OnlineUpdater.java:**
>>>> **51)
>>>>
>>>>
>>>> This suggests the bundle did not restart. But I stopped the JVM and
>>>> didn't
>>>> note whether the application was still usable, so I ran the test again,
>>>> removing felix-cache and performing the update against the same bundles.
>>>> This time I get a *different* result:
>>>>
>>>> ERROR: Resolver: Start error - com.elsten.bliss.bundle
>>>> org.osgi.framework.****BundleException: Uses constraint violation.
>>>> Unable
>>>>
>>>> to
>>>> resolve bundle revision com.elsten.bliss.platform [11.1] because it is
>>>> exposed to package 'com.elsten.musicbrainz' from bundle revisions
>>>> com.elsten.musicbrainz [30.1] and com.elsten.musicbrainz [30.0] via two
>>>> dependency chains.
>>>>
>>>> Chain 1:
>>>> com.elsten.bliss.platform [11.1]
>>>> import: (&(osgi.wiring.package=com.****
>>>> elsten.musicbrainz)(version>=****
>>>> 1.0.2))
>>>> |
>>>> export: osgi.wiring.package=com.****elsten.musicbrainz
>>>>
>>>> com.elsten.musicbrainz [30.1]
>>>>
>>>> Chain 2:
>>>> com.elsten.bliss.platform [11.1]
>>>> import:
>>>> (&(osgi.wiring.package=com.****elsten.musicbrainz.model)(****
>>>> version>=1.0.1))
>>>> |
>>>> export: osgi.wiring.package=com.****elsten.musicbrainz.model;
>>>> uses:=com.elsten.musicbrainz
>>>> export: osgi.wiring.package=com.****elsten.musicbrainz
>>>> com.elsten.musicbrainz [30.0]
>>>> at org.apache.felix.framework.****Felix.resolveBundleRevision(**
>>>> Felix.java:3832)
>>>> at org.apache.felix.framework.****Felix.startBundle(Felix.java:***
>>>> *1868)
>>>> at org.apache.felix.framework.****BundleImpl.start(BundleImpl.****
>>>> java:944)
>>>> at org.apache.felix.framework.****BundleImpl.start(BundleImpl.****
>>>> java:931)
>>>> at
>>>> org.apache.felix.****bundlerepository.impl.****ResolverImpl.deploy(**
>>>>
>>>> ResolverImpl.java:630)
>>>>
>>>> Crap. So now I am getting different errors on different invocations too.
>>>> Maybe it was a timing issue - on the re-run I probably ran the update
>>>> sooner after starting. These "Uses constraint violation"s are normally
>>>> fixed by package versioning, or so I thought, but in this case all
>>>> versions
>>>> of these bundles dictate package versions. So I don't know where to go
>>>> from
>>>> there.
>>>>
>>>> I'm also beginning to think using Require-Bundle may be better for my
>>>> sanity, assuming it allows coarser grained control of versioning.
>>>>
>>>> Serves me right for working on a Sunday I suppose.
>>>>
>>>> Dan
>>>>
>>>> On Sat, Jun 30, 2012 at 5:46 PM, Richard S. Hall <heavy@ungoverned.org
>>>>
>>>>> wrote:
>>>>>
>>>> Updating the service doesn't completely get rid of its old exports,
>>>> you
>>>>
>>>>> need to refresh it to do that. Most likely if you updated the client
>>>>> first,
>>>>> then it gets wired to the old export and stays that way after you
>>>>> update
>>>>> the server. Regardless, if you want to make sure you don't have any old
>>>>> "stale" versions causing you confusion, you have to do a "refresh"
>>>>> after
>>>>> a
>>>>> series of updates and uninstalls.
>>>>>
>>>>> -> richard
>>>>>
>>>>>
>>>>> On 6/30/12 12:09, Dan Gravell wrote:
>>>>>
>>>>> My OSGi adventure continues...
>>>>>
>>>>>> I have a bundle "Client" and bundle "Server". In Client's activator it
>>>>>> invokes code in Server, returning an object from Server, let's call it
>>>>>> server.A. A is defined in Server. Client then registers A as a
>>>>>> service:
>>>>>>
>>>>>> context.registerService(A.******class, (A) serverClass.getA(), new
>>>>>>
>>>>>>
>>>>>> Hashtable());
>>>>>>
>>>>>> This works when it is first run.
>>>>>>
>>>>>> If I then update Client and Server bundles, the Client Activator gets
>>>>>> run
>>>>>> again. This time I get a ClassCastException saying "server.A cannot be
>>>>>> cast
>>>>>> to server.A".
>>>>>>
>>>>>> So I guess the classloaders are different for the A that is returned
>>>>>> by
>>>>>> Server to the one Client sees. Given both bundles were updated at the
>>>>>> same
>>>>>> time, why is this?
>>>>>>
>>>>>> I make use of package versioning, if this is important. A's package,
>>>>>> server, was not updated, and its version was not incremented. Was the
>>>>>> code
>>>>>> in Client using the old version of server.A?
>>>>>>
>>>>>> I guess registering A as a service in Client, rather than Server, is
>>>>>> opposed to most sample code I see but is it the cause of the problem?
>>>>>> If
>>>>>> classloaders work on a per package level then it won't help will it?
>>>>>>
>>>>>> Thanks,
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>> ------------------------------******--------------------------**
>>>>>> --**
>>>>>>
>>>>> --**---------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.****apac**he.org<
>>>>> http://apache.org**>
>>>>> <users-unsubscribe@**felix.**apache.org <http://felix.apache.org><
>>>>> users-unsubscribe@**felix.apache.org<us...@felix.apache.org>
>>>>> >
>>>>>
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>> ------------------------------****----------------------------**
>>> --**---------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.**apac**he.org<http://apache.org>
>>> <us...@felix.apache.org>
>>> >
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Help me understand ClassCastException after update
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 7/1/12 9:38, Dan Gravell wrote:
> Thanks Richard...
>
> On Sun, Jul 1, 2012 at 2:15 PM, Richard S. Hall <he...@ungoverned.org>wrote:
>
>> I have to imagine the simple solution for your scenario is to deploy your
>> client and your server (with OBR or not), then to perform a refresh
>> afterwards.
>>
> ... but this is what I'm doing isn't it? Here's my actual code to deploy:
>
> final Resource bundleResource =
> FelixObrUtils.getLatestBundleResource(repoAdminSupplier);
> Resolver resolver = repoAdminSupplier.get().resolver();
> resolver.add(bundleResource);
> if (resolver.resolve()) {
> listener.installBundleStart();
> resolver.deploy(Resolver.START);
> // null to resolve all unresolved bundles
> context.getBundle(0).adapt(FrameworkWiring.class).resolveBundles(null);
> listener.installBundleComplete();
> } else {
> // handling code...
> }
>
> FelixObrUtils.getLatestBundleResource looks inside the RepositoryAdmin and
> returns the highest versioned Resource with the symbolic name
> "com.elsten.bliss.bundle". This is resolved (which should bring in the new
> dependencies) and then deployed.
>
> This code is itself running inside com.elsten.bliss.bundle.
>
> Thanks for the info about refreshing and the BundleContext. I always
> guessed that approach was a bit suspect. What is the correct way of
> retrieving the FrameworkWiring without the BundleContext?
For the above to work, the "context" must be from a bundle that hasn't
been updated. So, if you have three bundles: updater, client, and
server. And updater is doing the above code to update server and client,
then it should work.
-> richard
>
> Dan
>
>
>> If we release a modified version of OBR that automatically refreshes, then
>> you shouldn't need to manually perform the refresh afterwards.
>>
>> -> richard
>>
>> I'm using OBR, and the Client is marked as
>>> requiring a package on Server that was updated. Therefore I expected
>>> Server
>>> to be updated before Client (although this assumption might be wrong). In
>>> OBR API terms I am *only* calling deploy() on the Client BundleResource.
>>>
>>> The other, separate, package named 'server' within the Server bundle that
>>> contains type A was not updated and the requirement was not updated.
>>>
>>> When one package is updated but the other isn't within a bundle I assumed
>>> the classloader would be refreshed for the entire bundle, so affecting
>>> both
>>> packages, by virtue of the bundle being updated.
>>>
>>> So I ran an experiment. In bundle "Server", I updated the exported version
>>> of package "server". I then updated bundle "Server"'s version to ensure it
>>> would be updated. In "Client"'s manifest I changed the version requirement
>>> to reflect the new version of "server". I also updated "Client"'s version
>>> (although that uses the .qualifier PDE build approach, so a regeneration
>>> of
>>> the build script was all that was required).
>>>
>>> This time I get a different error message:
>>>
>>> ERROR: Resolver: Start error - com.elsten.bliss.bundle
>>> org.osgi.framework.**BundleException: Activator start error in
>>> bundle com.elsten.bliss.bundle [42].
>>> at org.apache.felix.framework.**Felix.activateBundle(Felix.**java:2027)
>>> at org.apache.felix.framework.**Felix.startBundle(Felix.java:**1895)
>>> at org.apache.felix.framework.**BundleImpl.start(BundleImpl.**java:944)
>>> at org.apache.felix.framework.**BundleImpl.start(BundleImpl.**java:931)
>>> at
>>> org.apache.felix.**bundlerepository.impl.**ResolverImpl.deploy(**
>>> ResolverImpl.java:630)
>>> [...]
>>> Caused by: java.lang.LinkageError: loader constraint violation: when
>>> resolving method
>>> "com.elsten.bliss.main.Main.**getLicenceStore()Lcom/elsten/**
>>> bliss/licence/**PerFixLicenceStore;"
>>> the class loader (instance of
>>> org/apache/felix/framework/**BundleWiringImpl$**BundleClassLoaderJava5)
>>> of the
>>> current class, com/elsten/osgi/Activator, and the class loader (instance
>>> of
>>> org/apache/felix/framework/**BundleWiringImpl$**BundleClassLoaderJava5)
>>> for
>>> resolved class, com/elsten/bliss/main/Main, have different Class objects
>>> for the type com/elsten/bliss/licence/**PerFixLicenceStore used in the
>>> signature
>>> at com.elsten.osgi.Activator.**start(Activator.java:40)
>>> at
>>> org.apache.felix.framework.**util.SecureAction.**
>>> startActivator(SecureAction.**java:641)
>>> at org.apache.felix.framework.**Felix.activateBundle(Felix.**java:1977)
>>>
>>> This is a problem with a line preceeding the one that I originally had a
>>> problem for. But again, it's for a type in a package I didn't update, but
>>> within the bundle I did update.
>>>
>>> Apologies for my obfuscated bundle and package naming before. I should
>>> explain how the actual names in the output above map to what I've
>>> described
>>> so far:
>>>
>>> Bundle com.elsten.bliss.bundle (nee "Client") has packages:
>>> com.elsten.osgi [the actual name for the 'client' package. The package
>>> containing the Activator that runs a class in com.elsten.bliss.main and
>>> uses the result to register services]
>>>
>>> Bundle com.elsten.bliss.platform (nee "Server") has packages:
>>> com.elsten.bliss.main [the package containing the class that provides the
>>> services to 'client']
>>> com.elsten.bliss.licence [the package containing the type showing the new
>>> problem]
>>> com.elsten.bliss.music.policy2 [the actual name for the 'server' package]
>>>
>>> So then I updated com.elsten.bliss.licence's version, containing bundle
>>> version, import version, and containing bundle of the import's version. I
>>> ran the update again. This time there were no errors! Although refresh
>>> still failed:
>>>
>>> java.lang.**IllegalStateException: Invalid BundleContext.
>>> at
>>> org.apache.felix.framework.**BundleContextImpl.**checkValidity(**
>>> BundleContextImpl.java:514)
>>> at
>>> org.apache.felix.framework.**BundleContextImpl.getBundle(**
>>> BundleContextImpl.java:173)
>>> at com.elsten.osgi.OnlineUpdater.**updateTo(OnlineUpdater.java:**51)
>>>
>>> This suggests the bundle did not restart. But I stopped the JVM and didn't
>>> note whether the application was still usable, so I ran the test again,
>>> removing felix-cache and performing the update against the same bundles.
>>> This time I get a *different* result:
>>>
>>> ERROR: Resolver: Start error - com.elsten.bliss.bundle
>>> org.osgi.framework.**BundleException: Uses constraint violation. Unable
>>> to
>>> resolve bundle revision com.elsten.bliss.platform [11.1] because it is
>>> exposed to package 'com.elsten.musicbrainz' from bundle revisions
>>> com.elsten.musicbrainz [30.1] and com.elsten.musicbrainz [30.0] via two
>>> dependency chains.
>>>
>>> Chain 1:
>>> com.elsten.bliss.platform [11.1]
>>> import: (&(osgi.wiring.package=com.**elsten.musicbrainz)(version>=**
>>> 1.0.2))
>>> |
>>> export: osgi.wiring.package=com.**elsten.musicbrainz
>>> com.elsten.musicbrainz [30.1]
>>>
>>> Chain 2:
>>> com.elsten.bliss.platform [11.1]
>>> import:
>>> (&(osgi.wiring.package=com.**elsten.musicbrainz.model)(**version>=1.0.1))
>>> |
>>> export: osgi.wiring.package=com.**elsten.musicbrainz.model;
>>> uses:=com.elsten.musicbrainz
>>> export: osgi.wiring.package=com.**elsten.musicbrainz
>>> com.elsten.musicbrainz [30.0]
>>> at org.apache.felix.framework.**Felix.resolveBundleRevision(**
>>> Felix.java:3832)
>>> at org.apache.felix.framework.**Felix.startBundle(Felix.java:**1868)
>>> at org.apache.felix.framework.**BundleImpl.start(BundleImpl.**java:944)
>>> at org.apache.felix.framework.**BundleImpl.start(BundleImpl.**java:931)
>>> at
>>> org.apache.felix.**bundlerepository.impl.**ResolverImpl.deploy(**
>>> ResolverImpl.java:630)
>>>
>>> Crap. So now I am getting different errors on different invocations too.
>>> Maybe it was a timing issue - on the re-run I probably ran the update
>>> sooner after starting. These "Uses constraint violation"s are normally
>>> fixed by package versioning, or so I thought, but in this case all
>>> versions
>>> of these bundles dictate package versions. So I don't know where to go
>>> from
>>> there.
>>>
>>> I'm also beginning to think using Require-Bundle may be better for my
>>> sanity, assuming it allows coarser grained control of versioning.
>>>
>>> Serves me right for working on a Sunday I suppose.
>>>
>>> Dan
>>>
>>> On Sat, Jun 30, 2012 at 5:46 PM, Richard S. Hall <heavy@ungoverned.org
>>>> wrote:
>>> Updating the service doesn't completely get rid of its old exports, you
>>>> need to refresh it to do that. Most likely if you updated the client
>>>> first,
>>>> then it gets wired to the old export and stays that way after you update
>>>> the server. Regardless, if you want to make sure you don't have any old
>>>> "stale" versions causing you confusion, you have to do a "refresh" after
>>>> a
>>>> series of updates and uninstalls.
>>>>
>>>> -> richard
>>>>
>>>>
>>>> On 6/30/12 12:09, Dan Gravell wrote:
>>>>
>>>> My OSGi adventure continues...
>>>>> I have a bundle "Client" and bundle "Server". In Client's activator it
>>>>> invokes code in Server, returning an object from Server, let's call it
>>>>> server.A. A is defined in Server. Client then registers A as a service:
>>>>>
>>>>> context.registerService(A.****class, (A) serverClass.getA(), new
>>>>>
>>>>> Hashtable());
>>>>>
>>>>> This works when it is first run.
>>>>>
>>>>> If I then update Client and Server bundles, the Client Activator gets
>>>>> run
>>>>> again. This time I get a ClassCastException saying "server.A cannot be
>>>>> cast
>>>>> to server.A".
>>>>>
>>>>> So I guess the classloaders are different for the A that is returned by
>>>>> Server to the one Client sees. Given both bundles were updated at the
>>>>> same
>>>>> time, why is this?
>>>>>
>>>>> I make use of package versioning, if this is important. A's package,
>>>>> server, was not updated, and its version was not incremented. Was the
>>>>> code
>>>>> in Client using the old version of server.A?
>>>>>
>>>>> I guess registering A as a service in Client, rather than Server, is
>>>>> opposed to most sample code I see but is it the cause of the problem? If
>>>>> classloaders work on a per package level then it won't help will it?
>>>>>
>>>>> Thanks,
>>>>> Dan
>>>>>
>>>>>
>>>>> ------------------------------****----------------------------**
>>>> --**---------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.**apac**he.org<http://apache.org>
>>>> <us...@felix.apache.org>
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@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: Help me understand ClassCastException after update
Posted by Dan Gravell <el...@googlemail.com>.
Thanks Richard...
On Sun, Jul 1, 2012 at 2:15 PM, Richard S. Hall <he...@ungoverned.org>wrote:
> I have to imagine the simple solution for your scenario is to deploy your
> client and your server (with OBR or not), then to perform a refresh
> afterwards.
>
... but this is what I'm doing isn't it? Here's my actual code to deploy:
final Resource bundleResource =
FelixObrUtils.getLatestBundleResource(repoAdminSupplier);
Resolver resolver = repoAdminSupplier.get().resolver();
resolver.add(bundleResource);
if (resolver.resolve()) {
listener.installBundleStart();
resolver.deploy(Resolver.START);
// null to resolve all unresolved bundles
context.getBundle(0).adapt(FrameworkWiring.class).resolveBundles(null);
listener.installBundleComplete();
} else {
// handling code...
}
FelixObrUtils.getLatestBundleResource looks inside the RepositoryAdmin and
returns the highest versioned Resource with the symbolic name
"com.elsten.bliss.bundle". This is resolved (which should bring in the new
dependencies) and then deployed.
This code is itself running inside com.elsten.bliss.bundle.
Thanks for the info about refreshing and the BundleContext. I always
guessed that approach was a bit suspect. What is the correct way of
retrieving the FrameworkWiring without the BundleContext?
Dan
> If we release a modified version of OBR that automatically refreshes, then
> you shouldn't need to manually perform the refresh afterwards.
>
> -> richard
>
> I'm using OBR, and the Client is marked as
>> requiring a package on Server that was updated. Therefore I expected
>> Server
>> to be updated before Client (although this assumption might be wrong). In
>> OBR API terms I am *only* calling deploy() on the Client BundleResource.
>>
>> The other, separate, package named 'server' within the Server bundle that
>> contains type A was not updated and the requirement was not updated.
>>
>> When one package is updated but the other isn't within a bundle I assumed
>> the classloader would be refreshed for the entire bundle, so affecting
>> both
>> packages, by virtue of the bundle being updated.
>>
>> So I ran an experiment. In bundle "Server", I updated the exported version
>> of package "server". I then updated bundle "Server"'s version to ensure it
>> would be updated. In "Client"'s manifest I changed the version requirement
>> to reflect the new version of "server". I also updated "Client"'s version
>> (although that uses the .qualifier PDE build approach, so a regeneration
>> of
>> the build script was all that was required).
>>
>> This time I get a different error message:
>>
>> ERROR: Resolver: Start error - com.elsten.bliss.bundle
>> org.osgi.framework.**BundleException: Activator start error in
>> bundle com.elsten.bliss.bundle [42].
>> at org.apache.felix.framework.**Felix.activateBundle(Felix.**java:2027)
>> at org.apache.felix.framework.**Felix.startBundle(Felix.java:**1895)
>> at org.apache.felix.framework.**BundleImpl.start(BundleImpl.**java:944)
>> at org.apache.felix.framework.**BundleImpl.start(BundleImpl.**java:931)
>> at
>> org.apache.felix.**bundlerepository.impl.**ResolverImpl.deploy(**
>> ResolverImpl.java:630)
>> [...]
>> Caused by: java.lang.LinkageError: loader constraint violation: when
>> resolving method
>> "com.elsten.bliss.main.Main.**getLicenceStore()Lcom/elsten/**
>> bliss/licence/**PerFixLicenceStore;"
>> the class loader (instance of
>> org/apache/felix/framework/**BundleWiringImpl$**BundleClassLoaderJava5)
>> of the
>> current class, com/elsten/osgi/Activator, and the class loader (instance
>> of
>> org/apache/felix/framework/**BundleWiringImpl$**BundleClassLoaderJava5)
>> for
>> resolved class, com/elsten/bliss/main/Main, have different Class objects
>> for the type com/elsten/bliss/licence/**PerFixLicenceStore used in the
>> signature
>> at com.elsten.osgi.Activator.**start(Activator.java:40)
>> at
>> org.apache.felix.framework.**util.SecureAction.**
>> startActivator(SecureAction.**java:641)
>> at org.apache.felix.framework.**Felix.activateBundle(Felix.**java:1977)
>>
>> This is a problem with a line preceeding the one that I originally had a
>> problem for. But again, it's for a type in a package I didn't update, but
>> within the bundle I did update.
>>
>> Apologies for my obfuscated bundle and package naming before. I should
>> explain how the actual names in the output above map to what I've
>> described
>> so far:
>>
>> Bundle com.elsten.bliss.bundle (nee "Client") has packages:
>> com.elsten.osgi [the actual name for the 'client' package. The package
>> containing the Activator that runs a class in com.elsten.bliss.main and
>> uses the result to register services]
>>
>> Bundle com.elsten.bliss.platform (nee "Server") has packages:
>> com.elsten.bliss.main [the package containing the class that provides the
>> services to 'client']
>> com.elsten.bliss.licence [the package containing the type showing the new
>> problem]
>> com.elsten.bliss.music.policy2 [the actual name for the 'server' package]
>>
>> So then I updated com.elsten.bliss.licence's version, containing bundle
>> version, import version, and containing bundle of the import's version. I
>> ran the update again. This time there were no errors! Although refresh
>> still failed:
>>
>> java.lang.**IllegalStateException: Invalid BundleContext.
>> at
>> org.apache.felix.framework.**BundleContextImpl.**checkValidity(**
>> BundleContextImpl.java:514)
>> at
>> org.apache.felix.framework.**BundleContextImpl.getBundle(**
>> BundleContextImpl.java:173)
>> at com.elsten.osgi.OnlineUpdater.**updateTo(OnlineUpdater.java:**51)
>>
>> This suggests the bundle did not restart. But I stopped the JVM and didn't
>> note whether the application was still usable, so I ran the test again,
>> removing felix-cache and performing the update against the same bundles.
>> This time I get a *different* result:
>>
>> ERROR: Resolver: Start error - com.elsten.bliss.bundle
>> org.osgi.framework.**BundleException: Uses constraint violation. Unable
>> to
>> resolve bundle revision com.elsten.bliss.platform [11.1] because it is
>> exposed to package 'com.elsten.musicbrainz' from bundle revisions
>> com.elsten.musicbrainz [30.1] and com.elsten.musicbrainz [30.0] via two
>> dependency chains.
>>
>> Chain 1:
>> com.elsten.bliss.platform [11.1]
>> import: (&(osgi.wiring.package=com.**elsten.musicbrainz)(version>=**
>> 1.0.2))
>> |
>> export: osgi.wiring.package=com.**elsten.musicbrainz
>> com.elsten.musicbrainz [30.1]
>>
>> Chain 2:
>> com.elsten.bliss.platform [11.1]
>> import:
>> (&(osgi.wiring.package=com.**elsten.musicbrainz.model)(**version>=1.0.1))
>> |
>> export: osgi.wiring.package=com.**elsten.musicbrainz.model;
>> uses:=com.elsten.musicbrainz
>> export: osgi.wiring.package=com.**elsten.musicbrainz
>> com.elsten.musicbrainz [30.0]
>> at org.apache.felix.framework.**Felix.resolveBundleRevision(**
>> Felix.java:3832)
>> at org.apache.felix.framework.**Felix.startBundle(Felix.java:**1868)
>> at org.apache.felix.framework.**BundleImpl.start(BundleImpl.**java:944)
>> at org.apache.felix.framework.**BundleImpl.start(BundleImpl.**java:931)
>> at
>> org.apache.felix.**bundlerepository.impl.**ResolverImpl.deploy(**
>> ResolverImpl.java:630)
>>
>> Crap. So now I am getting different errors on different invocations too.
>> Maybe it was a timing issue - on the re-run I probably ran the update
>> sooner after starting. These "Uses constraint violation"s are normally
>> fixed by package versioning, or so I thought, but in this case all
>> versions
>> of these bundles dictate package versions. So I don't know where to go
>> from
>> there.
>>
>> I'm also beginning to think using Require-Bundle may be better for my
>> sanity, assuming it allows coarser grained control of versioning.
>>
>> Serves me right for working on a Sunday I suppose.
>>
>> Dan
>>
>> On Sat, Jun 30, 2012 at 5:46 PM, Richard S. Hall <heavy@ungoverned.org
>> >wrote:
>>
>> Updating the service doesn't completely get rid of its old exports, you
>>> need to refresh it to do that. Most likely if you updated the client
>>> first,
>>> then it gets wired to the old export and stays that way after you update
>>> the server. Regardless, if you want to make sure you don't have any old
>>> "stale" versions causing you confusion, you have to do a "refresh" after
>>> a
>>> series of updates and uninstalls.
>>>
>>> -> richard
>>>
>>>
>>> On 6/30/12 12:09, Dan Gravell wrote:
>>>
>>> My OSGi adventure continues...
>>>>
>>>> I have a bundle "Client" and bundle "Server". In Client's activator it
>>>> invokes code in Server, returning an object from Server, let's call it
>>>> server.A. A is defined in Server. Client then registers A as a service:
>>>>
>>>> context.registerService(A.****class, (A) serverClass.getA(), new
>>>>
>>>> Hashtable());
>>>>
>>>> This works when it is first run.
>>>>
>>>> If I then update Client and Server bundles, the Client Activator gets
>>>> run
>>>> again. This time I get a ClassCastException saying "server.A cannot be
>>>> cast
>>>> to server.A".
>>>>
>>>> So I guess the classloaders are different for the A that is returned by
>>>> Server to the one Client sees. Given both bundles were updated at the
>>>> same
>>>> time, why is this?
>>>>
>>>> I make use of package versioning, if this is important. A's package,
>>>> server, was not updated, and its version was not incremented. Was the
>>>> code
>>>> in Client using the old version of server.A?
>>>>
>>>> I guess registering A as a service in Client, rather than Server, is
>>>> opposed to most sample code I see but is it the cause of the problem? If
>>>> classloaders work on a per package level then it won't help will it?
>>>>
>>>> Thanks,
>>>> Dan
>>>>
>>>>
>>>> ------------------------------****----------------------------**
>>> --**---------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.**apac**he.org<http://apache.org>
>>> <us...@felix.apache.org>
>>> >
>>>
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Help me understand ClassCastException after update
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 7/1/12 8:17, Dan Gravell wrote:
> One further question on this. You said "Most likely if you updated the
> client first, then it gets wired to the old export and stays that way after
> you update the server".
If you are using OBR, then my comment doesn't apply. However, OBR
doesn't worry about applying the updates in any particular dependency
order. Instead, it does it in two passes: in the first pass it does all
installs/updates, in the second pass it starts bundles. That way
ordering doesn't make a difference.
However, we just discussed recently that OBR doesn't automatically do a
refresh when it does an update operation, which most likely leads to the
root issue here.
Regarding your invalid bundle context issue, you can't use a bundle
context after the associated bundle has been updated. In general, it is
a bad idea to use bundle contexts from arbitrary bundles. However, if
you are going to do it you shouldn't store the bundle context, but
retrieve it when you need it. A bundle context becomes invalid any time
the bundle is stopped (which it does for update).
I have to imagine the simple solution for your scenario is to deploy
your client and your server (with OBR or not), then to perform a refresh
afterwards.
If we release a modified version of OBR that automatically refreshes,
then you shouldn't need to manually perform the refresh afterwards.
-> richard
> I'm using OBR, and the Client is marked as
> requiring a package on Server that was updated. Therefore I expected Server
> to be updated before Client (although this assumption might be wrong). In
> OBR API terms I am *only* calling deploy() on the Client BundleResource.
>
> The other, separate, package named 'server' within the Server bundle that
> contains type A was not updated and the requirement was not updated.
>
> When one package is updated but the other isn't within a bundle I assumed
> the classloader would be refreshed for the entire bundle, so affecting both
> packages, by virtue of the bundle being updated.
>
> So I ran an experiment. In bundle "Server", I updated the exported version
> of package "server". I then updated bundle "Server"'s version to ensure it
> would be updated. In "Client"'s manifest I changed the version requirement
> to reflect the new version of "server". I also updated "Client"'s version
> (although that uses the .qualifier PDE build approach, so a regeneration of
> the build script was all that was required).
>
> This time I get a different error message:
>
> ERROR: Resolver: Start error - com.elsten.bliss.bundle
> org.osgi.framework.BundleException: Activator start error in
> bundle com.elsten.bliss.bundle [42].
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:2027)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:1895)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:931)
> at
> org.apache.felix.bundlerepository.impl.ResolverImpl.deploy(ResolverImpl.java:630)
> [...]
> Caused by: java.lang.LinkageError: loader constraint violation: when
> resolving method
> "com.elsten.bliss.main.Main.getLicenceStore()Lcom/elsten/bliss/licence/PerFixLicenceStore;"
> the class loader (instance of
> org/apache/felix/framework/BundleWiringImpl$BundleClassLoaderJava5) of the
> current class, com/elsten/osgi/Activator, and the class loader (instance of
> org/apache/felix/framework/BundleWiringImpl$BundleClassLoaderJava5) for
> resolved class, com/elsten/bliss/main/Main, have different Class objects
> for the type com/elsten/bliss/licence/PerFixLicenceStore used in the
> signature
> at com.elsten.osgi.Activator.start(Activator.java:40)
> at
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:641)
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:1977)
>
> This is a problem with a line preceeding the one that I originally had a
> problem for. But again, it's for a type in a package I didn't update, but
> within the bundle I did update.
>
> Apologies for my obfuscated bundle and package naming before. I should
> explain how the actual names in the output above map to what I've described
> so far:
>
> Bundle com.elsten.bliss.bundle (nee "Client") has packages:
> com.elsten.osgi [the actual name for the 'client' package. The package
> containing the Activator that runs a class in com.elsten.bliss.main and
> uses the result to register services]
>
> Bundle com.elsten.bliss.platform (nee "Server") has packages:
> com.elsten.bliss.main [the package containing the class that provides the
> services to 'client']
> com.elsten.bliss.licence [the package containing the type showing the new
> problem]
> com.elsten.bliss.music.policy2 [the actual name for the 'server' package]
>
> So then I updated com.elsten.bliss.licence's version, containing bundle
> version, import version, and containing bundle of the import's version. I
> ran the update again. This time there were no errors! Although refresh
> still failed:
>
> java.lang.IllegalStateException: Invalid BundleContext.
> at
> org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContextImpl.java:514)
> at
> org.apache.felix.framework.BundleContextImpl.getBundle(BundleContextImpl.java:173)
> at com.elsten.osgi.OnlineUpdater.updateTo(OnlineUpdater.java:51)
>
> This suggests the bundle did not restart. But I stopped the JVM and didn't
> note whether the application was still usable, so I ran the test again,
> removing felix-cache and performing the update against the same bundles.
> This time I get a *different* result:
>
> ERROR: Resolver: Start error - com.elsten.bliss.bundle
> org.osgi.framework.BundleException: Uses constraint violation. Unable to
> resolve bundle revision com.elsten.bliss.platform [11.1] because it is
> exposed to package 'com.elsten.musicbrainz' from bundle revisions
> com.elsten.musicbrainz [30.1] and com.elsten.musicbrainz [30.0] via two
> dependency chains.
>
> Chain 1:
> com.elsten.bliss.platform [11.1]
> import: (&(osgi.wiring.package=com.elsten.musicbrainz)(version>=1.0.2))
> |
> export: osgi.wiring.package=com.elsten.musicbrainz
> com.elsten.musicbrainz [30.1]
>
> Chain 2:
> com.elsten.bliss.platform [11.1]
> import:
> (&(osgi.wiring.package=com.elsten.musicbrainz.model)(version>=1.0.1))
> |
> export: osgi.wiring.package=com.elsten.musicbrainz.model;
> uses:=com.elsten.musicbrainz
> export: osgi.wiring.package=com.elsten.musicbrainz
> com.elsten.musicbrainz [30.0]
> at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3832)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:931)
> at
> org.apache.felix.bundlerepository.impl.ResolverImpl.deploy(ResolverImpl.java:630)
>
> Crap. So now I am getting different errors on different invocations too.
> Maybe it was a timing issue - on the re-run I probably ran the update
> sooner after starting. These "Uses constraint violation"s are normally
> fixed by package versioning, or so I thought, but in this case all versions
> of these bundles dictate package versions. So I don't know where to go from
> there.
>
> I'm also beginning to think using Require-Bundle may be better for my
> sanity, assuming it allows coarser grained control of versioning.
>
> Serves me right for working on a Sunday I suppose.
>
> Dan
>
> On Sat, Jun 30, 2012 at 5:46 PM, Richard S. Hall <he...@ungoverned.org>wrote:
>
>> Updating the service doesn't completely get rid of its old exports, you
>> need to refresh it to do that. Most likely if you updated the client first,
>> then it gets wired to the old export and stays that way after you update
>> the server. Regardless, if you want to make sure you don't have any old
>> "stale" versions causing you confusion, you have to do a "refresh" after a
>> series of updates and uninstalls.
>>
>> -> richard
>>
>>
>> On 6/30/12 12:09, Dan Gravell wrote:
>>
>>> My OSGi adventure continues...
>>>
>>> I have a bundle "Client" and bundle "Server". In Client's activator it
>>> invokes code in Server, returning an object from Server, let's call it
>>> server.A. A is defined in Server. Client then registers A as a service:
>>>
>>> context.registerService(A.**class, (A) serverClass.getA(), new
>>> Hashtable());
>>>
>>> This works when it is first run.
>>>
>>> If I then update Client and Server bundles, the Client Activator gets run
>>> again. This time I get a ClassCastException saying "server.A cannot be
>>> cast
>>> to server.A".
>>>
>>> So I guess the classloaders are different for the A that is returned by
>>> Server to the one Client sees. Given both bundles were updated at the same
>>> time, why is this?
>>>
>>> I make use of package versioning, if this is important. A's package,
>>> server, was not updated, and its version was not incremented. Was the code
>>> in Client using the old version of server.A?
>>>
>>> I guess registering A as a service in Client, rather than Server, is
>>> opposed to most sample code I see but is it the cause of the problem? If
>>> classloaders work on a per package level then it won't help will it?
>>>
>>> Thanks,
>>> Dan
>>>
>>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@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: Help me understand ClassCastException after update
Posted by Dan Gravell <el...@googlemail.com>.
One further question on this. You said "Most likely if you updated the
client first, then it gets wired to the old export and stays that way after
you update the server". I'm using OBR, and the Client is marked as
requiring a package on Server that was updated. Therefore I expected Server
to be updated before Client (although this assumption might be wrong). In
OBR API terms I am *only* calling deploy() on the Client BundleResource.
The other, separate, package named 'server' within the Server bundle that
contains type A was not updated and the requirement was not updated.
When one package is updated but the other isn't within a bundle I assumed
the classloader would be refreshed for the entire bundle, so affecting both
packages, by virtue of the bundle being updated.
So I ran an experiment. In bundle "Server", I updated the exported version
of package "server". I then updated bundle "Server"'s version to ensure it
would be updated. In "Client"'s manifest I changed the version requirement
to reflect the new version of "server". I also updated "Client"'s version
(although that uses the .qualifier PDE build approach, so a regeneration of
the build script was all that was required).
This time I get a different error message:
ERROR: Resolver: Start error - com.elsten.bliss.bundle
org.osgi.framework.BundleException: Activator start error in
bundle com.elsten.bliss.bundle [42].
at org.apache.felix.framework.Felix.activateBundle(Felix.java:2027)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1895)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:931)
at
org.apache.felix.bundlerepository.impl.ResolverImpl.deploy(ResolverImpl.java:630)
[...]
Caused by: java.lang.LinkageError: loader constraint violation: when
resolving method
"com.elsten.bliss.main.Main.getLicenceStore()Lcom/elsten/bliss/licence/PerFixLicenceStore;"
the class loader (instance of
org/apache/felix/framework/BundleWiringImpl$BundleClassLoaderJava5) of the
current class, com/elsten/osgi/Activator, and the class loader (instance of
org/apache/felix/framework/BundleWiringImpl$BundleClassLoaderJava5) for
resolved class, com/elsten/bliss/main/Main, have different Class objects
for the type com/elsten/bliss/licence/PerFixLicenceStore used in the
signature
at com.elsten.osgi.Activator.start(Activator.java:40)
at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:641)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1977)
This is a problem with a line preceeding the one that I originally had a
problem for. But again, it's for a type in a package I didn't update, but
within the bundle I did update.
Apologies for my obfuscated bundle and package naming before. I should
explain how the actual names in the output above map to what I've described
so far:
Bundle com.elsten.bliss.bundle (nee "Client") has packages:
com.elsten.osgi [the actual name for the 'client' package. The package
containing the Activator that runs a class in com.elsten.bliss.main and
uses the result to register services]
Bundle com.elsten.bliss.platform (nee "Server") has packages:
com.elsten.bliss.main [the package containing the class that provides the
services to 'client']
com.elsten.bliss.licence [the package containing the type showing the new
problem]
com.elsten.bliss.music.policy2 [the actual name for the 'server' package]
So then I updated com.elsten.bliss.licence's version, containing bundle
version, import version, and containing bundle of the import's version. I
ran the update again. This time there were no errors! Although refresh
still failed:
java.lang.IllegalStateException: Invalid BundleContext.
at
org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContextImpl.java:514)
at
org.apache.felix.framework.BundleContextImpl.getBundle(BundleContextImpl.java:173)
at com.elsten.osgi.OnlineUpdater.updateTo(OnlineUpdater.java:51)
This suggests the bundle did not restart. But I stopped the JVM and didn't
note whether the application was still usable, so I ran the test again,
removing felix-cache and performing the update against the same bundles.
This time I get a *different* result:
ERROR: Resolver: Start error - com.elsten.bliss.bundle
org.osgi.framework.BundleException: Uses constraint violation. Unable to
resolve bundle revision com.elsten.bliss.platform [11.1] because it is
exposed to package 'com.elsten.musicbrainz' from bundle revisions
com.elsten.musicbrainz [30.1] and com.elsten.musicbrainz [30.0] via two
dependency chains.
Chain 1:
com.elsten.bliss.platform [11.1]
import: (&(osgi.wiring.package=com.elsten.musicbrainz)(version>=1.0.2))
|
export: osgi.wiring.package=com.elsten.musicbrainz
com.elsten.musicbrainz [30.1]
Chain 2:
com.elsten.bliss.platform [11.1]
import:
(&(osgi.wiring.package=com.elsten.musicbrainz.model)(version>=1.0.1))
|
export: osgi.wiring.package=com.elsten.musicbrainz.model;
uses:=com.elsten.musicbrainz
export: osgi.wiring.package=com.elsten.musicbrainz
com.elsten.musicbrainz [30.0]
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3832)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:931)
at
org.apache.felix.bundlerepository.impl.ResolverImpl.deploy(ResolverImpl.java:630)
Crap. So now I am getting different errors on different invocations too.
Maybe it was a timing issue - on the re-run I probably ran the update
sooner after starting. These "Uses constraint violation"s are normally
fixed by package versioning, or so I thought, but in this case all versions
of these bundles dictate package versions. So I don't know where to go from
there.
I'm also beginning to think using Require-Bundle may be better for my
sanity, assuming it allows coarser grained control of versioning.
Serves me right for working on a Sunday I suppose.
Dan
On Sat, Jun 30, 2012 at 5:46 PM, Richard S. Hall <he...@ungoverned.org>wrote:
> Updating the service doesn't completely get rid of its old exports, you
> need to refresh it to do that. Most likely if you updated the client first,
> then it gets wired to the old export and stays that way after you update
> the server. Regardless, if you want to make sure you don't have any old
> "stale" versions causing you confusion, you have to do a "refresh" after a
> series of updates and uninstalls.
>
> -> richard
>
>
> On 6/30/12 12:09, Dan Gravell wrote:
>
>> My OSGi adventure continues...
>>
>> I have a bundle "Client" and bundle "Server". In Client's activator it
>> invokes code in Server, returning an object from Server, let's call it
>> server.A. A is defined in Server. Client then registers A as a service:
>>
>> context.registerService(A.**class, (A) serverClass.getA(), new
>> Hashtable());
>>
>> This works when it is first run.
>>
>> If I then update Client and Server bundles, the Client Activator gets run
>> again. This time I get a ClassCastException saying "server.A cannot be
>> cast
>> to server.A".
>>
>> So I guess the classloaders are different for the A that is returned by
>> Server to the one Client sees. Given both bundles were updated at the same
>> time, why is this?
>>
>> I make use of package versioning, if this is important. A's package,
>> server, was not updated, and its version was not incremented. Was the code
>> in Client using the old version of server.A?
>>
>> I guess registering A as a service in Client, rather than Server, is
>> opposed to most sample code I see but is it the cause of the problem? If
>> classloaders work on a per package level then it won't help will it?
>>
>> Thanks,
>> Dan
>>
>>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Help me understand ClassCastException after update
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Updating the service doesn't completely get rid of its old exports, you
need to refresh it to do that. Most likely if you updated the client
first, then it gets wired to the old export and stays that way after you
update the server. Regardless, if you want to make sure you don't have
any old "stale" versions causing you confusion, you have to do a
"refresh" after a series of updates and uninstalls.
-> richard
On 6/30/12 12:09, Dan Gravell wrote:
> My OSGi adventure continues...
>
> I have a bundle "Client" and bundle "Server". In Client's activator it
> invokes code in Server, returning an object from Server, let's call it
> server.A. A is defined in Server. Client then registers A as a service:
>
> context.registerService(A.class, (A) serverClass.getA(), new Hashtable());
>
> This works when it is first run.
>
> If I then update Client and Server bundles, the Client Activator gets run
> again. This time I get a ClassCastException saying "server.A cannot be cast
> to server.A".
>
> So I guess the classloaders are different for the A that is returned by
> Server to the one Client sees. Given both bundles were updated at the same
> time, why is this?
>
> I make use of package versioning, if this is important. A's package,
> server, was not updated, and its version was not incremented. Was the code
> in Client using the old version of server.A?
>
> I guess registering A as a service in Client, rather than Server, is
> opposed to most sample code I see but is it the cause of the problem? If
> classloaders work on a per package level then it won't help will it?
>
> Thanks,
> Dan
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Help me understand ClassCastException after update
Posted by Dan Gravell <el...@googlemail.com>.
Thanks for answering Neil! I've been referring to your blog a lot the past
few weeks and we also talked on the bndtools group the other day.
The CCE occurs in the activator for Client. It's the line I pasted above:
context.registerService(A.class, (A) serverClass.getA(), new Hashtable());
So it's that cast: (A) - sorry I guess having one letter class names
probably obscured this.
Yes, another bundle uses this service. Let's call this... Client2 (sorry).
That bundle was *not* updated. That uses both a ServiceTracker and in a few
places a simple getService().
I did try to refresh after the update, but got another exception:
java.lang.IllegalStateException: Invalid BundleContext.
at
org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContextImpl.java:514)
at
org.apache.felix.framework.BundleContextImpl.getBundle(BundleContextImpl.java:173)
I am refreshing using a bundle context of one of the bundles that was
updated. This might be a bad thing to do. It throws the ISE I guess because
the of the previous CCE, as the bundle is in STARTING mode, not STARTED. My
code to refresh is:
context.getBundle(0).adapt(FrameworkWiring.class).resolveBundles(null);
In other words: get the system bundle, adapt it and then resolve all. I
didn't know another way of getting the FrameworkBinding instance from just
the BundleContext.
Dan
On Sat, Jun 30, 2012 at 5:39 PM, Neil Bartlett <nj...@gmail.com> wrote:
> Where does the ClassCastException happen? You said that Client registers
> the service, does any other bundle access and use the service? If so, what
> kind of method did you use to obtain the service (eg ServiceTracker, DS,
> etc)?
>
> Also did you refresh after updating the bundles? Note that bundles cannot
> really be updated "at the same time", ie there is no atomic multi-bundle
> update. This is why you need to refresh after a series of updates.
>
> Rgds
> Neil
>
> --
> Neil Bartlett
> Sent from a phone
>
>
> On Saturday, 30 June 2012 at 17:09, Dan Gravell wrote:
>
> > My OSGi adventure continues...
> >
> > I have a bundle "Client" and bundle "Server". In Client's activator it
> > invokes code in Server, returning an object from Server, let's call it
> > server.A. A is defined in Server. Client then registers A as a service:
> >
> > context.registerService(A.class, (A) serverClass.getA(), new
> Hashtable());
> >
> > This works when it is first run.
> >
> > If I then update Client and Server bundles, the Client Activator gets run
> > again. This time I get a ClassCastException saying "server.A cannot be
> cast
> > to server.A".
> >
> > So I guess the classloaders are different for the A that is returned by
> > Server to the one Client sees. Given both bundles were updated at the
> same
> > time, why is this?
> >
> > I make use of package versioning, if this is important. A's package,
> > server, was not updated, and its version was not incremented. Was the
> code
> > in Client using the old version of server.A?
> >
> > I guess registering A as a service in Client, rather than Server, is
> > opposed to most sample code I see but is it the cause of the problem? If
> > classloaders work on a per package level then it won't help will it?
> >
> > Thanks,
> > Dan
> >
> >
>
>
>
Re: Help me understand ClassCastException after update
Posted by Neil Bartlett <nj...@gmail.com>.
Where does the ClassCastException happen? You said that Client registers the service, does any other bundle access and use the service? If so, what kind of method did you use to obtain the service (eg ServiceTracker, DS, etc)?
Also did you refresh after updating the bundles? Note that bundles cannot really be updated "at the same time", ie there is no atomic multi-bundle update. This is why you need to refresh after a series of updates.
Rgds
Neil
--
Neil Bartlett
Sent from a phone
On Saturday, 30 June 2012 at 17:09, Dan Gravell wrote:
> My OSGi adventure continues...
>
> I have a bundle "Client" and bundle "Server". In Client's activator it
> invokes code in Server, returning an object from Server, let's call it
> server.A. A is defined in Server. Client then registers A as a service:
>
> context.registerService(A.class, (A) serverClass.getA(), new Hashtable());
>
> This works when it is first run.
>
> If I then update Client and Server bundles, the Client Activator gets run
> again. This time I get a ClassCastException saying "server.A cannot be cast
> to server.A".
>
> So I guess the classloaders are different for the A that is returned by
> Server to the one Client sees. Given both bundles were updated at the same
> time, why is this?
>
> I make use of package versioning, if this is important. A's package,
> server, was not updated, and its version was not incremented. Was the code
> in Client using the old version of server.A?
>
> I guess registering A as a service in Client, rather than Server, is
> opposed to most sample code I see but is it the cause of the problem? If
> classloaders work on a per package level then it won't help will it?
>
> Thanks,
> Dan
>
>
Re: Help me understand ClassCastException after update
Posted by Dan Gravell <el...@googlemail.com>.
I think you might be right. Could this be a package versioning problem? A
is in a package that was *not* updated (although its holding bundle was),
and Client's version requirement for Import-Package for A's package had not
changed.
When I do a full VM restart it works fine, the versions are all updated.
Currently I update using OBR:
resolver.deploy(Resolver.START)
If it *is* a packaging problem and I need to increment the version of A's
package and the version requirements on all Import-Package declarations for
A's package... I'm beginning to wonder how on earth one can keep on top of
this. Granted: this is a legacy app converted to OSGi, so it is not
modularised perfectly. But it feels like it will be an enormous pain to
keep on top of package versioning. Hopefully bndtools can help with this...
To make it more confusing: A extends SuperA which is in a separate bundle
again. This separate bundle was also not updated. Furthermore, another
bundle again uses A, as I mentioned to Neil.
Dan
On Sat, Jun 30, 2012 at 5:30 PM, Christian Schneider <
chris@die-schneider.net> wrote:
> The service should not be involved in the problem. I think the client is
> still using the old class that was created by the classloader of the old
> server bundle. As it comes from a different classloader it is of course
> incompatible.
>
> Have you tried uninstalling client and server and then installing the new
> bundles. Then it should work. How exactly do you do the update at the
> moment?
>
> Christian
>
> Am 30.06.2012 18:09, schrieb Dan Gravell:
>
> My OSGi adventure continues...
>>
>> I have a bundle "Client" and bundle "Server". In Client's activator it
>> invokes code in Server, returning an object from Server, let's call it
>> server.A. A is defined in Server. Client then registers A as a service:
>>
>> context.registerService(A.**class, (A) serverClass.getA(), new
>> Hashtable());
>>
>> This works when it is first run.
>>
>> If I then update Client and Server bundles, the Client Activator gets run
>> again. This time I get a ClassCastException saying "server.A cannot be
>> cast
>> to server.A".
>>
>> So I guess the classloaders are different for the A that is returned by
>> Server to the one Client sees. Given both bundles were updated at the same
>> time, why is this?
>>
>> I make use of package versioning, if this is important. A's package,
>> server, was not updated, and its version was not incremented. Was the code
>> in Client using the old version of server.A?
>>
>> I guess registering A as a service in Client, rather than Server, is
>> opposed to most sample code I see but is it the cause of the problem? If
>> classloaders work on a per package level then it won't help will it?
>>
>> Thanks,
>> Dan
>>
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Help me understand ClassCastException after update
Posted by Christian Schneider <ch...@die-schneider.net>.
The service should not be involved in the problem. I think the client is
still using the old class that was created by the classloader of the old
server bundle. As it comes from a different classloader it is of course
incompatible.
Have you tried uninstalling client and server and then installing the
new bundles. Then it should work. How exactly do you do the update at
the moment?
Christian
Am 30.06.2012 18:09, schrieb Dan Gravell:
> My OSGi adventure continues...
>
> I have a bundle "Client" and bundle "Server". In Client's activator it
> invokes code in Server, returning an object from Server, let's call it
> server.A. A is defined in Server. Client then registers A as a service:
>
> context.registerService(A.class, (A) serverClass.getA(), new Hashtable());
>
> This works when it is first run.
>
> If I then update Client and Server bundles, the Client Activator gets run
> again. This time I get a ClassCastException saying "server.A cannot be cast
> to server.A".
>
> So I guess the classloaders are different for the A that is returned by
> Server to the one Client sees. Given both bundles were updated at the same
> time, why is this?
>
> I make use of package versioning, if this is important. A's package,
> server, was not updated, and its version was not incremented. Was the code
> in Client using the old version of server.A?
>
> I guess registering A as a service in Client, rather than Server, is
> opposed to most sample code I see but is it the cause of the problem? If
> classloaders work on a per package level then it won't help will it?
>
> Thanks,
> Dan
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org