On 6/29/11 15:44, Shamik Bandopadhyay 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.
Well, it seems like you have three options if you wanted to try to use
File Install:
1. Keep the JAR name consistent (e.g., bar.jar instead of
bar-1.0.0.jar), then whatever you drop in will replace what was
there, thus eliminating the need to uninstall. Probably not the
best option, but it would work.
2. Perform two commands, first copy in bar-1.1.0 to the monitored
directory, which shouldn't have much impact on the running system,
then remove bar-1.0.0, which causes File Install to uninstall it
and refresh, thus foo ends up wiring to bar-1.1.0.
3. If you don't like a two-step deploy, then write a shell script
called "deploy" that does the above two steps for you.
Just some thoughts.
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.
The framework implements Bundle (just like a normal bundle), so if you
are creating an instance of the framework, then you can just use the
normal OSGi API to get bundles and perform lifecycle operations on them.
Without a doubt you can implement this from scratch...that's all File
Install or the Felix launcher do too. There is no magic. You just have
to decide if you want to roll your own or use an existing approach. File
Install is one such reasonably simple existing approach.
-> richard
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>
-> 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<[email protected]>
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
