Skip to content
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

Merged
merged 7 commits into from Jul 26, 2019

Conversation

NicoNes
Copy link
Contributor

@NicoNes NicoNes commented Jun 27, 2019

No description provided.

@NicoNes NicoNes changed the title [Resteasy-2285] WIP Use LocalResteasyProviderFactory instead of ResteasyProviderFactoryImpl [Resteasy-2285] Use LocalResteasyProviderFactory instead of ResteasyProviderFactoryImpl Jun 27, 2019
*/
public ResteasyClientBuilderImpl providerFactory(ResteasyProviderFactory providerFactory)
{
this.providerFactory = providerFactory;
withConfig(providerFactory);
Copy link
Member

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.

Copy link
Contributor Author

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();
Copy link
Member

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 :-)

@asoldano asoldano added the main label Jun 27, 2019
Copy link
Member

@asoldano asoldano left a 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.

@NicoNes
Copy link
Contributor Author

NicoNes commented Jul 26, 2019

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.
Since registerBuiltin() is protected, the delegate cannot invoke resteasyProviderFactoryDelegator.registerBuiltin(). So I just throw an UnsupportedOperationException for this method. Let me know if you think it is acceptable.

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>
@asoldano
Copy link
Member

@NicoNes , I've thought about this... and I believe at then of the day it's acceptable, yes.

@asoldano asoldano merged commit 07b1c91 into resteasy:master Jul 26, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
2 participants