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 <[email protected]> >> 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 >> [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
