On 02/04/12 18:32, Richard S. Hall wrote:
On 4/2/12 17:05, Matias SM wrote:
On 02/04/12 17:31, Richard S. Hall wrote:
On 4/2/12 15:42, Matias SM wrote:
Thank you for your answer Richard, please see my comments inline:
On 02/04/12 14:40, Richard S. Hall wrote:
On 4/1/12 12:32, Matias SM wrote:
Hi everybody,
I'm using OBR to help me resolve bundle deployment. Everything
works great and as expected but I'm facing a situation I don't
know how to solve.
---------------------------------------
Here is my test scenario:
I have the following bundles in an OBR repository:
* SymbolicName: A | Bundle-Version: 1.0.0.1 | exports: (package:
"p.a" version: 1)
* SymbolicName: A | Bundle-Version: 1.0.0.2| exports: (package:
"p.a" version: 1)
* SymbolicName: DA | Bundle-Version: 1| depends: (package: "p.a"
version: [1 , 2) )
* SymbolicName: DexA | Bundle-Version: 1| depends: (package:
"p.a" version: [1 , 2) ) and (bundle: "A" version: [1.0.0.2,
1.0.0.2] )
Then my test runs as follows:
g! deploy -s DA
==> this also deploys A version 1.0.0.2 (I guess because it
is the "newer" bundle that exports "pa" version 1)
g! deploy -s [email protected]
==> this __updates__ the previously deployed A (version 1.0.0.2)
First "issue", if I run:
g!deploy -s [email protected]
==> then OBR executes successfully but [email protected] is not
installed (since there is an "updated" version of it already
resolved). I know this is the expected behavior, but I would like
to be able to deploy [email protected]
It seems like OBR should probably be performing a refresh after it
does an update, so there isn't an older version hanging around.
Second (and worse) issue, if I now run:
g!refresh
==> so [email protected] is completely uninstalled from the framework
And then:
g!deploy -s DexA
==> this deployment __fails__ because [email protected] can't be
reinstalled in the framework!!
Not sure why that would be. Are you seeing some sort of error?
I think that the "problem" here is that to be able to update the
dependency again to [email protected], OBR should withhold [email protected] (that
was deployed in step 2). I don't think this should be a valid thing
to do.
Still seems like it should be possible for OBR to deploy DexA by
updating 1.0.0.1 to 1.0.0.2.
Wouldn't that break the request that bundle [email protected] is deployed
(step 2 in test)?
No. OBR doesn't keep some set of "desired deployed bundles" or
anything like that...it isn't that sophisticated. It simply tries to
deploy bundles given the current context of the framework. So, the
fact that you told OBR to deploy foo in some previous request has no
bearing on subsequent requests other than the fact that it impacts the
set of installed bundles from which it starts to perform its
operation...but that is no different than if you installed a given
bundle manually and didn't use OBR at all.
Ok, now I understand your point. Though I can see that this behavior may
lead to some issues if bundle [email protected] has some kind of functionality
other than defining classes to export.
---------------------------------------
In the OBR project web page [1] can be read:
"OBR's deployment algorithm appears simple at first glance, but
it is actually somewhat complex due to the nature of deploying
independently developed bundles. For example, in an ideal world,
if an update for a bundle is made available, then updates for all
of the bundles satisfying its dependencies are also made
available. Unfortunately, this may not be the case, thus the
deployment algorithm might have to install new bundles during an
update to satisfy either new dependencies or updated dependencies
that can no longer be satisfied by existing local bundles. In
response to this type of scenario, ___the OBR deployment
algorithm tries to favor updating existing bundles, if possible,
as opposed to installing new bundles to satisfy dependencies.____"
I don't fully understand this explanation but I get that the
described behavior is as intended.
Not sure which part you don't understand.
What I don't understand is how the need to favor updating existing
bundles is concluded from the problem stated in the previous
sentences. It is not clear to me the relation between the need to
"install new bundles during an update" and the algorithm that
"tries to favor updating existing bundles instead of installing new
ones".
Ok, I see your point now. No, the one doesn't necessarily follow the
other. The reason to favor updating existing bundles is the reason I
gave below.
My questions are:
1- Is there a way to force the installation of different bundle
versions (instead of the update of "older" ones) when deploying
through OBR?
No, I don't think so.
2- What kind of issues may this behavior (installation of
different versions) rise? (this is not considering the "problem"
of having a lot of bundles installed)
Lots of providers is generally a bad thing since it creates many
partitions in the overall class spaces of the bundles, meaning
that collaboration among them becomes limited to little islands of
bundles that happen to be using the same same providers.
I understand. But updating the bundles may lead to the problem I
presented, where a bundle can't be resolved despite all necessary
resources are available.
I know that this behavior is not defined by OBR but OSGi in
general. But I don't understand why once a bundle is updated, an
older version of it can't be re-installed so a bundle depending on
it can be successfully resolved. I think that allowing this may
help to avoid problems like the one presented (note that I have
almost no experience with OSGi so maybe I'm talking nonsenses). Do
you know the reason to "forbid" the installation of an old version
of an updated bundle?
You can re-install older versions. OBR will *only* update an
existing bundle if it still satisfies all existing constraints. If
not, then it will install another version, which will then give you
both versions installed at the same time.
There is no rule forbidding the installation of an old version of an
updated bundle. More than likely, we just aren't speaking the same
language. Perhaps you can open a JIRA issue with a simple example
recreating the scenario where you cannot install an older version of
an updated bundle. If so, I'll take a look.
mmm... but I can't do that even directly from the felix shell (at
least in Felix bundle version 4.0.2).
I will create an issue as you recommend, but you can recreate the
scenario simply doing:
- Installing a bundle
- Update it with another bundle differing only in its Bundle-Version
(I tested with just a qualifier change)
- A try to install again the first bundle will return the original
bundle id (i.e. the updated bundle's id) and the updated version will
remain
That's because you are using the same location string to install it, I
suppose and this is a unique key. You need to use a new location
string (which by default is the URL you use for your bundle),
otherwise you get back the existing bundle. It is not easy to use a
different location string from the shell, but is possible from the
OSGi API (i.e., BundleContext.installBundle(String, InputStream)).
You can do this to see it work: Take your little scenario described in
the paragraph above and before running the framework make a copy of
your initial bundle (just give it a slightly different name), then:
1. Install bundle copy 1.
2. Update it to a bundle differing only in Bundle-Version.
3. Install bundle copy 2.
Voila!
I'm not sure I followed you, but I don't think this is the issue here.
I'm using different files for each bundle. Here is a more verbose output
of my test:
g! install file:/somepath/test.osgi.bundle_1.0.0.201203312048.jar
Bundle ID: 402
g! update 402 file:/somepath/test.osgi.bundle_1.0.0.201203312052.jar
g! install file:/somepath/test.osgi.bundle_1.0.0.201203312048.jar
Bundle ID: 402
Note that I use 2 different files for the update
(test.osgi.bundle_1.0.0.201203312048.jar and
test.osgi.bundle_1.0.0.201203312052.jar).
If what you mean is that the first (non-updated) version has the same
path that the one that I'm trying to install later on, that is
reasonable since they both correspond to the same version/bundle. In
that case the issue remains, if I need to re-install the bundle
test.osgi.bundle_1.0.0.201203312048.jar to resolve another one, I will
not be able to.
-> richard
I thought it was the intended behavior.
-> richard
Note that while I'm using the shell to run my tests, my intention
is to use the OBR API in my code. So the "solution" may be
available only in the API.
Sorry the mail got so long but I wanted to state my problem as
clear as possible.
Thank you for taking the time to read and to answer!
Still not clear to me what the actual issue is or the solution,
but at a minimum OBR should probably refresh after update.
The issue is that the DexA bundle can't be resolved despite
[email protected] is available in the repositories. I don't get how
refreshing would solve the problem since [email protected] can't be
installed because [email protected] is recognized as an update of it.
Thank you again for taking the time to respond to me!
-> richard
Kind regards
[1]
http://felix.apache.org/site/apache-felix-osgi-bundle-repository.html#ApacheFelixOSGiBundleRepository-OBRServiceAPI
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
