-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request: MicroProfile-config integration: Allow injecting annotations with jakarta.inject.Qualifier #1679
Comments
FYI - nasty reflection was: package com.google.inject.internal;
import com.google.inject.internal.Annotations.AnnotationChecker;
import org.eclipse.microprofile.config.inject.ConfigProperty;
import java.lang.annotation.Annotation;
import java.util.Collections;
public class ConfigPropertyOrAnnotationChecker extends AnnotationChecker {
private final AnnotationChecker delegate;
/**
* Constructs a new checker that looks for annotations of the given types.
*
* @param delegate delegate checker
*/
public ConfigPropertyOrAnnotationChecker(Object delegate) {
super(Collections.singleton(ConfigProperty.class));
this.delegate = (AnnotationChecker) delegate;
}
@Override
boolean hasAnnotations(Class<? extends Annotation> annotated) {
return annotated == ConfigProperty.class || delegate.hasAnnotations(annotated);
}
} and try {
Field bindingAnnotationCheckerField = Annotations.class.getDeclaredField("bindingAnnotationChecker");
bindingAnnotationCheckerField.setAccessible(true);
Field modifiersField = Field.class.getDeclaredField("modifiers");
modifiersField.setAccessible(true);
modifiersField.setInt(
bindingAnnotationCheckerField, bindingAnnotationCheckerField.getModifiers() & ~Modifier.FINAL);
Object bindingAnnotationChecker = bindingAnnotationCheckerField.get(Annotations.class);
bindingAnnotationCheckerField.set(
Annotations.class, new ConfigPropertyOrAnnotationChecker(bindingAnnotationChecker));
bindingAnnotationCheckerField.setAccessible(false);
} catch (NoSuchFieldException | IllegalAccessException e) {
throw new ConfigurationException(Collections.singleton(new Message(e.getLocalizedMessage())));
} |
Field + Construct interceptors will be a much better option here, Qualifier should already be there - Strictly speaking this should actually be more than do-able I'll join you on this one |
TypeListeners seem to be the best route |
Sorry not really sure how they help... the point is to make things annotated with ConfigProperty injectable - do listeners allow not having a binding but influencing how to inject the value? Or were you suggesting writing an extension that listened to type and then added a binding - the challenge there is that you can't create a key with any annotation, which doesn't contain javax.inject.Qualifier or com.google.inject.BindingAnnotation, which ConfigProperty does not |
Yep - I got pretty well through it but very busy time work wise for me right now - Intercepting on the injection with a TypeListener and pushing the value into the configuration seems to be bringing some success for me, support for 3rd party annotations generally goes this route to cater for these scenarios, Reflection probably not going to get away from, in one way or the other, but the binding mechanism :) I need it for something i'm working on during the 9-5 as well, but have a lot in front before I get there :) I'm doing an approach very similar to the jsr250 implementation
|
Your work is amazing and inspiring and makes me wonder - "how on earth did you figure out how to do that?" The documentation doesn't really go into much detail about extending or plugging in, and from what experimentation I've tried - I can't see how only having the TypeListener is able to do the injection and communicate to Guice internals that it's already taken care of... if I try with a simple listener and add a memberInjector and just set the value, Guice still complains. Is there some magic communication that happens when you ask the "encounter" for the Injector and then ask it for a provider? I see the key is rewritten to look for Named but how does Guice know that you've done that for it? Ultimately, I would like to not have to prebind anything - and this mechanism looks really great if I can just get the Config object and get the value (which is easy) then inject it, it would be quite nice to use - but squelching Guice's lookup failures is the part I can't make work. |
Ohhhhhh… This doesn't work if you have |
OK that is strange I've already done this on a few of my Guiced-EE implementations and that wasn't the case - I will check it and get back to you, definitely supposed to override any @Inject settings hmm - To make sure though, this best works with PrivateModules with expose clauses - sorry about the delay the holidays in April were a few too many put quite a bit of the side-work on hold getting back into work xD I'm going a bit overboard on the impl though, doing a main MP implementation, not just for config, let's see if I can keep them loosely coupled xD |
@GedMarc - Here's a draft PR to show you what I haven't been able to make work - but in the context of your system. And reference showing that the desired behavior for ConfigProfile should include @Inject
@ConfigProperty(name = "my.long.property")
private Long injectedLongValue; |
Duplicate of #1383 |
…rt for `toProvider(...)` to instances of `jakarta.inject.Provider` or classes/keys/typeLiterals of type `jakarta.inject.Provider`. See #1383 (comment) for details of the plans. The Guice 6.0 release will support `javax.inject` _and_ `jakarta.inject` (excluding `toProvider()` support for `jakarta.inject`), and the Guice 7.0+ release will remove the `javax.inject` references. Further background on these issues: * #1630 * #1679 * #1490 * #1383 PiperOrigin-RevId: 526763665
This does not add support for `toProvider(...)` to instances of `jakarta.inject.Provider` or classes/keys/typeLiterals of type `jakarta.inject.Provider`. See #1383 (comment) for details of the plans. The Guice 6.0 release will support `javax.inject` _and_ `jakarta.inject` (excluding `toProvider()` support for `jakarta.inject`), and the Guice 7.0+ release will remove the `javax.inject` references. Further background on these issues: * #1630 * #1679 * #1490 * #1383 PiperOrigin-RevId: 526763665
This does not add support for `toProvider(...)` to instances of `jakarta.inject.Provider` or classes/keys/typeLiterals of type `jakarta.inject.Provider`. See #1383 (comment) for details of the plans. The Guice 6.0 release will support `javax.inject` _and_ `jakarta.inject` (excluding `toProvider()` support for `jakarta.inject`), and the Guice 7.0+ release will remove the `javax.inject` references. Further background on these issues: * #1630 * #1679 * #1490 * #1383 PiperOrigin-RevId: 526763665
This does not add support for `toProvider(...)` to instances of `jakarta.inject.Provider` or classes/keys/typeLiterals of type `jakarta.inject.Provider`. See #1383 (comment) for details of the plans. The Guice 6.0 release will support `javax.inject` _and_ `jakarta.inject` (excluding `toProvider()` support for `jakarta.inject`), and the Guice 7.0+ release will remove the `javax.inject` references. Further background on these issues: * #1630 * #1679 * #1490 * #1383 PiperOrigin-RevId: 526763665
This does not add support for `toProvider(...)` to instances of `jakarta.inject.Provider` or classes/keys/typeLiterals of type `jakarta.inject.Provider`. See #1383 (comment) for details of the plans. The Guice 6.0 release will support `javax.inject` _and_ `jakarta.inject` (excluding `toProvider()` support for `jakarta.inject`), and the Guice 7.0+ release will remove the `javax.inject` references. Further background on these issues: * #1630 * #1679 * #1490 * #1383 PiperOrigin-RevId: 526763665
This does not add support for `toProvider(...)` to instances of `jakarta.inject.Provider` or classes/keys/typeLiterals of type `jakarta.inject.Provider`. See #1383 (comment) for details of the plans. The Guice 6.0 release will support `javax.inject` _and_ `jakarta.inject` (excluding `toProvider()` support for `jakarta.inject`), and the Guice 7.0+ release will remove the `javax.inject` references. Further background on these issues: * #1630 * #1679 * #1490 * #1383 PiperOrigin-RevId: 527349023
You can see a very basic microprofile test configuration here - |
@scr-oath Not sure if you are still interested, I needed to switch to Vert.x as a much higher priority (y) |
Hey @scr-oath @GedMarc , letting you know since you may be targeting Guice 7.0.0, about the new Micronaut Guice project, that depending on your usecase could be a useful replacement: micronaut-projects/micronaut-guice#9 |
I would like to integrate with MicroProfile Config. I got pretty far along, but… in order to allow Guice to allow
@ConfigProperty
, I had to do some very nasty reflection to muck with the innards of the strategyFor so thatensureIsBindingAnnotation(annotationType);
would pass and allow me toKey.get(someType, someConfigPropertyAnnotation)
.Ultimately, I would like to bind the
@ConfigProperty
and, of course, if this snippet can be made to work, any solution is awesome:The text was updated successfully, but these errors were encountered: