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 <[email protected]>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: [email protected]
For additional commands, e-mail: [email protected]
