Mailing-List: contact users-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@felix.apache.org
Received-SPF: pass (athena.apache.org: domain of shamikb@gmail.com designates
 209.85.210.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <BANLkTi=p6YNhjSN6pfrimcZZ-HrDgR5iZg@mail.gmail.com>
References: <BANLkTikYvAZ8vmVHbX_1OUKVvc1cuRHP8Q@mail.gmail.com>
	<4E0B749A.6050104@ungoverned.org>
	<BANLkTi=p6YNhjSN6pfrimcZZ-HrDgR5iZg@mail.gmail.com>
Date: Wed, 29 Jun 2011 12:57:30 -0700
Message-ID: <BANLkTimq6c6dKZgjpPEJJJ7f+FcwJ9pW6w@mail.gmail.com>
Subject: Re: Question on bundle management best practises
From: Shamik Bandopadhyay <shamikb@gmail.com>
To: users@felix.apache.org
Content-Type: multipart/alternative; boundary=000e0cd20abad5951b04a6df31a9

--000e0cd20abad5951b04a6df31a9
Content-Type: text/plain; charset=ISO-8859-1

Just to add to my previous reply, I realized the other way to do is to drop
all your bundles in the deploy folder instead of installing them through
karaf console or web console. In that way you can install or uninstall a
bundle by dropping and deleting respectively. But not sure how to refresh
specific bundle(s)

On Wed, Jun 29, 2011 at 12:44 PM, Shamik Bandopadhyay <shamikb@gmail.com>wrote:

> I did take a look into this when I was trying the hot deploy exercise. My
> understanding is, this is property which felix file-install internally uses
> to perform hot deploy. It polls the "deploy" directory and installs any
> newly found bundle, uninstalls when the bundle is reomoved.
>
> What I'm trying to figure looks a little beyond the scope of felix file
> install. If you recall yesterday's discussion on hot deploy of a different
> version of a bundle (for/bar example), I tried few things and understood the
> behaviour. To refresh, my container has foo-1.0.0 which has a dependency on
> bar-1.0.0. Successful, hot deploying a bar-1.1.0 requires the following
> step.
>
> 1. Drop the bar-1.1.0 in deploy folder. Felix file install poller will pick
> it up and install it.
> 2. Uninstall bar-1.0.0 from the container
> 3. Refresh foo-1.0.0. so that it'll refer to bar-1.1.0
>
> The part which I'm struggling is to deal with step 2 and 3. I don't think
> felix file install allows you to do so. Doing it through web console is an
> option, but I was more looking into an external script which can do perform
> the above steps by calling some API / script provided by OSGi / felix.
>
> Another thing I've noticed is OSGi core framework Bundle interface provides
> the lifecycle methods. Maybe, I can create a bundle, expose a service which
> will use this API to perform the lifecycle operations. The referenced bundle
> lists, which needs to be refreshed, can be automated through spring app
> context.
>
> This prompted me to post the question to understand what's the best
> practise being followed in this particular aspect.
>
> -Thanks
>
> On Wed, Jun 29, 2011 at 11:53 AM, Richard S. Hall <heavy@ungoverned.org>wrote:
>
>> It seems like File Install should allow you to do things.
>>
>>    http://felix.apache.org/site/**apache-felix-file-install.html<http://felix.apache.org/site/apache-felix-file-install.html>
>>
>> -> richard
>>
>>
>> On 6/29/11 13:37, Shamik Bandopadhyay wrote:
>>
>>> Hi,
>>>
>>>   I'm trying to understand the best practises or ways to manage bundles
>>> in
>>> an OSGi environment. I ran into this when I was trying to do a hot
>>> deployment . As part of the process, I had to drop the new version of the
>>> bundle in the deploy folder, uninstall the old version from OSGi
>>> container
>>> and refresh the bundles who has a reference to this one.
>>>
>>> Now, one easy way to achieve this is to use the web console. But I'm
>>> looking
>>> into the option of using some sort of external script which will allow me
>>> to
>>> uninstall and refresh bundles. The available commands are accessible only
>>> through the karaf console.
>>>
>>> Is there a way to execute these commands (uninstall, refresh) from an
>>> external script ? What are best practises people follow in this regard ?
>>>
>>> I'll appreciate if someone can share their experience.
>>>
>>> - Thanks
>>>
>>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<users-unsubscribe@felix.apache.org>
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>

--000e0cd20abad5951b04a6df31a9--