You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Dan Gravell <el...@googlemail.com> on 2012/06/19 14:43:07 UTC
Guidance on using auto deploy, OBR or something else for initial
provisioning and updates
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.
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?
Thanks,
Dan
Re: Guidance on using auto deploy, OBR or something else for initial
provisioning and updates
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 6/20/12 12:30 , Marcel Offermans wrote:
> On Jun 20, 2012, at 18:23 , Richard S. Hall wrote:
>> On 6/20/12 12:15 , Dan Gravell wrote:
>>> On Wed, Jun 20, 2012 at 4:06 PM, Richard S. Hall <he...@ungoverned.org>wrote:
>>>
>>>> (make sure you refresh too)
>>>>
>>> The Resolver doesn't refresh after deploy? Well I suppose that's a
>>> different conceptual level of behaviour so ok, thanks.
>> Looking at the code quickly, it looks like it doesn't...it probably should if it updates a bundle...perhaps you can open an RFE issue in JIRA for this…
> Question remains if it should refresh automatically. Suppose you want to do multiple deploys sequentially and when all are done, do a refresh. So an option to refresh would be nice, but I would make that explicit.
Sure, but performing a refresh automatically is probably better than not
performing one at all. :-)
Especially since it does automatically restart any bundles that were
updated if they were previously active...
-> richard
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Guidance on using auto deploy, OBR or something else for initial
provisioning and updates
Posted by Dan Gravell <el...@googlemail.com>.
Thanks all. I added it to JIRA anyway so that a decision can be made
through that 'official', formalised channel.
https://issues.apache.org/jira/browse/FELIX-3566
Dan
On Wed, Jun 20, 2012 at 5:30 PM, Marcel Offermans <
marcel.offermans@luminis.nl> wrote:
> On Jun 20, 2012, at 18:23 , Richard S. Hall wrote:
> > On 6/20/12 12:15 , Dan Gravell wrote:
> >> On Wed, Jun 20, 2012 at 4:06 PM, Richard S. Hall <heavy@ungoverned.org
> >wrote:
> >>
> >>> (make sure you refresh too)
> >>>
> >> The Resolver doesn't refresh after deploy? Well I suppose that's a
> >> different conceptual level of behaviour so ok, thanks.
> >
> > Looking at the code quickly, it looks like it doesn't...it probably
> should if it updates a bundle...perhaps you can open an RFE issue in JIRA
> for this…
>
> Question remains if it should refresh automatically. Suppose you want to
> do multiple deploys sequentially and when all are done, do a refresh. So an
> option to refresh would be nice, but I would make that explicit.
>
> Greetings, Marcel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Guidance on using auto deploy, OBR or something else for initial provisioning and updates
Posted by Marcel Offermans <ma...@luminis.nl>.
On Jun 20, 2012, at 18:23 , Richard S. Hall wrote:
> On 6/20/12 12:15 , Dan Gravell wrote:
>> On Wed, Jun 20, 2012 at 4:06 PM, Richard S. Hall <he...@ungoverned.org>wrote:
>>
>>> (make sure you refresh too)
>>>
>> The Resolver doesn't refresh after deploy? Well I suppose that's a
>> different conceptual level of behaviour so ok, thanks.
>
> Looking at the code quickly, it looks like it doesn't...it probably should if it updates a bundle...perhaps you can open an RFE issue in JIRA for this…
Question remains if it should refresh automatically. Suppose you want to do multiple deploys sequentially and when all are done, do a refresh. So an option to refresh would be nice, but I would make that explicit.
Greetings, Marcel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Guidance on using auto deploy, OBR or something else for initial
provisioning and updates
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 6/20/12 12:15 , Dan Gravell wrote:
> On Wed, Jun 20, 2012 at 4:06 PM, Richard S. Hall <he...@ungoverned.org>wrote:
>
>> (make sure you refresh too)
>>
> The Resolver doesn't refresh after deploy? Well I suppose that's a
> different conceptual level of behaviour so ok, thanks.
Looking at the code quickly, it looks like it doesn't...it probably
should if it updates a bundle...perhaps you can open an RFE issue in
JIRA for this...
> So, you have to just look for the "version" prefix and largely ignore the
>> X.Y...
>>
> Ok, already done this. The code for this workaround -
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=372656 - largely works.
> However, there's no coping with versions. From what I can see the version
> directory is not numbered after the bundle version, it's numbered after the
> revision that has been applied in this Felix instance. So how do I know
> which version to use? Can I just use the latest?
You would just use the latest, but if you always do a refresh after an
update, there should only ever be one versionX.Y directory, so you just
use the one that exists.
-> richard
>
> Dan
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Guidance on using auto deploy, OBR or something else for initial
provisioning and updates
Posted by Dan Gravell <el...@googlemail.com>.
On Wed, Jun 20, 2012 at 4:06 PM, Richard S. Hall <he...@ungoverned.org>wrote:
> (make sure you refresh too)
>
The Resolver doesn't refresh after deploy? Well I suppose that's a
different conceptual level of behaviour so ok, thanks.
So, you have to just look for the "version" prefix and largely ignore the
> X.Y...
>
Ok, already done this. The code for this workaround -
https://bugs.eclipse.org/bugs/show_bug.cgi?id=372656 - largely works.
However, there's no coping with versions. From what I can see the version
directory is not numbered after the bundle version, it's numbered after the
revision that has been applied in this Felix instance. So how do I know
which version to use? Can I just use the latest?
Dan
Re: Guidance on using auto deploy, OBR or something else for initial
provisioning and updates
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 6/20/12 10:40 , Dan Gravell wrote:
> On Wed, Jun 20, 2012 at 3:33 PM, Richard S. Hall <he...@ungoverned.org>wrote:
>
>> On 6/20/12 10:20 , Dan Gravell wrote:
>>
>>> That's ok - I know we are using Felix. And this worked before I used OBR,
>>> because bundle.getLocation would return a file URL. However the OBR URL
>>> returned by getLocation is totally abstracted. How might I find the
>>> location in the bundle cache?
>>>
>> Just to be clear, we are talking about two different locations:
>>
>> 1. The bundle.getLocation() method was returning the original location
>> from which the framework made a copy of the bundle to install into
>> its bundle cache.
>> 2. The bundle in the bundle cache is the copy made from the original
>> location above.
>>
>> So, in your old solution you were getting it from the source. Now you will
>> be getting it from the copy.
>
> Hmmm, interesting. So it sounds like updating that bundle (from a different
> source) wouldn't work because it would just point back to the original
> location. I thought I'd observed it work, but maybe my test wasn't
> satisfactory...
Yes, that wouldn't work. The location never changes, so it will always
point to the original, not any subsequent updates.
>> Well, you can configure the location of the bundle cache using the
>> org.osgi.framework.storage property, so you can look up this property.
>> After that, then yes you'll need to know the structure of the cache to find
>> the bundle you want. You shouldn't need to read any of the files, though,
>> you just need to know the structure so you can find what you want.
>>
> Of course! I forgot about the property. I thought I would need to read
> bundle.info though so I can find out which bundle ("bundle0" - "bundleNN")
> is the one I want to return the location for.
Technically, you could. But the N in "bundleN" is the bundle ID, so it
is pretty straightforward to determine which bundle ID you want. The
main trick is that the "versionX.Y" directory that contains the bundle
JAR file will change after an update (make sure you refresh too). So,
you have to just look for the "version" prefix and largely ignore the X.Y...
-> richard
>
>
>> You could hide all of this behind some method, but it is still ugly...
>>
> Agreed!
>
> Dan
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Guidance on using auto deploy, OBR or something else for initial
provisioning and updates
Posted by Dan Gravell <el...@googlemail.com>.
On Wed, Jun 20, 2012 at 3:33 PM, Richard S. Hall <he...@ungoverned.org>wrote:
> On 6/20/12 10:20 , Dan Gravell wrote:
>
>> That's ok - I know we are using Felix. And this worked before I used OBR,
>> because bundle.getLocation would return a file URL. However the OBR URL
>> returned by getLocation is totally abstracted. How might I find the
>> location in the bundle cache?
>>
>
> Just to be clear, we are talking about two different locations:
>
> 1. The bundle.getLocation() method was returning the original location
> from which the framework made a copy of the bundle to install into
> its bundle cache.
> 2. The bundle in the bundle cache is the copy made from the original
> location above.
>
> So, in your old solution you were getting it from the source. Now you will
> be getting it from the copy.
Hmmm, interesting. So it sounds like updating that bundle (from a different
source) wouldn't work because it would just point back to the original
location. I thought I'd observed it work, but maybe my test wasn't
satisfactory...
> Well, you can configure the location of the bundle cache using the
> org.osgi.framework.storage property, so you can look up this property.
> After that, then yes you'll need to know the structure of the cache to find
> the bundle you want. You shouldn't need to read any of the files, though,
> you just need to know the structure so you can find what you want.
>
Of course! I forgot about the property. I thought I would need to read
bundle.info though so I can find out which bundle ("bundle0" - "bundleNN")
is the one I want to return the location for.
> You could hide all of this behind some method, but it is still ugly...
>
Agreed!
Dan
Re: Guidance on using auto deploy, OBR or something else for initial
provisioning and updates
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 6/20/12 10:20 , Dan Gravell wrote:
> On Wed, Jun 20, 2012 at 3:10 PM, Richard S. Hall <he...@ungoverned.org>wrote:
>
>> The bundle, as provided by OBR, has a location of "obr://[bundle
>>> name]/[some string]". Jetty doesn't know how to interpret that. Is there
>>> any way of finding the filesystem location from the OBR provided bundle?
>>>
>> No, there is no way of determining it other than knowing the bundle cache
>> format of the framework and calculating it yourself.
>
> That's ok - I know we are using Felix. And this worked before I used OBR,
> because bundle.getLocation would return a file URL. However the OBR URL
> returned by getLocation is totally abstracted. How might I find the
> location in the bundle cache?
Just to be clear, we are talking about two different locations:
1. The bundle.getLocation() method was returning the original location
from which the framework made a copy of the bundle to install into
its bundle cache.
2. The bundle in the bundle cache is the copy made from the original
location above.
So, in your old solution you were getting it from the source. Now you
will be getting it from the copy.
>
> Other than explicitly finding it on the filesystem - new
> File("felix-cache") and going through the bundle.infos... or is that what
> you meant? If so, this might be a show-stopper unless I can think of some
> other way.
Well, you can configure the location of the bundle cache using the
org.osgi.framework.storage property, so you can look up this property.
After that, then yes you'll need to know the structure of the cache to
find the bundle you want. You shouldn't need to read any of the files,
though, you just need to know the structure so you can find what you want.
Still sucks, I know, but this is a pretty crappy thing to do in the
first place. ;-)
Some frameworks (hint: Equinox) provide some utility to do this, but we
never have. You could hide all of this behind some method, but it is
still ugly...
-> richard
>
> Dan
>
Re: Guidance on using auto deploy, OBR or something else for initial
provisioning and updates
Posted by Dan Gravell <el...@googlemail.com>.
On Wed, Jun 20, 2012 at 3:10 PM, Richard S. Hall <he...@ungoverned.org>wrote:
> The bundle, as provided by OBR, has a location of "obr://[bundle
>> name]/[some string]". Jetty doesn't know how to interpret that. Is there
>> any way of finding the filesystem location from the OBR provided bundle?
>>
> No, there is no way of determining it other than knowing the bundle cache
> format of the framework and calculating it yourself.
That's ok - I know we are using Felix. And this worked before I used OBR,
because bundle.getLocation would return a file URL. However the OBR URL
returned by getLocation is totally abstracted. How might I find the
location in the bundle cache?
Other than explicitly finding it on the filesystem - new
File("felix-cache") and going through the bundle.infos... or is that what
you meant? If so, this might be a show-stopper unless I can think of some
other way.
Dan
Re: Guidance on using auto deploy, OBR or something else for initial
provisioning and updates
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 6/20/12 06:28 , Dan Gravell wrote:
> Thanks Richard. I've started work on this. I just want to document one
> problem with a workaround (should anyone run into the same problem), and
> then my latest problem.
>
> First problem I encountered almost immediately was with a fragment I have
> re-exporting extra sun.* internal packages from the system bundle. The
> issue is registered here https://issues.apache.org/jira/browse/FELIX-2465 but
> I didn't see my workaround.
>
> bindex generated:
>
> <require extend='true' filter='(&(symbolicname=system.bundle)
>
> For my fragment. I had to change this to:
>
> <require extend='true' filter='(&(symbolicname=org.apache.felix.framework)
>
> Obviously this ties me to Felix but this is ok for deployment/distribution
> build. I will also have to do some hacking in the build script to change
> this string but that's not too hard.
>
> Now, my current problem. I use the Jetty OSGi integration to serve up a UI
> for my app. The Jetty code relies on being able to get the filesystem
> location for a bundle, I guess because Jetty is still wedded to Files and
> the filesystem at some level. See bit.ly/KM6pdW [GrepCode link]
> getBundleInstallLocation(Bundle).
>
> The bundle, as provided by OBR, has a location of "obr://[bundle
> name]/[some string]". Jetty doesn't know how to interpret that. Is there
> any way of finding the filesystem location from the OBR provided bundle?
>
> I realise this isn't very 'OSGi'.
Yes, it is not.
No, there is no way of determining it other than knowing the bundle
cache format of the framework and calculating it yourself.
-> richard
>
> Dan
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Guidance on using auto deploy, OBR or something else for initial
provisioning and updates
Posted by Dan Gravell <el...@googlemail.com>.
Thanks Richard. I've started work on this. I just want to document one
problem with a workaround (should anyone run into the same problem), and
then my latest problem.
First problem I encountered almost immediately was with a fragment I have
re-exporting extra sun.* internal packages from the system bundle. The
issue is registered here https://issues.apache.org/jira/browse/FELIX-2465 but
I didn't see my workaround.
bindex generated:
<require extend='true' filter='(&(symbolicname=system.bundle)
For my fragment. I had to change this to:
<require extend='true' filter='(&(symbolicname=org.apache.felix.framework)
Obviously this ties me to Felix but this is ok for deployment/distribution
build. I will also have to do some hacking in the build script to change
this string but that's not too hard.
Now, my current problem. I use the Jetty OSGi integration to serve up a UI
for my app. The Jetty code relies on being able to get the filesystem
location for a bundle, I guess because Jetty is still wedded to Files and
the filesystem at some level. See bit.ly/KM6pdW [GrepCode link]
getBundleInstallLocation(Bundle).
The bundle, as provided by OBR, has a location of "obr://[bundle
name]/[some string]". Jetty doesn't know how to interpret that. Is there
any way of finding the filesystem location from the OBR provided bundle?
I realise this isn't very 'OSGi'.
Dan
Re: Guidance on using auto deploy, OBR or something else for initial
provisioning and updates
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 6/19/12 12:03 , Dan Gravell wrote:
> Thanks Richard,
>
> You can, although you can also use OBR to deploy from a local repository
>> too. Regarding location, it isn't too important. For example, OBR just
>> generates one based on the symbolic name and a timestamp. The main issue is
>> that the location is used as a key to uniquely identify a bundle, so if you
>> use a different location for the same bundle, the framework will treat it
>> different than if you use the same location.
>>
> Sounds like OBR is generally the way to go. I'll take a more in depth look.
> Other than
> https://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+OSGi+Bundle+Repository#ApacheFelixOSGiBundleRepository-OBRRepositoryFile
> are
> there any other resources or examples you happen to know of?
That's pretty much it. FYI, there is OSGi OBR API packages and Felix OBR
API packages. At this point, you are probably better off using the Felix
OBR API packages, since the OSGi API is on hold for now and will likely
be different if it ever advances.
>
>
>> Yeah, you don't need to do that. You can package the initial bundles with
>> the install package. Of course, once you update the installed bundles, you
>> may want another mechanism to save the updates overtop of the bundles in
>> the install package (i.e., outside the framework) so if the user ever
>> restarts from scratch (i.e., deletes their framework cache) they will start
>> with the latest bundles. Of course, this is not completely necessary, since
>> you could just deploy the old bundles and update them again, but it's
>> something to think about.
>
> Yeah, already thought about that, I wasn't going to overwrite the
> initially-installed bundles for now. There are security implications for
> Windows Vista+ platforms (write access to Program Files/**) technical
> issues with the Mac (updating a DMG image possibly beyond its size) and
> finally in many ways it may be a nice feature being able to roll back to
> the original version just by removing felix-cache.
Right. Makes sense.
>
>
>> You don't need to write your own AutoProcessor, just your own launcher
>> that massages the auto-deploy directory bundles to be what you want, then
>> the existing AutoProcessor would install, update, and delete as appropriate.
>
> I guess I don't understand this... Considering possibly already installed
> bundles in felix-cache I still have the problem with the version numbers
> differentiating the bundles and so more than one version of the bundle may
> be started.
>
> i.e... after first install and before first run:
>
> bundle/
> my_web_app-1.0.1.jar
> jetty-xyz.jar
>
> Run it:
>
> bundle/
> my_web_app-1.0.1.jar
> jetty-xyz.jar
>
> felix-cache/
> my_web_app-1.0.1.jar
> jetty-xyz.jar
>
> Update it:
>
> bundle/
> my_web_app-1.0.1.jar
> jetty-xyz.jar
>
> felix-cache/
> my_web_app-1.0.2.jar
> jetty-xyz.jar
>
> Re-install later version:
>
> bundle/
> my_web_app-1.0.3.jar
> jetty-xyz.jar
>
> felix-cache/
> my_web_app-1.0.2.jar
> jetty-xyz.jar
>
> Because my_web_app-1.0.3.jar has a different URL to my_web_app-1.0.2.jar
> (whose location is my_web_app-1.0.1.jar) it will be started.
The auto-deploy directory can perform installs, updates, or uninstalls.
By default, it only does "install", which means it will install it if it
isn't already installed using the location as a unique key. You may also
tell it to "update", in which case it will always update bundles based
on the location. Finally, you may also tell it to uninstall, in which
case if it finds installed bundles that aren't in the auto-deploy
directory, it will uninstall them from the framework. You can set any
combination of these actions, e.g., "install, uninstall" which won't do
updates or "install, update", which only installs and updates, but not
uninstalls.
So, in your example above, you would never modify the framework's
installed set of bundles directly. Instead, you would simply copy/remove
stuff from the auto-deploy directory so that the next time the framework
restarts it will change to the correct configuration of bundles based on
the auto-deploy actions you enable.
This is not as dynamic as updating bundles directly, but the current
launcher already supports restarting the framework, so you'd only have
to do a simple modification to have it re-read the auto-deploy directory.
There are a thousand ways to skin a cat, as we say... (no offense to cats)
-> richard
>
> Dan
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Guidance on using auto deploy, OBR or something else for initial
provisioning and updates
Posted by Dan Gravell <el...@googlemail.com>.
Thanks Richard,
You can, although you can also use OBR to deploy from a local repository
> too. Regarding location, it isn't too important. For example, OBR just
> generates one based on the symbolic name and a timestamp. The main issue is
> that the location is used as a key to uniquely identify a bundle, so if you
> use a different location for the same bundle, the framework will treat it
> different than if you use the same location.
>
Sounds like OBR is generally the way to go. I'll take a more in depth look.
Other than
https://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+OSGi+Bundle+Repository#ApacheFelixOSGiBundleRepository-OBRRepositoryFile
are
there any other resources or examples you happen to know of?
> Yeah, you don't need to do that. You can package the initial bundles with
> the install package. Of course, once you update the installed bundles, you
> may want another mechanism to save the updates overtop of the bundles in
> the install package (i.e., outside the framework) so if the user ever
> restarts from scratch (i.e., deletes their framework cache) they will start
> with the latest bundles. Of course, this is not completely necessary, since
> you could just deploy the old bundles and update them again, but it's
> something to think about.
Yeah, already thought about that, I wasn't going to overwrite the
initially-installed bundles for now. There are security implications for
Windows Vista+ platforms (write access to Program Files/**) technical
issues with the Mac (updating a DMG image possibly beyond its size) and
finally in many ways it may be a nice feature being able to roll back to
the original version just by removing felix-cache.
> You don't need to write your own AutoProcessor, just your own launcher
> that massages the auto-deploy directory bundles to be what you want, then
> the existing AutoProcessor would install, update, and delete as appropriate.
I guess I don't understand this... Considering possibly already installed
bundles in felix-cache I still have the problem with the version numbers
differentiating the bundles and so more than one version of the bundle may
be started.
i.e... after first install and before first run:
bundle/
my_web_app-1.0.1.jar
jetty-xyz.jar
Run it:
bundle/
my_web_app-1.0.1.jar
jetty-xyz.jar
felix-cache/
my_web_app-1.0.1.jar
jetty-xyz.jar
Update it:
bundle/
my_web_app-1.0.1.jar
jetty-xyz.jar
felix-cache/
my_web_app-1.0.2.jar
jetty-xyz.jar
Re-install later version:
bundle/
my_web_app-1.0.3.jar
jetty-xyz.jar
felix-cache/
my_web_app-1.0.2.jar
jetty-xyz.jar
Because my_web_app-1.0.3.jar has a different URL to my_web_app-1.0.2.jar
(whose location is my_web_app-1.0.1.jar) it will be started.
Dan
Re: Guidance on using auto deploy, OBR or something else for initial
provisioning and updates
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 6/19/12 10:18 , Dan Gravell wrote:
> Thanks so much for answering Richard... replies inline:
>
> On Tue, Jun 19, 2012 at 3:01 PM, Richard S. Hall <he...@ungoverned.org>wrote:
>
>> 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.
>>
> Ok, it just seemed pretty easy to do this with JarFile and so on (I already
> do it for the update code). But never mind, it is what it is.
Yeah, it is fairly simple, but not cost free. We didn't want to bloat
and add features to what is supposed to be a simple mechanism that we
ship with the framework. We probably long ago should have started a
separate "launcher" subproject at Felix that people could add all of the
bells and whistles they wanted to for launching, but that wasn't the
intent of the framework launcher.
>
> 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).
>>
> Well I'd like to use OBR in general because I think I can also replace my
> custom updating code with it.
>
> With OBR, is it possible to start with a set of already-downloaded bundles
> (i.e. those supplied by the installer), and then use an online repository
> to update? Or, really, should all installation/updating be online? I
> suppose I'm a bit confused about the significance of bundle location.
You can, although you can also use OBR to deploy from a local repository
too. Regarding location, it isn't too important. For example, OBR just
generates one based on the symbolic name and a timestamp. The main issue
is that the location is used as a key to uniquely identify a bundle, so
if you use a different location for the same bundle, the framework will
treat it different than if you use the same location.
It is up to the management agent to manage locations how it sees fit.
OBR uses the approach that I mentioned above and then it tries to update
a bundle if one with the same symbolic name is already deployed, instead
of trying to install it again.
>
> The issue with online 'initial provisioning' (quoted to avoid association
> with the OSGi concept) is that there's further downloading to do, even
> after the user thinks they've installed the software. This would need to be
> communicated, and it might also dissuade use.
Yeah, you don't need to do that. You can package the initial bundles
with the install package. Of course, once you update the installed
bundles, you may want another mechanism to save the updates overtop of
the bundles in the install package (i.e., outside the framework) so if
the user ever restarts from scratch (i.e., deletes their framework
cache) they will start with the latest bundles. Of course, this is not
completely necessary, since you could just deploy the old bundles and
update them again, but it's something to think about.
>
> 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.
>>
> Yeah, I considered writing my own AutoProcessor but wanted to stick with
> launching felix.jar if possible for now. My build, exes and so on depend on
> it.
You don't need to write your own AutoProcessor, just your own launcher
that massages the auto-deploy directory bundles to be what you want,
then the existing AutoProcessor would install, update, and delete as
appropriate.
>
> Another approach I considered was a 'bootstrap' bundle which did what
> AutoProcessor/OBR does, and then maybe uninstalled itself once the
> first-run was complete?
Yeah, that too, although building it into the launcher probably makes
more sense to me unless you are going to turn the bootstrap bundle into
a full-blown management agent.
-> richard
>
> Dan
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Guidance on using auto deploy, OBR or something else for initial
provisioning and updates
Posted by Dan Gravell <el...@googlemail.com>.
Thanks so much for answering Richard... replies inline:
On Tue, Jun 19, 2012 at 3:01 PM, Richard S. Hall <he...@ungoverned.org>wrote:
> 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.
>
Ok, it just seemed pretty easy to do this with JarFile and so on (I already
do it for the update code). But never mind, it is what it is.
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).
>
Well I'd like to use OBR in general because I think I can also replace my
custom updating code with it.
With OBR, is it possible to start with a set of already-downloaded bundles
(i.e. those supplied by the installer), and then use an online repository
to update? Or, really, should all installation/updating be online? I
suppose I'm a bit confused about the significance of bundle location.
The issue with online 'initial provisioning' (quoted to avoid association
with the OSGi concept) is that there's further downloading to do, even
after the user thinks they've installed the software. This would need to be
communicated, and it might also dissuade use.
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.
>
Yeah, I considered writing my own AutoProcessor but wanted to stick with
launching felix.jar if possible for now. My build, exes and so on depend on
it.
Another approach I considered was a 'bootstrap' bundle which did what
AutoProcessor/OBR does, and then maybe uninstalled itself once the
first-run was complete?
Dan
Re: Guidance on using auto deploy, OBR or something else for initial
provisioning and updates
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org