Re: [quarkus-dev] Digest for quarkus-dev@googlegroups.com - 2 updates in 1 topic
36 views
Skip to first unread message
René Grob
May 2, 2022, 2:10:59 PM5/2/22
to quark...@googlegroups.com
Hi Yoann,
Using the same property for build and runtime configuration sounds like opening a can of worms to me. What if I want a default false but able to enable the feature at runtime? Build-time properties can usually not be changed at runtime - the change will be ignored or if quarkus.configuration.build-time-mismatch-at-runtime is set to fail, the app will not even start up. I strongly recommend using different properties.
On Sat, 30 Apr 2022 at 04:03, <quark...@googlegroups.com> wrote:
Yoann Rodiere <yo...@hibernate.org>: Apr 29 09:09AM +0200
Hi,
Hibernate *Search* (so, another extension, not what you're using) already
has a property named `quarkus.hibernate-search-orm.enabled` [1], but it's
used to disable the extension *at runtime*. I believe other extensions have
this as well, or at least I've seen requests for such features in other
extensions. But so far, I've only seen this requested as a runtime flag,
which obviously requires that build steps always be executed (just in case
the extension is enabled at runtime).
Now, about disabling build steps... I suspect this has been discussed
before, but I don't have the history in mind, so I'll let others (Sanne?)
answer as to whether we can/want to do this or not.
I can start bike-shedding though, so here you go :)
If we end up adding this feature, and if we end up using an `enabled`
property to control this feature (like in Hibernate Search), then I think
the property should work both at build time *and at runtime*, for
consistency, and because I think disabling stuff at runtime is a more
widespread use case.
We would have an `enabled` property that would default to `true`. If set
to `false` at build time, then it's definitive, you can't set it back to
true at runtime (you would get an exception on bootstrap). If it stays to
the default value or is set to `true`, then you can still set it to `false`
at runtime.
[1]
https://quarkus.io/guides/hibernate-search-orm-elasticsearch#quarkus-hibernate-search-orm-elasticsearch_quarkus.hibernate-search-orm.enabled
Yoann Rodière
Hibernate Team
yo...@hibernate.org
On Fri, 29 Apr 2022 at 00:08, 'Thomas Darimont' via Quarkus Development
Pedro Igor <pigor.c...@gmail.com>: Apr 29 03:38AM -0700
Thanks, Yoann.
What I'm looking for is a property similar to yours. Good to know Hibernate
Search has this option so perhaps it makes sense to also have something
similar in HHH.
I might be wrong, but it seems that conditional steps also affect the build
so steps are ignored depending on their condition. In our case, we need
build steps excluded from re-augmentation because Keycloak is a mutable
application.
Right now, we managed to achieve our goal (avoid bootstrapping EMF/DS) by
conditionally creating our PU in our extension. That seems to be enough to
"disable" the extension because there would be no JPA model to process.
On Friday, April 29, 2022 at 4:09:57 AM UTC-3 Yoann Rodiere wrote:
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to quarkus-dev...@googlegroups.com.
Yoann Rodiere
May 3, 2022, 4:16:44 AM5/3/22
to rene....@gmail.com, Quarkus Development mailing list
> What if I want a default false but able to enable the feature at runtime?
Fair point.
> I strongly recommend using different properties
Ok, but I'd still make sure we have at least a warning (and probably an error) if an extension is disabled with the build time property but enabled with the runtime property.
This would probably require that the extension always keep *some* build steps enabled, though, to implement the check.
Also, that brings the problem of finding explicit enough names. A simple name, e.g. "enabled", should be used for the runtime property, I think, since it has the most straightforward behavior.
For the build time property, I guess "augment", "enabled-at-build-time" or "allow-enabling" would work, but those are definitely not good names.
We'd need something that makes it clear the extension will be disabled completely if the property is set to `false`, and that also makes it clear the disabling happens at build time and thus cannot be reverted at runtime. I'm open to suggestions...
Maybe we should use "enable"/"enabled" for the build-time property, and "start"/"started" for the runtime property?
--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CACkR2pUkkjPDPG0EjRX6imPF0uC%2BeOHxJv_bbg_wzgV0VfZGhA%40mail.gmail.com.
Erin Schnabel
May 3, 2022, 11:55:18 AM5/3/22
to yo...@hibernate.org, Quarkus Development mailing list, rene....@gmail.com
The convention we use is that *.enabled is the build time check, with the defaults explained (usually true).
For micrometer, the big on/off switch is at build time... there are ways to enable/disable publishing or other nested behaviors at runtime, but they are more specific properties..
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAEqagpruSbUhThWGWSyp%2BeVCoJktxWs_niOCCTZjOQWk_RCJ3A%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages