For really low-level things consider using system.bundle fragments. In OSGi R6 system.bundle fragments are now allowed to have activators by specifying a ExtensionBundle-Activator header. See the R6 specification for the details, but in short the system.bundle fragments are activated at framework init() time before start-level 1 is even reached. This is really useful for system level code that hooks directly into the framework and must be present from the init of the framework to provide consistent behavior for the lifetime of the framework. Things like bundle/service/resolver/weaving hooks. It sounds like that would be needed for things like aspects if they are being applied at runtime with a weaving hook.
For Karaf decanter, I think I am missing the issue. If you are using service-oriented design patterns wouldn't the necessary services become available before the rest of the system can come on-line? Tom osgi-dev-boun...@mail.osgi.org wrote on 10/28/2016 08:25:36 AM: > From: Christian Schneider <ch...@die-schneider.net> > To: OSGi Developer Mail List <osgi-dev@mail.osgi.org> > Date: 10/28/2016 08:25 AM > Subject: [osgi-dev] Making sure some bundles are started first > Sent by: osgi-dev-boun...@mail.osgi.org > > 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
