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
