Quarkus: Allow users to select alternatives though the MicroProfile Config

[mkouba]

Currently, an alternative must be annotated with @Priority or @io.quarkus.arc.AlternativePriority. It should be possible to use MP Config to select an alternative as well.

The simplest approach would be to list all selected alternatives, e.g. quarkus.arc.selected-alternatives=org.acme.Foo. It's not possible to specify the priority but could take the spec approach where components annotated with @Priority take precedence.

[mkouba]

@stuartwdouglas @manovotn FYI

[geoand]

I sort of remember discussing something like this in the past. I agree we should have this

[manovotn]

Fine by me; just two notes - ~firstly, in spec you can have several alternatives enabled and the ordering inside beans.xml defines which alternative wins (if they both override the same bean). Are we going to have something similar here?~

EDIT: The above is wrong. Ordering only matters for interceptors/decorators. For alternatives, you get ambiguous res. exception.

And secondly, is this actually better then to include and parse contents of beans.xml as you would with CDI? This way we are adding another thing that exists in CDI but we don't support the standard way and instead define a custom means to do the exact same thing (well, except that we don't have multiple bean archives).

[mkouba]

Are we going to have something similar here?

It could be the same for the property - position in the list defines the ordering.

parse contents of beans.xml as you would with CDI?

Parsing the beans.xml would not be enough. We would have to merge the contents of the descriptors (this is what Weld did for SE for a long time) and that's not standardized either. Also beans.xml enablement implies enablement for bean archives whereas config property is global enablement. Note that we don't support this way of handling bean archives. Moreover, we do attempt to unify configuration in quarkus and so I believe it's a good way, even though it's not a standard.

[manovotn]

position in the list defines the ordering.

Are you able to tell the position? I thought MP config only lets you retrieve the value.

Note that we don't support this way of handling bean archives.

I am aware of that. I was just "thinking aloud". We introduce yet another non-standard thing but on second thought this can actually help people who were using beans.xml enablement to migrate and at the same time it fits into our scenario of one bean archive with global only enablements.

And it would also allow to only enable alternatives for testing which is something people tend to ask for.

I think I am starting to like it as well, +1 :-)

[mkouba]

Are you able to tell the position?

The value is just a list.

[famod]

This might be a silly question, but could that mechanism also be used to select different alternatives per QuarkusTest?

[stuartwdouglas]

Not for @QuarkusTest, at least not without some changes.

We may want to look at a version of QuarkusTest that has a slightly different lifecycle that would allow this.

[stuartwdouglas]

"It's not possible to specify the priority but could take the spec approach where components annotated with @Priority take precedence."

Does this mean it is not possible to replace an alternative that has been annotated with priority?

[mkouba]

Does this mean it is not possible to replace an alternative that has been annotated with priority?

In fact, according to the spec if you enable an alternative in beans.xml and another alternative with @Priority, and both of them satisfy an injection point then an ambiguous dependency exists. At least this is my interpretation and Weld does exactly the same. CC @manovotn

I don't think this beahavior is very useful and so since we would enable them globally we could assign them some default priority. Another approach could be to define the priorities in the config, i.e. something like:

quarkus.arc.alternative.org.acme.Foo=10
org.acme.Foo/alternative/priority=10

[manovotn]

In fact, according to the spec if you enable an alternative in beans.xml and another alternative with @Priority, and both of them satisfy an injection point then an ambiguous dependency exists.

That's correct. Spec isn't clear about this but I think it's implied by the fact that you cannot declare a priority number in beans.xml which means you cannot be sure which bean should "win" during resolution.

we could assign them some default priority.

Or we could make the config always win over priority declared in the code. You probably wouldn't declare alternative in the config if you knew it isn't going to override what's in the code, right?

[stuartwdouglas]

On Thu, 26 Mar 2020 at 19:34, Martin Kouba [e-mail] wrote:

Does this mean it is not possible to replace an alternative that has been
annotated with priority?

In fact, according to the spec if you enable an alternative in beans.xml
and another alternative with @Priority, and both of them satisfy an
injection point then an ambiguous dependency exists. At least this is my
interpretation and Weld does exactly the same. CC @manovotn
https://github.com/manovotn

I don't think this beahavior is very useful and so since we would enable
them globally we could assign them some default priority. Another approach
could be to define the priorities in the config, i.e. something like:

quarkus.arc.alternative.org.acme.Foo=10
org.acme.Foo/alternative/priority=10

I don't really think that is necessary, I think that if a bean is enabled
through config then it should just take priority over everything (i.e. the
same as @Priority(Integer.MAX_VALUE).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/quarkusio/quarkus/issues/8135#issuecomment-604298456,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACQG64O6M7E3DNR22KU363RJMHQHANCNFSM4LTJBZGA
.

[mkouba]

I think that if a bean is enabled
through config then it should just take priority over everything (i.e. the
same as @priority(Integer.MAX_VALUE)

Sounds reasonable.

[mkouba]

WIP is here: https://github.com/mkouba/quarkus/tree/issue-8135

One thing I don't like is that the quarkus.arc.selected-alternatives= approach does not scale well if there are multiple alternative classes we need to enable. YAML could be a little bit more readable. I've also tried to switch to regular expressions - that would be pretty powerful but not very nice for simple cases (a user would have to escape dots in package names).

[famod]

I've also tried to switch to regular expressions - that would be pretty powerful but not very nice for simple cases (a user would have to escape dots in package names).

Not the prettiest solution, but maybe something like quarkus.arc.selected-alternatives=%regex[...] could be used, e.g.:
http://maven.apache.org/plugins/maven-assembly-plugin/advanced-descriptor-topics.html#Using_Regular_Expressions_to_Exclude_Files

[mkouba]

Hm, I was thinking about the syntax used in CDI exclude filters, i.e. org.acme.* to match all classes from the given package and org.acme.** to match the package and subpackages. And maybe also the possibility to only match the simple name, i.e. Foo to match org.acme.Foo.

[manovotn]

+1 to similarity with CDI filters

And maybe also the possibility to only match the simple name, i.e. Foo to match org.acme.Foo.

This can be misleading, what happens when you have Foo and FooBar or BarFoo beans?

[mkouba]

This can be misleading, what happens when you have Foo and FooBar or BarFoo beans?

I don't think so. It would be exact match only, i.e. neither FooBar nor BarFoo would match...