OLSander opened a new pull request, #944: URL: https://github.com/apache/aries/pull/944
Addresses [ARIES-2243](https://issues.apache.org/jira/browse/ARIES-2243). SPI Fly uses `Bundle.getHeaders()` to discover consumers and providers and inspect bundle class paths. This requests localized headers, which can trigger localization resource lookups for every inspected bundle, including bundles without SPI Fly declarations. This change uses `getHeaders("")` at the six production call sites in SPI Fly: - Consumer header discovery on hosts and fragments. - Provider capability/header discovery on hosts and fragments. - `Bundle-ClassPath` inspection for embedded service files and the fallback class-loader lookup. The additional provider/class-path calls read the same kind of technical metadata. Updating them keeps SPI Fly's header access consistent; the performance measurements below primarily concern consumer discovery. Existing test changes update mock expectations to the selected overload. Other Aries modules are left for separate changes. **Compatibility / review point** The [OSGi localization specification](https://docs.osgi.org/specification/osgi.core/8.0.0/framework.module.html#framework.module.localization) permits localized manifest headers, while requiring the framework to use non-localized values for headers with framework semantics. Raw values therefore match the framework's interpretation of the standard capability and class-path headers. For the custom `SPI-Consumer` and `SPI-Provider` headers, this proposal treats the values as machine configuration. A bundle using `%key` indirection for an entire custom SPI header would behave differently. Please confirm that raw access matches SPI Fly's intended contract. None of the relevant consumer header values in the tested Connect bundle set uses this indirection; that audit is specific to our application. **Validation** - `mvn clean install -f spi-fly` passed on Windows with Java 17 and Maven 3.9.11: 63 unit tests, zero failures/errors/skips; the configured integration-test phase also completed successfully. - Four new parameterized consumer-discovery cases cover `SPI-Consumer` and `Require-Capability`, each on a host and a fragment. They require the raw overload, reject the no-argument overload, and verify the resulting weaving instructions. All four fail against the original implementation and pass with this change. - Built baseline and patched `1.3.9-SNAPSHOT` bundles from the same upstream revision were tested in Connect/Equinox with 612 application bundles and identical ASM 9.11.1 dependencies. A timing-only agent verified the loaded artifact; it did not substitute header calls. After one warm-up per variant, two alternating pairs gave: | Initial SPI Fly activation | Baseline | Patched | | --- | ---: | ---: | | Pair 1 | 1,171 ms | 792 ms | | Pair 2 | 1,088 ms | 662 ms | Consumer header extraction decreased from 941/871 ms to 546/451 ms. JVM-to-window timings overlapped (baseline 16.96/19.54 s; patched 18.43/18.38 s), so these runs establish reduced SPI Fly scanning work, not a repeatable overall application-startup improvement. The patched bundle also passed an unsaved Print-template creation and Source/Design editing round trip. The original application dependency was restored afterward. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
