NBICoreVsExtensionsReusability

NBI Engine Core and Extensions Interoperability Strategy

Original Description

This document specifies the functionality of the NBI engine which is responsible of ensuring reusability of installable components based on different versions of NBI core engine and, possibly, custom extensions by different vendors.

A typical usecase for such reusability is the following: installer vendor A builds an installable component X using NBI core engine Core.I (core version I) and its custom engine extension A.K (extension version K); another installer vendor B wants to reuse the component in its installer which is based on core engine Core.J and its extension B.M.

The straightforward approach would not work here as there may be incompatibilities between different versions of the NBI core, as well as between engine extensions provided by different vendors. Therefore the solution needs to be more intricate.
The main idea is to force the "environment" of component X be always Core.I + A.K without regard to the currently active core + extension combination. In other words, the classloader which loads the configuration logic for the component should respect its desired environment settings (core version and extension brand and version) and filter out the incompatibilities.

This said, the following additional requirements can be formulated with regard to the core engine, installable components and the process of loading their configuration logic:

  1. The critical engine APIs (registry, wizard) MUST NOT change between minor core revisions (1.X);
  2. The component should expose its desired core and extension versions via it's descriptor and provide links to them, so that the currently active engine could obtain and activate them;
  3. The component's classloader should filter out the current engine's classes except for the critical parts (registry, wizard) thus substituting them with the ones residing in the desired core/extension pair;


From the technical standpoint this requires light modification of the registry XML format (information about the supported core version and required extension needs to be added to the product descriptor); product package format needs to change to incorporate the core and extension supported by the component; server-side application needs to learn how to handle these libraries.

A separate task is the creation of a specialized classloader which would replace the current implementation, which would satisfy requirement #3.

Estimated resources required to complete these tasks are: 10 mythical man/days.

In-Work Notes


Key Assumptions

  1. Major versions of the engine core are compatible in terms or key interfaces. Product requiring core version 1.X will work reliably with any 1.Y, be Y greater or less than X.
  2. A product may require more than one extension to be present in order to work correctly.
Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo