jbonofre opened a new pull request, #2899: URL: https://github.com/apache/karaf/pull/2899
## Summary Backport of #2898 to `karaf-4.4.x`. After a major JDK version change (e.g. JDK 11 -> 17), Karaf can become unresponsive to `etc/*.cfg` changes and deploy directory drops (`log:tail` shows nothing about the change). This was tracked down to a stale bundle wiring persisted in `data/cache`: after restarting under the new JDK, the File Install bundle's cached wiring was missing wires to `org.osgi.service.cm` (Configuration Admin) and `org.osgi.service.log` (Log Service), so config/deploy directory monitoring silently stops working. Reverting to the previous JDK does not self-heal it, since the corrupted state is on disk, not JDK-dependent. This change makes Karaf detect the situation and clean up automatically: - `ConfigProperties` now records the JDK specification version (`java.specification.version`) used on the last start in `data/jdk_version`. - On startup, if the recorded version differs from the current one, the OSGi bundle cache (`org.osgi.framework.storage`, normally `data/cache`) is cleaned before the framework is created, forcing a full re-resolution instead of reusing stale wiring. - A normal restart on the same JDK (including patch upgrades, since only the specification version is compared) is unaffected. - The behavior can be disabled with `-Dkaraf.clean.cache.on.jdk.change=false` for anyone who wants to manage this themselves. Cherry-picked cleanly from `main` (one trivial context difference in `ConfigProperties.java`, unrelated to this change). ## Test plan - [x] `mvn -pl util,main -am install -DskipTests` then `mvn -pl main test -Dtest=UtilsTest` passes on `karaf-4.4.x`. -- 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]
