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
[Resteasy-2285] Use LocalResteasyProviderFactory instead of ResteasyProviderFactoryImpl #2083
Conversation
*/ | ||
public ResteasyClientBuilderImpl providerFactory(ResteasyProviderFactory providerFactory) | ||
{ | ||
this.providerFactory = providerFactory; | ||
withConfig(providerFactory); |
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'm not convinced about this. By calling withConfig
, you're effectively causing new allocations, as the contents from the provided providerFactory
has to be copied into a new provider factory. Yes, that would now be a LocalResteasyProviderFactory
, but still stuff would be copied, while with the current code, the provided object is directly linked.
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.
Hey @asoldano,
You're right few improvments can be done.
Actually my point about calling withConfig
was to prevent following case:
ResteasyClientBuilder resteasyClientBuilder=new ResteasyClientBuilderImpl();
resteasyClientBuilder.providerFactory(new ResteasyProviderFactoryImpl());
resteasyClientBuilder.register(MyFeature.class);
Because of usage of ResteasyClientBuilderImpl
two intances of MyFeature.class
will be created: one by ClientHelper
and the other by ServerHelper
.
In a standalone client the instance created by ServerHelper
is useless.
So initially I wanted to prevent this creation. Then now I realized it's up to the user to call resteasyClientBuilder.providerFactory()
with the most relevant ResteasyProviderFactory
subtype. In a standalone client it will be the LocalResteasyProviderFactory
and in other cases the ResteasyProviderFactoryImpl
.
I'll do the fix 👍
Thanks
return RuntimeType.CLIENT; | ||
} | ||
}; | ||
providerFactory = new LocalResteasyProviderFactory(); |
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.
This is fine, nice catch :-)
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.
Hi @NicoNes , the proposed changes are basically fine now, thanks. The only concern I have is with the position of the new ResteasyProviderFactoryDelegate class. Is it really needed in the resteasy-core-spi? Are we expecting users to really rely on that? Perhaps it could live in resteasy-core, in the same package of the ResteasyProviderFactoryImpl class.
Hi @asoldano , I did not pay attention to that but you're right there is no good reason for this class to be in resteasy-core-spi. I moved it into the package you said. Thanks |
Signed-off-by: NicoNes <nicolas.nesmon@gmail.com>
…y on client side Signed-off-by: NicoNes <nicolas.nesmon@gmail.com>
Signed-off-by: NicoNes <nicolas.nesmon@gmail.com>
Signed-off-by: NicoNes <nicolas.nesmon@gmail.com>
Signed-off-by: NicoNes <nicolas.nesmon@gmail.com>
Signed-off-by: NicoNes <nicolas.nesmon@gmail.com>
Signed-off-by: NicoNes <nicolas.nesmon@gmail.com>
@NicoNes , I've thought about this... and I believe at then of the day it's acceptable, yes. |
No description provided.