[ANN] 4.0 milestone 2

[Andrus Adamchik]

The second milestone of Bootique 4 is out. There are a lot of goodies included:

1. Jakarta EE 11 support. This just means that a bunch of libraries across the modules are aligned with v11. Most notably, Servlets 6.1 / Jetty 12.1 and JAX-RS 4.0 / Jersey 4.x.

2. STDIN as an extra config source. This an interesting new feature that allows to pass app configuration to the app stdin via "--config=stdin:yaml" or "--config=stdin:json". It enables or simplifies certain secure deployment scenarios. E.g. pushing secrets to the app on startup via SSH without saving the secrets file on the target machine:

cat secrets.yaml | ssh user@server 'java -jar my.jar --config=stdin:yaml'

3. bootique-logback includes a configurable SMTP appender for simple no-frills application alerting ("if there is an 'ERROR' level log line, email it to a given address"). Just like "--config=stdin:xxx" above, this feature falls into the category of "don't overcomplicate your deployments!"

4. OidcFilter in bootique-shiro. The work continued to implement and refine JWT OAuth2 / OpenID connect support. This release includes a new OidcFilter to protect web pages with a redirect-based login to an external IDP (like Google, Entra, etc.). It also reorganizes some configuration around JwtRealm that was first introduced in M1.

5. Swagger module, in addition to the earlier "OpenAPI customizer", features a more specific OpenApiModelRequestFilter that allows to include/exclude certain paths and HTTP methods in the resulting model based on application security rules.

6. Swagger UI config supports putting custom JS snippets in YAML for the "requestInterceptor" property. The use case that we had in mind was to pass security tokens to the API calls. E.g., when used in conjunction with OidcFilter above, you can pass the OIDC cookie as a token to the OpenAPI backend:

swaggerui:
default:
requestInterceptor: |
function (req) {
const token = // get auth cookie
if (token) {
req.headers["Authorization"] = "Bearer " + token;
}
return req;
}

7. bootique-job is free of the Spring dependency, as we rewrote the Spring TaskScheduler. We borrowed pieces of Spring code (e.g., cron parser), and implemented our own simple scheduler. So no heavy dependency tree anymore, and we can control the stack (e.g., we switched to virtual threads for jobs).

8. Also, bootique-job features a new Scheduler API for manipulating triggers. The old one didn't support creating new triggers (though it allowed a degree of manipulation of the existing ones declared in YAML). Now you can create/schedule/cancel/remove triggers in the app in a simple and consistent way.

9. bootique-jersey now supports multi-part features out of the box. No need to add extra Jersey dependencies.

10. We fixed a long-standing bug with bootique-jersey resource scoping. Previously all resources were treated as singletons, whether they were created as such or not. Now we'll respect the actual DI scopes for resources (such as @Singleton annotation)

11. bootique-cayenne configuration structure was reworked to reduce the number of invariants, get rid of implicit behavior and use resource URLs in the Bootique "classpath:" format instead of always assuming "classpath:". See https://github.com/bootique/bootique-cayenne/issues/119 for details.

12. There are dependency version upgrades across the board, including a lot of security-related ones.

Release notes: https://github.com/bootique/bootique/releases/tag/4.0-M2
Upgrade notes: https://github.com/bootique/bootique/blob/master/UPGRADE.md

Thanks,
Andrus

[giulio...@gmail.com]

I am slow going, but still going.

I have upgraded already to Bootique-4.0-M3 and things are moving along
smoothly (mostly thanks to Claude Code, though! 😅).
I have stumbled upon a minor issue though: Bootique main POM does not
expose which version of `slf4j` is using; in my project I have a
library module that relies just on slf4j, but I have to set its
version explicitly in order to use it.

Thanks,

Giulio Cesare

> --
> You received this message because you are subscribed to the Google Groups "Bootique User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bootique-use...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bootique-user/1BE38AD7-292A-44A4-A4E2-A2E33B4E89F1%40objectstyle.com.

[Andrus Adamchik]

Hi Giulio,

Yeah, this is a wrinkle that affects more than just SLF4J.

While Bootique would bring in third-party dependencies to your project as transitive when needed, we don't define such dependencies on their own in the Bootique BOM.

I wish we could at least expose the versions of common third party libraries from here as properties (so users could add their own dependencies using those versions):

https://github.com/bootique/bootique-modules-parent/blob/master/pom.xml

But Maven wouldn't allow us to expose properties via the BOM. The only way I am aware of to share properties is to make our POM the parent of a user project, but that's too invasive and we walked away from it a few Bootique generations back. I wonder if there's some other Maven hack I may be missing?

Andrus

> To view this discussion visit https://groups.google.com/d/msgid/bootique-user/CAAOOpAOYB3Q4mjCqrFmjYVkiUBTxBzvn1JYCHyRdMtvkeOwawA%40mail.gmail.com.

[giulio...@gmail.com]

Thanks Andrus,

I reported the issue hoping I was missing something myself, but it
looks like it a more structural issue with Maven.
I will keep my eyes open, and if I stumble upon other way to address
the issue I will report back.

Thanks!!

Giulio Cesare

> To view this discussion visit https://groups.google.com/d/msgid/bootique-user/7511C69F-4D91-4FFD-BC9C-8483E757D9FE%40objectstyle.com.