Hmmm. That's unfortunate. I'm pretty stuck on these components. I now realise this is sometimes called a "management agent" in OSGi world, although the same term is also used for an entity that manages configuration admin stuff.
What I don't really understand is how the management agent can be updated, if it cannot update itself (bundles should not change their own state AIUI). Can this be done by two co-operating bundles? As so: com.mgmtagent.1 installs an update for com.mgmtagent.2 if one exists. Then starts com.mgmtagent.2 transiently com.mgmtagent.2 installs updates for com.mgmtagent.1, then updates for all the other bundles and starts them transiently I'm surprised there aren't more bundles around for re-use that do this type of thing - FileInstall is the only one I know - maybe I've missed the others? I can't use FileInstall because of the polling. I would appreciate anyone's thoughts. Dan bliss <http://www.blisshq.com/> - fully automated music library management. Read the music library management blog <http://www.blisshq.com/music-library-management-blog/>. On 26 October 2016 at 15:38, Peter Kriens <[email protected]> wrote: > If you have bundles that can’t handle the dynamics then you’re screwed … > there is only one good solution and make them handle the dynamics > correctly. Then everything falls in place. > > OSGi works like a charm when you follow its few and simple rules but if > you try to deviate it quickl becomes hell. > > Kind regards, > > Peter Kriens > > > > On 26 okt. 2016, at 15:19, Dan Gravell <[email protected]> wrote: > > > > I wondered if someone could help me with the best way of structuring my > bundle start sequencing. > > > > My application is a self hosted server that runs Felix which then runs a > "bootstrap bundle" from bundle/ which in term adds a repository to > felix.bundlerepository.RepositoryAdmin (I think I'm very behind the > times) which is in a well-known location in the installation - app-bundle/ > . All the bundles in there are then started transiently to prevent them > starting automatically on the next restart. > > > > The reason I do it this way is because I have to restart the JVM when > code is updated; some components in my server do not deal well with bundle > restarting (threads left etc). It is too much work to fix this. When the > app restarts, and because the bundles were only started transiently, the > "bootstrap bundle" gets a chance to look for updated code, install it, then > run the bundles transiently again. > > > > A problem I have had is where I have updated the "bootstrap bundle". If > this is done by in-app update then the new version is never used, because > it does not get copied to bundle/ . If it is done by installing a new > version of the software manually, it is added in addition to the previous > version of the bundle, both run, and problems result. > > > > It feels like I might be able to add another special case to resolve > this. > > > > However I think I'm going about this totally wrong and I wondered if > there have been any developments in the past four years since I implemented > this? > > > > Thanks, > > Dan > > _______________________________________________ > > OSGi Developer Mail List > > [email protected] > > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev >
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
