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

Fixes for OSGi, remove automatic creation of executor for async requests #538

Closed

Conversation

tdraier
Copy link
Contributor

@tdraier tdraier commented Sep 15, 2023

Hi,

Here's a PR with different fixes for OSGi, and a fix for #537 . This has been done on the javax branch but should be portable on master.

On OSGi side, I've changed version ranges so that it can be deployed on all compatible versions of servlet (3+) /websocket (1.1+) and graphql (the current code works well with graphql 20 and 21). Also updated the gradle dependencies accordingly.
I've changed GraphQLMutationProvider and GraphQLSubscriptionProvider that were both implementing the same getFields methods from GraphQLFieldsProvider (removed), preventing any provider to implement both interfaces. I'm not sure what was the reason to have a common getFields() method but the code seems more simple with the 2 different methods. Also exposed the getSubscriptionProtocolFactory() from websocket endpoint, as I need to be able to call it externally in my code ..

I've slightly changed the GraphQLConfiguration.Builder so that we can provide some base configuration from OSGi with a GraphQLConfigurationProvider. Also added some safeguard to prevent providing invocationInputFactory and invocationInputFactoryBuilderat the same time.

However, a big change in GraphqlConfiguration is the removal of the thread pool executor creation for async support, as explained in #537 . In my opinion it cannot be created by the GraphQLConfiguration object or its builder, but should be created and managed by the servlet itself. The code creating a default thread pool (and destroying it) could be moved to AbstractGraphQLHttpServlet - but it should be possible to skip the creation of that default pool if we want to use our own executor. Tell me what do you think, I will update the PR if needed.

Copy link
Member

@federicorispo federicorispo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you create some tests for the automatic creation of the executor?

@@ -1,6 +1,7 @@
package graphql.kickstart.servlet;

import graphql.schema.GraphQLSchema;
import java.util.concurrent.ThreadPoolExecutor;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove unused import

@@ -3,11 +3,7 @@
import graphql.schema.GraphQLFieldDefinition;
import java.util.Collection;

public interface GraphQLMutationProvider extends GraphQLFieldProvider {
public interface GraphQLMutationProvider extends GraphQLProvider {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would not touch so easily these interfaces since they are the contract to the outside and I think there are projects that could rely on them.

Same thing for the deletion of the GraphQLFieldProvider and the update of the GraphQlSubscriptionProvider

import lombok.Setter;

@Setter
class OsgiSchemaBuilder {
public class OsgiSchemaBuilder {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please create some unit tests for this builder since it has some login in it?

@federicorispo federicorispo deleted the branch graphql-java-kickstart:javax February 8, 2024 21:51
@federicorispo
Copy link
Member

@tdraier The javax branch is no longer maintained since the artifact of the javax flavour is generated on the master branch during the build phase. Could you please reopen this PR pointing to the master branch?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants