felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: OBR and automatic bundle update
Date Mon, 02 Apr 2012 22:25:29 GMT
Yes, you are using the same path when you try to install the first bundle the second time and
this will not work since that path is used as a unique key, which is why it returns the same
bundle id as printed in your session since it did not install anything the second time.

As I suggest you need to have two different paths.

However, this isn't an issue for OBR since it uses an arbitrary location string, so it is
always unique when it does an install, which you can't easily do from the shell, like I said
before.


Matias SM <matias_sm@yahoo.com.ar> wrote:

>
>
>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 A@1.0.0.1
>>>>>>>     ==> this __updates__ the previously deployed A (version
>1.0.0.2)
>>>>>>>
>>>>>>> First "issue", if I run:
>>>>>>> g!deploy -s A@1.0.0.2
>>>>>>>     ==> then OBR executes successfully but A@1.0.0.2 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 A@1.0.0.2
>>>>>>
>>>>>> 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 A@1.0.0.2 is completely uninstalled from the
>framework
>>>>>>> And then:
>>>>>>> g!deploy -s DexA
>>>>>>>     ==> this deployment __fails__ because A@1.0.0.2 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 A@1.0.0.2, OBR should withhold A@1.0.0.1 (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 A@1.0.0.1 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 A@1.0.0.1 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 
>>>>> A@1.0.0.2 is available in the repositories. I don't get how 
>>>>> refreshing would solve the problem since A@1.0.0.2 can't be 
>>>>> installed because A@1.0.0.1 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: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>
>>>
>---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>For additional commands, e-mail: users-help@felix.apache.org

-- 
Sent from my phone, excuse my brevity.
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message