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/07/25 11:18:24 UTC
Uses violations: cascading package version updates?
I have the following bundles:
bundle A {
package a
export-package:a
}
bundle B {
package b.a
package b.b
package b.c
package b.d
package b.e
import-package: a
export-package:b.a;uses:=a,
b.b;uses:=b.a,
b.c;uses:=b.b,
b.d;uses:=b.c,
b.e;uses:=b.d
}
bundle C {
package c
import-package: b.e,
a
}
Now, I update 'a' to a new version. C's required version of a is upped, but
not B's. My understanding is that this would cause a 'uses' clause
violation because C is exposed to the two versions of a direct from A (the
new one) and via B (the old one). And so it proves:
Chain 1:
C [47.1]
import: (&(osgi.wiring.package=a)(version>=1.1.0))
|
export: osgi.wiring.package=a
A [9.1]
Chain 2:
C [47.1]
import: (&(osgi.wiring.package=b.e)(version>=1.0.0))
|
export: osgi.wiring.package=b.e; uses:=a
B [33.0]
import: (&(osgi.wiring.package=a)(version>=1.0.0))
|
export: osgi.wiring.package=a
C [9.0]
Now I don't have any beef with this, it makes sense. There are two versions
of 'a' in the class space of C.
Oddly (in my eyes anyway) if I merely restart Felix then it all appears to
work. Surely if B was wired to version 1.0.0 of A it should remain so?
Anyway, that's not really my question...
My question is how to manage this.
The only way I've found to avoid the uses constraint violation is to
increase the version requirement to 'a' of every package that uses 'a',
then increase version requirements for all those users of 'a' and versions
of the packages that use those packages that use 'a' and so on. This
doesn't scale in any non-trivial case so I'm assuming I'm doing something
very wrong here.
Hoping for some insight...
Dan
Re: Uses violations: cascading package version updates?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 7/25/12 09:18 , Dan Gravell wrote:
>> If you refresh A after updating it, then both B and C should be refreshed
>> too since they depend on it. Then everyone will point to the same version
>> of 'a'. No?
>>
> Errr... I'm embarrassed to say I don't know.
>
> I'm using OBR and deploying a bunch of bundles (of which A, B and C are a
> subset) from a repository.xml. Basically I use a filter string to specify
> all of my bundles and then say deploy(START). _Then_ I do the refresh, but
> the uses constraints violation has already happened by then (when I did the
> deploy). Is there a better way? Should I take each resource and deploy,
> refresh, deploy, refresh? I thought refresh was supposed to be grouped to
> some extent?
Yeah, OBR doesn't do this automatically and it should, see:
https://issues.apache.org/jira/browse/FELIX-3566
I'll probably go ahead and apply the above patch to OBR, but I'm not
sure when it will actually be released. In the meantime, you can simply
refresh without specifying any bundles after performing an OBR deploy.
Refreshing without specifying any target bundles will only refresh
bundles that were updated or uninstalled.
If you need to do multiple deploy operations, then yeah it is better to
do the refresh at the end.
-> richard
>
> Dan
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Uses violations: cascading package version updates?
Posted by Dan Gravell <el...@googlemail.com>.
On Wed, Jul 25, 2012 at 4:07 PM, Richard S. Hall <he...@ungoverned.org>wrote:
> On 7/25/12 10:57 , Dan Gravell wrote:
>
>> The best way to do this sort of stuff is to create a management agent that
>>> records, deploys, and reinstates the proper state of your application
>>> after
>>> deployment operations.
>>>
>>
>> So would the agent record the current state for each bundle, stop each
>> bundle, update it, refresh, then restart?
>>
>
> Pretty much.
Ok! That works. I was a little intimidated by what you mean by 'management
agent' but after several tries I got this working... at least with my
current batch of updates. Here's what I do... I would appreciate a sanity
review.
https://gist.github.com/3177368
Some notes...
The 'resourcesToUpdateExceptUpdater' is required because the updater
bundle, where this code lives, cannot be stopped while this code works.
That's because the bundle context becomes invalid. *Edit* actually, I now
use the system bundle's context for some of this work... maybe I can use
that instead?
The 'sendUiStoppingMessageAndBlock' stuff is to instruct the UI to begin
polling for the restart of the user interface after update. The Semaphore
should return very quickly. It has to be a semaphore because the update
sent to the UI occurs in a different thread - the UI is a comet web based
UI.
Dan
Re: Uses violations: cascading package version updates?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 7/25/12 10:57 , Dan Gravell wrote:
> Thanks Richard...
>
> On Wed, Jul 25, 2012 at 3:52 PM, Richard S. Hall <he...@ungoverned.org>wrote:
>> Would not be a good idea. Synchronous listeners are not supposed to change
>> the state of the bundle they receive an event about since the framework is
>> often in the middle of some operation on them.
>>
> Ok, makes sense.
>
>
>> The best way to do this sort of stuff is to create a management agent that
>> records, deploys, and reinstates the proper state of your application after
>> deployment operations.
>
> So would the agent record the current state for each bundle, stop each
> bundle, update it, refresh, then restart?
Pretty much.
>
> If there are references for the best way of doing this do let me know (to
> avoid cluttering the mailing list!).
Not really, although you could look at Apache Ace...it is a management
agent too, but it uses a slightly different approach than what we are
discussing here.
-> richard
>
> Dan
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Uses violations: cascading package version updates?
Posted by Dan Gravell <el...@googlemail.com>.
Thanks Richard...
On Wed, Jul 25, 2012 at 3:52 PM, Richard S. Hall <he...@ungoverned.org>wrote:
>
> Would not be a good idea. Synchronous listeners are not supposed to change
> the state of the bundle they receive an event about since the framework is
> often in the middle of some operation on them.
>
Ok, makes sense.
> The best way to do this sort of stuff is to create a management agent that
> records, deploys, and reinstates the proper state of your application after
> deployment operations.
So would the agent record the current state for each bundle, stop each
bundle, update it, refresh, then restart?
If there are references for the best way of doing this do let me know (to
avoid cluttering the mailing list!).
Dan
Re: Uses violations: cascading package version updates?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 7/25/12 10:38 , Dan Gravell wrote:
> On Wed, Jul 25, 2012 at 2:27 PM, Richard S. Hall <he...@ungoverned.org>wrote:
>
>> p.s. The constraint violation happens during deploy, I imagine, because
>> you are leaving your bundles in an active state, so OBR tries to restart
>> them (or you are telling OBR to start them when calling deploy()). The the
>> OBR patch I referenced, this will help since it refreshes before
>> restarting, but OBR is not intended to be a sophisticated management agent,
>> so you might need to write something better.
>>
> Ok, so the important thing here is that the refresh has to be done between
> update and start, correct?
>
> Could this be done with a SynchronousBundleListener? E.g. decide which
> bundles are being updated, then listen for the update event and when it
> occurs perform a refresh on that bundle?
Would not be a good idea. Synchronous listeners are not supposed to
change the state of the bundle they receive an event about since the
framework is often in the middle of some operation on them.
The best way to do this sort of stuff is to create a management agent
that records, deploys, and reinstates the proper state of your
application after deployment operations.
-> richard
>
> This would happen multiple times, for each bundle that is updated. I could
> potentially group all the updated bundles together given by taking a look
> at the state changes and trying to collect the bundles together somehow. It
> looks like resolveBundleRevision occurs before STARTING.
>
> Dan
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Uses violations: cascading package version updates?
Posted by Dan Gravell <el...@googlemail.com>.
On Wed, Jul 25, 2012 at 2:27 PM, Richard S. Hall <he...@ungoverned.org>wrote:
> p.s. The constraint violation happens during deploy, I imagine, because
> you are leaving your bundles in an active state, so OBR tries to restart
> them (or you are telling OBR to start them when calling deploy()). The the
> OBR patch I referenced, this will help since it refreshes before
> restarting, but OBR is not intended to be a sophisticated management agent,
> so you might need to write something better.
>
Ok, so the important thing here is that the refresh has to be done between
update and start, correct?
Could this be done with a SynchronousBundleListener? E.g. decide which
bundles are being updated, then listen for the update event and when it
occurs perform a refresh on that bundle?
This would happen multiple times, for each bundle that is updated. I could
potentially group all the updated bundles together given by taking a look
at the state changes and trying to collect the bundles together somehow. It
looks like resolveBundleRevision occurs before STARTING.
Dan
Re: Uses violations: cascading package version updates?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 7/25/12 09:18 , Dan Gravell wrote:
>> If you refresh A after updating it, then both B and C should be refreshed
>> too since they depend on it. Then everyone will point to the same version
>> of 'a'. No?
>>
> Errr... I'm embarrassed to say I don't know.
>
> I'm using OBR and deploying a bunch of bundles (of which A, B and C are a
> subset) from a repository.xml. Basically I use a filter string to specify
> all of my bundles and then say deploy(START). _Then_ I do the refresh, but
> the uses constraints violation has already happened by then (when I did the
> deploy). Is there a better way? Should I take each resource and deploy,
> refresh, deploy, refresh? I thought refresh was supposed to be grouped to
> some extent?
p.s. The constraint violation happens during deploy, I imagine, because
you are leaving your bundles in an active state, so OBR tries to restart
them (or you are telling OBR to start them when calling deploy()). The
the OBR patch I referenced, this will help since it refreshes before
restarting, but OBR is not intended to be a sophisticated management
agent, so you might need to write something better.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Uses violations: cascading package version updates?
Posted by Dan Gravell <el...@googlemail.com>.
>
> If you refresh A after updating it, then both B and C should be refreshed
> too since they depend on it. Then everyone will point to the same version
> of 'a'. No?
>
Errr... I'm embarrassed to say I don't know.
I'm using OBR and deploying a bunch of bundles (of which A, B and C are a
subset) from a repository.xml. Basically I use a filter string to specify
all of my bundles and then say deploy(START). _Then_ I do the refresh, but
the uses constraints violation has already happened by then (when I did the
deploy). Is there a better way? Should I take each resource and deploy,
refresh, deploy, refresh? I thought refresh was supposed to be grouped to
some extent?
Dan
Re: Uses violations: cascading package version updates?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 7/25/12 05:18 , Dan Gravell wrote:
> I have the following bundles:
>
> bundle A {
> package a
>
> export-package:a
> }
>
> bundle B {
> package b.a
> package b.b
> package b.c
> package b.d
> package b.e
>
> import-package: a
> export-package:b.a;uses:=a,
> b.b;uses:=b.a,
> b.c;uses:=b.b,
> b.d;uses:=b.c,
> b.e;uses:=b.d
> }
>
> bundle C {
> package c
>
> import-package: b.e,
> a
> }
>
> Now, I update 'a' to a new version. C's required version of a is upped, but
> not B's. My understanding is that this would cause a 'uses' clause
> violation because C is exposed to the two versions of a direct from A (the
> new one) and via B (the old one). And so it proves:
>
> Chain 1:
> C [47.1]
> import: (&(osgi.wiring.package=a)(version>=1.1.0))
> |
> export: osgi.wiring.package=a
> A [9.1]
>
> Chain 2:
> C [47.1]
> import: (&(osgi.wiring.package=b.e)(version>=1.0.0))
> |
> export: osgi.wiring.package=b.e; uses:=a
> B [33.0]
> import: (&(osgi.wiring.package=a)(version>=1.0.0))
> |
> export: osgi.wiring.package=a
> C [9.0]
>
> Now I don't have any beef with this, it makes sense. There are two versions
> of 'a' in the class space of C.
>
> Oddly (in my eyes anyway) if I merely restart Felix then it all appears to
> work. Surely if B was wired to version 1.0.0 of A it should remain so?
> Anyway, that's not really my question...
>
> My question is how to manage this.
>
> The only way I've found to avoid the uses constraint violation is to
> increase the version requirement to 'a' of every package that uses 'a',
> then increase version requirements for all those users of 'a' and versions
> of the packages that use those packages that use 'a' and so on. This
> doesn't scale in any non-trivial case so I'm assuming I'm doing something
> very wrong here.
>
> Hoping for some insight...
If you refresh A after updating it, then both B and C should be
refreshed too since they depend on it. Then everyone will point to the
same version of 'a'. No?
-> richard
>
> Dan
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org