2016-11-22 12:32 GMT+01:00 Hari Madhavan <hari.madha...@promantia.com>:
> Hi All, > > We use OSGi with Karaf for a secure and reliable message delivery product > that is deployed on end-user desktops ( as opposed to servers ) . One of > the things that is important is to have seamless auto-upgrades of the > product as new versions are published. There are 2 requirements that we had > for which I wanted to understand the best solution. > > > - We had decided to stop all activity in the product before starting > the upgrade. This would cause a small delay for the end-user but as > upgrades do not happen often it is acceptable as long as we do it only > during upgrades. The process that we would follow is as follows > - Check if there is an update available for a feature > - If updates are available > - complete currently running transactions > - shutdown all services > - pull down the updates from the server ( Nexus ) > - install the updates > > How can we find whether there is an feature upgrade to be installed ? Is > there an event on feature:repo-refresh that we can bind to which will tell > us that the feature has an upgrade ? Alternatively can we invoke > feature:install when it runs with -t -v parameters through an API interface > as that would also enable us to confirm whether an attempt to upgrade would > bring new versions or not. > > Note that your feature repositories should be versioned correctly. So you could use the mvn url handler to check if there's a new version of the repository to use. Then use the published FeaturesService to simulate the changes. It's not really easy to detect if there are any changes, as none of the methods of the FeaturesService return a useful result. One way without changing the code would be to use the setOutputFile method which has the effect of writing the output of the resolver to a file in json format. You can then read the file, extract the list of bundles and compare them to the list of current bundles to see if there are any changes. > > - We wanted to have an option of running an upgrade installer at the > time of upgrade where the structure of some of the persistent data stores ( > databases , preference files ) related to the product are updated to be > consistent with the new version of the bundle that manages this data store. > To do this we defined an upgrade interface that is implemented in bundles > that need some client side changes to be done at the time of upgrade. We > plan to invoke this service interface after the upgraded bundle has been > installed by providing the earlier version of the bundle as a parameter, > so that the upgrade service implementation within the bundle can serially > do all upgrade changes from that version to the current version. To do > this before installing a feature , I'd like to know the original version of > each bundle which has changed. This information is available when > feature:install is run with a -v parameter. How can we programatically > access that information ? > > If you use the method I indicated above to see if there are any changes, you should have the list of old and new bundles. Btw, if you prefer, you can use the verbose flag instead of the json written file. In order to grab the output which is written to System.out, you'd have to use the org.apache.felix.service.threadio.ThreadIO service in order to set the thread based system streams with your own stream to grab the output. But you'd have to parse the output which is more error prone I think. > Apologies for the long mail and thanks in advance for your suggestions. > > Regards > Hari > > > Regards > Hari > > Hari Madhavan, > Director - ERP Practice, > Promantia Global Consulting LLP <http://www.promantia.in> > Ph: +91 9845147731 > *Openbravo Gold Partner* > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
