←Older revision |
Revision as of 16:08, 12 October 2011 |
Line 32: |
Line 32: |
| The [[Netbinox]] system reconfigures classical [[Equinox]] container and replaces its bundle content access system. Instead of classical (and slow) ''ZipBundleFile'', there is enhanced ''JarBundleFile'' which knows how to communicate with [[NetBeans Runtime Container]] [[netbeans:StartupCache|start caches]]. This is the heart of the whole system that brings the [[performance]] improvements and makes the ''difference''. I write ''difference'' in both, positive and negative meaning. As the whole bundle access system is rewritten, there is non zero probability its behaviour is not [[Amoeba|completely same]] as the original one (see the previous paragraph what to do if you find a difference). | | The [[Netbinox]] system reconfigures classical [[Equinox]] container and replaces its bundle content access system. Instead of classical (and slow) ''ZipBundleFile'', there is enhanced ''JarBundleFile'' which knows how to communicate with [[NetBeans Runtime Container]] [[netbeans:StartupCache|start caches]]. This is the heart of the whole system that brings the [[performance]] improvements and makes the ''difference''. I write ''difference'' in both, positive and negative meaning. As the whole bundle access system is rewritten, there is non zero probability its behaviour is not [[Amoeba|completely same]] as the original one (see the previous paragraph what to do if you find a difference). |
| | | |
- | The deviations observable from within the [[OSGi]] specification shall be limited to those related to bundle content access. However, they may be other type of deviations, as the [[OSGi]] specification does not prescribe the installation layout neither specific [[OSGi]] container extensions, nor it defines behavior of [[ThreadContextClassLoader]]. [[Equinox]] also provides its own extension [[NetbinoxHook|hooks]], not part of [[OSGi]] specification. [[NetbinoxHook]]s are as similar as possible, but are registered in slightly different [[NetbinoxHook|way]]. | + | The deviations observable from within the [[OSGi]] specification shall be limited to those related to bundle content access. However, there may be other type of deviations, as the [[OSGi]] specification does not prescribe the installation layout neither specific [[OSGi]] container extensions, nor it defines behavior of [[ThreadContextClassLoader]]. [[Equinox]] also provides its own extension [[NetbinoxHook|hooks]], not part of [[OSGi]] specification. [[NetbinoxHook]]s are as similar as possible, but are registered in slightly different [[NetbinoxHook|way]]. |
| | | |
- | The [[Netbinox]] system wraps the [[Equinox]] container and takes care of loading its classes. In order to support not just [[Equinox]], but also [[Felix]] (as part of [[Netigso]] project), we had to separate the [[OSGi]] [[API]] classes from the [[JAR]]s of those [[OSGi]] containers. Since version 1.16.8 the the ''modules/ext/equinox.jar'' used by [[Netbinox]] is identical to up stream ''org.eclipse.osgi_VERSION.vDATE.jar'' (it used to contain only [[Equinox]] specific classes before [https://netbeans.org/bugzilla/show_bug.cgi?id=195305 195305] was fixed). The common [[OSGi]] [[API]]s are in ''modules/ext/osgi.cmpn-4.2.jar'' and ''modules/ext/osgi.core-4.2.jar''. No problems related to this separation were reported so far. | + | The [[Netbinox]] system wraps the [[Equinox]] container and takes care of loading its classes. In order to support not just [[Equinox]], but also [[Felix]] (as part of [[Netigso]] project), we had to separate the [[OSGi]] [[API]] classes from the [[JAR]]s of those [[OSGi]] containers. Since version 1.16.8 the ''modules/ext/equinox.jar'' used by [[Netbinox]] is identical to up stream ''org.eclipse.osgi_VERSION.vDATE.jar'' (it used to contain only [[Equinox]] specific classes before [https://netbeans.org/bugzilla/show_bug.cgi?id=195305 195305] was fixed). The common [[OSGi]] [[API]]s are in ''modules/ext/osgi.cmpn-4.2.jar'' and ''modules/ext/osgi.core-4.2.jar''. No problems related to this separation were reported so far. |
| | | |
| While using [[Equinox]] in the [[Eclipse]] way, one gets not only the [[OSGi]] container, but often also reuses the launcher. This launcher has some assumptions about configuration files, command line options, etc. None of this is reused by [[Netbinox]]. Rather the configuration files are standard [[NetBeans]] ones (although there are ways to read [[Eclipse]] like ones too). The [[Eclipse]] like command line options are not recognized, however most of the functionality remains accessible via system properties. For example, one cannot use ''-console'' to start the [[Equinox]]'s [[OSGi]] console, but one can still specify ''-J-Dosgi.console='' property to turn the same functionality on. There are ways to enhance the [[NetBeans]] and thus [[Netbinox]] launcher to understand new options, however that is a topic for another document. | | While using [[Equinox]] in the [[Eclipse]] way, one gets not only the [[OSGi]] container, but often also reuses the launcher. This launcher has some assumptions about configuration files, command line options, etc. None of this is reused by [[Netbinox]]. Rather the configuration files are standard [[NetBeans]] ones (although there are ways to read [[Eclipse]] like ones too). The [[Eclipse]] like command line options are not recognized, however most of the functionality remains accessible via system properties. For example, one cannot use ''-console'' to start the [[Equinox]]'s [[OSGi]] console, but one can still specify ''-J-Dosgi.console='' property to turn the same functionality on. There are ways to enhance the [[NetBeans]] and thus [[Netbinox]] launcher to understand new options, however that is a topic for another document. |