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