-
Notifications
You must be signed in to change notification settings - Fork 2.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
Move BasicAuthenticationMechanism to synthetic bean #45442
Conversation
Thanks for your pull request! Your pull request does not follow our editorial rules. Could you have a look?
This message is automatically generated by a bot. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually moved it from synthetic bean to normal one few releases back. I thought it was better to have normal beans as they are ready sooner in case someone injected HTTP authenticator very early as it is a singleton I think.
But it's hardly important, I agree it is easier to use defautlBean()
rather than annotation transformer. I don't mind changes, but I'd like to check - the reason why you are proposing this is to avoid transformer because it is requires more operations (like the annotation transformer predicate is run many times), correct?
if (buildTimeConfig.auth.basic.isPresent() && buildTimeConfig.auth.basic.get()) { | ||
securityInformationProducer.produce(SecurityInformationBuildItem.BASIC()); | ||
} | ||
|
||
return AdditionalBeanBuildItem.builder().setUnremovable().addBeanClass(BasicAuthenticationMechanism.class).build(); | ||
SyntheticBeanBuildItem.ExtendedBeanConfigurator configurator = SyntheticBeanBuildItem |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think default bean scope is @Dependent
and you dropped @Singleton
so you are making it dependent. It could be actually good idea, but first, I'd need to inspect our code and probably make same change for all the auth mechanisms. Is this intentional? if not, let's keep it a singleton for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I picked up on that and have the change done locally
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BTW I glanced at current impl. and I actually think all the HTTP auth mechanisms would be in 99 % cases better off as dependent (sometimes users can inject them if they provide alternatives, but how many users does it?), I think we just use them once. I'll re-check later this week if I didn't miss something and open PR when Sergey is back.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Provided that it is worse to have beans we don't need at CDI container, because these java class instances will live anyway. And with the dependent, we won't be proxying beans either. I am not sure if it is worth it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍🏽
Yeah, the synthetic bean is much better for this kind of thing. Oddly enough the tests are now failing, so I need to check and see what's going on... |
Ok @geoand , we can do it then. |
👍🏽 PR updated |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Status for workflow
|
No description provided.