fix: recognise the nested jars of Spring Boot when looking up the token file - #25680
Conversation
…en file The lookup for flow-build-info.json decides that the application is packaged into a jar by counting the archives the vite.generated.ts of flow-server is inside of, and then prefers the file in the outermost archive, which is the one of the application itself. Spring Boot 3.2 and newer separate the jar of the application from an archive nested in it with '/!' instead of '!/', so nothing was counted for it and the application never looked packaged. The file of a dependency was then used whenever the class loader happened to return it first. Both separators are now counted, so the file of the application wins again.
Type of change
How to testThis cannot be exercised by hand without packaging an application, so it Test coverageThe test mocks the class path of an application packaged with Spring
The URL formats were taken from API changesNone. Both changed methods are private. |
…t-nested-jars-in-token-file-lookup # Conflicts: # flow-server/src/test/java/com/vaadin/flow/server/startup/DefaultApplicationConfigurationFactoryTest.java
|
Reopened as #25681, which is based on |
|
1 participant
Depends on #25649, Follow-up to #6858
behavior deviation · flow-server · applications packaged with
Spring Boot 3.2 or newer, where a dependency also contains a
flow-build-info.json
Background — the token file lookup. The build writes
flow-build-info.jsoninto the build output folder, and the runtimereads it from the class path at startup. A copy inside a jar is skipped,
unless the application is packaged into a jar itself, in which case its
own file is inside one too and has to be used.
Whether the application is packaged is decided by counting the archives
a resource of
flow-serveris inside of, and the separator counted forthat is the one Spring Boot used before 3.2. Applications packaged with
a newer Spring Boot therefore never looked packaged, and the file of a
dependency was used whenever the class loader returned it first, giving
the application the settings of the project that built the dependency.
Risks:
the application is now used instead of the first one found. The old
order was accidental.
threading or performance impact, nothing to migrate.
Context. Spring Boot 3.2 replaced the nested jar URLs of its own
loader with the
nested:protocol, which separates the jar of theapplication from an archive inside it with
/!, as innested:/app.jar/!BOOT-INF/lib/flow-server.jar!/vite.generated.ts. Thelookup only counted
jar!/, so it saw one archive where there are two.jar!/and thejar/!separator when working outhow many archives a resource is inside of, so an application packaged
with Spring Boot 3.2 or newer is recognised as packaged.
one archive in its path, which is the file of the application itself
in both the old and the new packaging.
of a dependency comes first on the class path.