-
Notifications
You must be signed in to change notification settings - Fork 114
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
Fixes for OSGi, remove automatic creation of executor for async requests #538
Conversation
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.
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; |
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.
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 { |
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 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 { |
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.
Could you please create some unit tests for this builder since it has some login in it?
@tdraier The |
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 thegetSubscriptionProtocolFactory()
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 aGraphQLConfigurationProvider
. Also added some safeguard to prevent providinginvocationInputFactory
andinvocationInputFactoryBuilder
at 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.