-
|
I have a a custom validator which looks like: @Dependent
public class GreetingListValidator implements ConstraintValidator<GreetingList, String> {
@ConfigProperty(name = "greeting.list", defaultValue = "hello")
String greetingList;
private Set<String> greetings = Collections.emptySet();
@Override
public void initialize(GreetingList constraintAnnotation) {
System.out.println("Greeting List is " + greetingList+" in GreetingListValidator");
greetings = Arrays.stream(greetingList.split(","))
.map(String::trim).map(String::toLowerCase)
.collect(Collectors.toSet());
}
@Override
public boolean isValid(String value, ConstraintValidatorContext context) {
return greetings.contains(value.trim().toLowerCase());
}
}I compile (with native compilation) and deploy my app. The effective greeting list is the default one: hello . It does not contain bonjour. The external configuration is not taken. :'( Now, as a workaround, I moved my validation code into a CDI bean: @ApplicationScoped
public class GreetingListService {
@ConfigProperty(name = "greeting.list", defaultValue = "hello")
String greetingList;
private Set<String> greetings = Collections.emptySet();
@PostConstruct
public void initialize() {
System.out.println("Greeting List is " + greetingList+" in GreetingListValidator");
greetings = Arrays.stream(greetingList.split(","))
.map(String::trim).map(String::toLowerCase)
.collect(Collectors.toSet());
}
public boolean isValid(String value) {
return greetings.contains(value.trim().toLowerCase());
}
}
@Dependent
public class GreetingListValidator implements ConstraintValidator<GreetingList, String> {
@Inject
String greetingListService;
@Override
public void initialize(GreetingList constraintAnnotation) {
}
@Override
public boolean isValid(String value, ConstraintValidatorContext context) {
return greetingListService.isValid(value);
}
}And this works! The environment variable is taken. :-) My question is about Validator lifecycle. Are they created as CDI beans? What is the difference between a Validator initialization and a CDI bean inialization regarding @ConfigProperty injection |
Beta Was this translation helpful? Give feedback.
Replies: 5 comments 16 replies
-
|
Answering to myself, I have just noticed during native compilation: The |
Beta Was this translation helpful? Give feedback.
-
Well, not exactly at build time. The CDI container is started during the |
Beta Was this translation helpful? Give feedback.
-
|
@mkouba Thanks for explaining, I am not sure to grasp everything though, it seems a bit complicated. Lesson learned, I tried several alternatives. @Dependent
public class GreetingListValidator implements ConstraintValidator<GreetingList, String> {
@ConfigProperty(name = "greeting.list", defaultValue = "hello")
Provider<String> greetingList;
private Set<String> greetings;
@Override
public void initialize(GreetingList constraintAnnotation) {
String s = greetingList.get();
System.out.println("Greeting List is " + s + " in GreetingListValidator");
greetings = Arrays.stream(s.split(","))
.map(String::trim).map(String::toLowerCase)
.collect(Collectors.toSet());
}
@Override
public boolean isValid(String value, ConstraintValidatorContext context) {
return greetings.contains(value.trim().toLowerCase());
}
}Yet this is not enough. The @Dependent
public class GreetingListValidator implements ConstraintValidator<GreetingList, String> {
@ConfigProperty(name = "greeting.list", defaultValue = "hello")
Provider<String> greetingList;
private Set<String> greetings;
@Override
public void initialize(GreetingList constraintAnnotation) {
}
@Override
public boolean isValid(String value, ConstraintValidatorContext context) {
if (greetings == null) {
String s = greetingList.get();
System.out.println("Greeting List is " + s + " in GreetingListValidator");
greetings = Arrays.stream(s.split(","))
.map(String::trim).map(String::toLowerCase)
.collect(Collectors.toSet());
}
return greetings.contains(value.trim().toLowerCase());
}
}This another possible workaround. |
Beta Was this translation helpful? Give feedback.
-
That's more a question for Bean Validation guys :-) |
Beta Was this translation helpful? Give feedback.
-
|
I'm really not a "Bean Validation guy", but seeing Guillaume is on PTO... No, I don't know of a BV-specific way to initialize stuff on runtime init. I'd look into the Quarkus-specific startup initialization features: https://quarkus.io/guides/cdi-reference#startup_event You'd also need a way to retrieve runtime config, so not using annotations... I suppose if you use some Smallrye API, you can achieve that? |
Beta Was this translation helpful? Give feedback.
-
|
I misread the initial question, so I'll rephrase my answer: No, I don't know of a BV-specific way to initialize stuff on runtime init. Your solution of injecting a |
Beta Was this translation helpful? Give feedback.
-
|
I am still puzzled by the fact that validator init doesn't behave like normal CDI bean init. |
Beta Was this translation helpful? Give feedback.
-
Yes, because if an extension also calls a method upon the component then lazy instantiation does not help at all.
Well, I can imagine that we fail the build if we're pretty sure that it's a real problem. Otherwise we'll just annoy the users with yet another configuration knob. So we could throw an exception:
The question is whether we should only validate the injection points when the native image is being built. I guess that we should because that's the only situation where it matters. Like you mentioned we should also provide a way to eliminate false positives. An annotation with a clear name should be fine. But naming is hard, right ;-). Maybe something like |
Beta Was this translation helpful? Give feedback.
-
Not sure what "represents a component of an extension [...]" means. Just in case you mean "something declared explicitly by the extension as problematic", I'd like to mention that this problem could affect potentially any bean, e.g. a completely custom bean (no implemented interface) injected into a That's one reason why I was thinking of a static init validation rather than build time validation (another reason below).
Probably unrelated to your point, but I was thinking that for injected So it's not about validating injection points, but more about validating... injections? IDK the proper wording.
Makes sense to me.
Anyway, that's something we could happily bikeshed on once we open an issue/PR :) If you think it makes sense to open one. |
Beta Was this translation helpful? Give feedback.
-
|
We also noticed the |
Beta Was this translation helpful? Give feedback.
-
Yes, we could validate the
@yrodiere Yes, I think that it makes sense and I will try to prepare a prototype that could be discussed further...
@gquintana Yes, a |
Beta Was this translation helpful? Give feedback.
-
More seriously, you could also store such exceptions in a collection that would be checked after static init, and make sure to report them then (potentially as suppressed exception, if static init failed for another reason). Not perfect, but probably the best we can do.
Thanks a lot @mkouba! |
Beta Was this translation helpful? Give feedback.
Well, not exactly at build time. The CDI container is started during the
STATIC_INITbootstrap phase. For a native executable build, however, theSTATIC_INITbootstrap phase runs as part of the native build process. I.e. if a CDI bean is initialized duringSTATIC_INITof a native executable build then the@ConfigPropertyinjection points cannot reflect the runtime values (configured with system properteis and ENV variables). And it seems thatConstraintValidators are initialized during theSTATIC_INITphase.