NetbinoxHook
From APIDesign
| (2 intermediate revisions not shown.) | |||
| Line 1: | Line 1: | ||
| - | [[Netbinox]] is fully compatible [[OSGi]] container built around [[Equinox]]. It's goal is to be fully compatible for complient [[OSGi]] bundles. However [[Equinox]] offers more than just [[OSGi]] [[API]]s. It offers various extension [[NetbinoxHook|hooks]]. Version 1.16.7 of [[Netbinox]] exposes these hooks too, however as there are certain problems [[ | + | [[Netbinox]] is fully compatible [[OSGi]] container built around [[Equinox]]. It's goal is to be fully compatible for complient [[OSGi]] bundles. However [[Equinox]] offers more than just [[OSGi]] [[API]]s. It offers various extension [[NetbinoxHook|hooks]]. Version 1.16.7 of [[Netbinox]] exposes these hooks too, however as there are certain problems [[BootstrappingEquinox]], it exposes them in slightly different way. |
First of all the [[Netbinox]] itself needs to register few hooks to achieve the improvements to the [[NetbinoxPerformance]]. Those include class loading hook, bundle file factory hook, framework log and adaptor hook. However since version 1.16.7 the [[Netbinox]] also queries for additional hook configurators using [[ServiceLoader]] [[injection]] style: | First of all the [[Netbinox]] itself needs to register few hooks to achieve the improvements to the [[NetbinoxPerformance]]. Those include class loading hook, bundle file factory hook, framework log and adaptor hook. However since version 1.16.7 the [[Netbinox]] also queries for additional hook configurators using [[ServiceLoader]] [[injection]] style: | ||
| Line 9: | Line 9: | ||
</source> | </source> | ||
| - | This means that anyone can create a [[NetBeans]] module, add dependency on ''org.apidesign.netbinox'' version at least 1.16.7 and implement [[Equinox]]'s own ''HookConfigurator''. The configurator's '''addHooks''' method can then register what ever additional [[ | + | This means that anyone can create a [[NetBeans]] module, add dependency on ''org.apidesign.netbinox'' version at least 1.16.7 and implement [[Equinox]]'s own ''HookConfigurator''. |
| + | |||
| + | <source lang="java"> | ||
| + | @ServiceRegistration(service=HookConfigurator.class) | ||
| + | public final class MyHooks implements HookConfigurator { | ||
| + | public void addHooks(HookRegistry hr) { | ||
| + | // register the additional hooks | ||
| + | } | ||
| + | } | ||
| + | </source> | ||
| + | |||
| + | The configurator's '''addHooks''' method can then register what ever additional [[NetbinoxHook|hooks]] one needs. Obviously the additional [[NetbinoxHook|hooks]] need to be packaged as [[NetBeans]] module and not [[OSGi]] bundle, as they have to be available sooner than the [[Equinox]] framework starts (another [[BootstrappingEquinox|boostrapping]] problem). However except of this small limitation the [[Lookup]] based registration seems to be quite easy and compatible enough with the original [[Equinox]] approach. | ||
| + | |||
| + | <comments/> | ||
Current revision
Netbinox is fully compatible OSGi container built around Equinox. It's goal is to be fully compatible for complient OSGi bundles. However Equinox offers more than just OSGi APIs. It offers various extension hooks. Version 1.16.7 of Netbinox exposes these hooks too, however as there are certain problems BootstrappingEquinox, it exposes them in slightly different way.
First of all the Netbinox itself needs to register few hooks to achieve the improvements to the NetbinoxPerformance. Those include class loading hook, bundle file factory hook, framework log and adaptor hook. However since version 1.16.7 the Netbinox also queries for additional hook configurators using ServiceLoader injection style:
for (HookConfigurator hc : Lookup.getDefault().lookupAll(HookConfigurator.class)) { hc.addHooks(hr); }
This means that anyone can create a NetBeans module, add dependency on org.apidesign.netbinox version at least 1.16.7 and implement Equinox's own HookConfigurator.
@ServiceRegistration(service=HookConfigurator.class) public final class MyHooks implements HookConfigurator { public void addHooks(HookRegistry hr) { // register the additional hooks } }
The configurator's addHooks method can then register what ever additional hooks one needs. Obviously the additional hooks need to be packaged as NetBeans module and not OSGi bundle, as they have to be available sooner than the Equinox framework starts (another boostrapping problem). However except of this small limitation the Lookup based registration seems to be quite easy and compatible enough with the original Equinox approach.
<comments/>
Follow
