On 6/19/12 08:43 , Dan Gravell wrote:
Hi. I've converted an application to run on OSGi and it works nicely inside
Felix. I've got to the point where I need to consider the user's experience
with installation and first-use of my product.
The product itself is a consumer oriented piece of software which is
installable on the user's computer. Therefore, the 'profile' here is an
application installed many times. Because this is a consumer piece of
software, installation -> start needs to be one step. For Windows and Linux
users there is an installer, built using IzPack.
Currently, the installer installs all the bundles into a bundle/ directory
and Felix does its auto deploy thing over that directory, auto deploying
each bundle. This works, but only the very first time the application is
installed.
If the user happens to install a later version over the top, you get
multiple JARs for the same bundle, because the version number is in the JAR
file. This doesn't work with the auto deployer which appears to use the
bundle location as the identifying characteristic of a bundle, rather than
its symbolic name. I'm not why it does that, but anyway it means I get all
sorts of problems with multiple instances of Jetty running. I notice the
felix-cache has different bundleN entries for the same bundle.
It does that because that's all it has. To get the symbolic name, it
would have to crack open the JAR file and parse its manifest to get its
symbolic name.
Later on, in-app update provisions updated versions of the bundle from a
source online. This is just my code downloading bundles and installing
them. Therefore, different versions of the bundle will end up in
felix-cache. Later re-installations of the product may mean even more
versions lying about. This scares me! This seems a fairly flawed approach
so I'm beginning to wonder whether I understand the implications of Felix
auto deploy and updating in the way I am suggesting.
I'm wondering if I'm approaching this in completely the wrong way. I can
see other solutions for provisioning (in the sense of finding, downloading,
resolving and installing bundles) such as OBR. Would it be better to use
that?
Has anyone else got any advice or done something similar?
You overestimate the level of sophistication of auto-deploy. It was only
intended to get you going, mostly for development purposes. It is in no
way an attempt to implement a management agent. You need to do that
yourself or use something else like OBR (which is also fairly simple and
may or may not work exactly like you need).
However, you might be able to get close using auto-deploy if you made a
custom launcher that created/recreated the auto-deploy directory each
time you started the framework and then set the auto-deploy actions to
"install,update,delete" which would install any new bundles, update and
existing bundles, and uninstall any missing bundles.
-> richard
Thanks,
Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
