Reviving this... Well, it was about 6 lines of code and it took me 6 months ;). Obviously there was a bit more going on that was keeping me busy, but eventually I've implemented that strategy. (also fixed aProtectionDomain issue mentioned by Tim back at the community event, and completely rewrote the whole proxy model).
Back to topic, there are several ways to restart the bundles... mainly, in which order, and doing individual restarts or batching stops and starts. Aspecio first collect the set of bundles providing services to weave, sorts them using the natural Bundle comparator (based on bundleIds). It stops them all in that order, then starts them all. The ordering should allow to keep the original installation order, and stopping and starting them by batch is aiming to minimize service level interactions between these bundles (such as re-creating components with static references too many times). For instance with three restarted bundles A, B and C, if C had a DS component X using services from A and B with static references, restarting A then B would recreate X twice. Going with the batch, it should happen only once. In case someone has the same need one day, the code is available on GitHub[1] in ServiceWeavingManager#open() Hope this helps, Simon [1] https://github.com/primeval-io/aspecio Simon Chemouil a écrit le 02/11/2016 à 14:27 : > I thought about restarting bundles when I was first dealing with that > issue and judged it was a bit extreme, yet ended up with forcing an > early start. > Considering start level an optimization is a nice way to solve the problem. > > I will try to find some time to make the necessary adjustments to > support that behavior in the next version of Aspecio. > > Simon > > Le 28/10/2016 à 17:32, Neil Bartlett a écrit : >> Start Levels can solve these problems but it’s best to use only as an >> optimisation rather than to enable functionality. I.e., make sure your >> bundles still work even if they are started in the “wrong” order, though >> perhaps with slightly poorer performance. >> >> 1st scenario seems to be fine… if you miss some log messages it’s not the >> end of the world, but by controlling start order you can make sure you miss >> as few messages as possible. If you have some part of your application that >> absolutely must log, then have it depend on the Log Service. >> >> 2nd scenario: I assume Aspecio is implemented using Service Hooks. The >> general advice with these is: when you find pre-existing services that you >> want to intercept, force a stop and restart of their origin bundles. If >> Aspecio starts last then everything still works eventually, but at the >> expense of some churn. Applying start levels allows you to optimise and >> avoid the churn. >> >> Neil >> >>> On 28 Oct 2016, at 14:25, Christian Schneider <ch...@die-schneider.net> >>> wrote: >>> >>> There are some rare cases were I would like to make sure that certain >>> bundles are started very early (or before other bundles). >>> >>> Two examples: >>> >>> - Karaf decanter logs messages, bundle and services events. The problem is >>> that it will only start to do so when the decanter bundles are started. So >>> it misses some messages on startup. Decanter currently uses EventAdmin to >>> communicate between modules. This introduces another point where messages >>> can get lost during startup. >>> >>> - Simon Chemuil introduces an interesting Aspect framework Aspecio that can >>> apply aspects to services. The problem is that it must be started before >>> the services are present. >>> >>> Are there best practices for these use cases? >>> >>> Christian >>> >>> -- >>> Christian Schneider >>> http://www.liquid-reality.de >>> >>> Open Source Architect >>> http://www.talend.com >>> >>> _______________________________________________ >>> OSGi Developer Mail List >>> osgi-dev@mail.osgi.org >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >> >> _______________________________________________ >> OSGi Developer Mail List >> osgi-dev@mail.osgi.org >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
