Perhaps that message was too brief... ;-)
On 6/29/11 7:41 PM, [email protected] wrote:
Sent from my cell, please excuse my brevity. Mike Van
Shamik Bandopadhyay<[email protected]> wrote:
Thanks Richard, I just ran a quick test to verify the file-install refresh.
It works great. So I guess, I can safely use the deploy folder to install /
uninstall w/o worrying about refresh. That clarifies my doubt.
Thanks again, appreciate your help.
On Wed, Jun 29, 2011 at 1:04 PM, Richard S. Hall<[email protected]>wrote:
On 6/29/11 15:57, Shamik Bandopadhyay wrote:
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)
Sorry, my assumption was all bundles are installed the same way. It is not
a good idea to try to have to different management agents managing the same
set of bundles.
Regarding refreshing, I think File Install automatically does a refresh on
uninstall or update.
-> richard
On Wed, Jun 29, 2011 at 12:44 PM, Shamik Bandopadhyay<[email protected]**
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<[email protected]>*
*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>
<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.**apac**he.org<http://apache.org>
<users-unsubscribe@**felix.apache.org<[email protected]>
For additional commands, e-mail: [email protected]
------------------------------**------------------------------**---------
To unsubscribe, e-mail:
users-unsubscribe@felix.**apache.org<[email protected]>
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
