Giter Club home page Giter Club logo

smallrye-graphql's Introduction

Contributing

Want to contribute? Great! We try to make it easy, and all contributions, even the smaller ones, are greatly welcome. This includes bug reports, fixes, documentation.

All SmallRye projects use GitHub Issues to manage issues. Open an issue directly in GitHub within the appropriate SmallRye project repository.

Becoming a Project Committer

Through continued contributions to SmallRye projects, other committers on the project can nominate you to become a committer too!

Check out the nomination process for full details.

All original contributions to SmallRye projects are licensed under the ASL - Apache License, version 2.0 or later, or, if another license is specified as governing the file or directory being modified, such other license.

All contributions are subject to the Developer Certificate of Origin (DCO). The DCO text is also included verbatim in the dco.txt file in the root directory of each repository.

Before you Contribute

To contribute, use GitHub Pull Requests, from your own fork.

Code Reviews

All submissions, including submissions by project members, need to be reviewed before they are merged.

Continuous Integration

We’re all human, so SmallRye projects use continuous integration to ensure consistency, particularly as most SmallRye projects need to pass the applicable MicroProfile TCK for that specification. Each pull request triggers a full build of the project. Please make sure to monitor the output of the build and act accordingly.

Tests and Documentation are not optional

Don’t forget to include tests in your pull requests. Also, don’t forget the documentation (Javadoc).

Setup

If you have not done so on your machine, you need to:

  • Install Git and configure your GitHub access

  • Install Java SDK (OpenJDK recommended)

  • Install Maven

IDE Config and Code Style

SmallRye projects have a strictly enforced code style. Code formatting is done by the Eclipse code formatter, using the config files found in Code Rules. By default when you run mvn install the code will be formatted automatically. When submitting a pull request the CI build will fail if running the formatter results in any code changes, so it is recommended that you always run a full Maven build before submitting a pull request.

Eclipse Setup

Open the Preferences window, and then navigate to JavaCode StyleFormatter. Click Import and then select the eclipse-format.xml file in the coderules directory.

Next navigate to JavaCode StyleOrganize Imports. Click Import and select the eclipse.importorder file.

IDEA Setup

Open the Preferences window, navigate to Plugins and install the [Eclipse Code Formatter Plugin](https://plugins.jetbrains.com/plugin/6546-eclipse-code-formatter).

Restart your IDE, open the Preferences window again and navigate to Other SettingsEclipse Code Formatter.

Select Use the Eclipse Code Formatter, then change the Eclipse Java Formatter Config File to point to the eclipse-format.xml file in the coderules directory. Make sure the Optimize Imports box is ticked, and select the eclipse.importorder file as the import order config file.

Signing Commits

Signing commits is required to make sure that the contributor matches the author. To be able to sign commits, use the following instructions: https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits

The small print

This project is an open source project, please act responsibly, be nice, polite, and enjoy!

smallrye-graphql's People

Contributors

acanda avatar andro999b avatar andymc12 avatar cherrydev avatar computerlove avatar craig-day avatar debu999 avatar dependabot-preview[bot] avatar dependabot[bot] avatar eamelink avatar gabrielsson avatar gsmet avatar jmartisk avatar kenfinnigan avatar ladicek avatar marceloverdijk avatar mskacelik avatar nandorholozsnyak avatar patope avatar phillip-kruger avatar pipinet avatar radcortez avatar robp94 avatar rokkim avatar rubik-cube-man avatar smallrye-ci avatar t1 avatar velias avatar vladi-bnv avatar ybroeker avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

smallrye-graphql's Issues

gradle.properties

See if we can get the version of smallrye from the pom rather than from gradle.properties. This should make release easier

Serializable model

build an Serializable model (replace the graphql-java model) from the jandex index, then use that to build the graphql-java model.

This will allow other indexers to build the model, and allow Quarkus to create the model on compile.

Get JDK 11 to pass the TCK

I'm sure you are aware of this. I am getting errors during ExecutionDynamicTest execution , it seems there is a pattern for the 4 of 3 specific runs that have been failing. I have not taken the time yet of going deeper, but I guess that by getting a better context from you I could accelerate my understanding.

I also noted your GitHub action is currently succeeding with JDK 8.

SmallRye CI / build with jdk 8
succeeded 1 hour ago in 3m 22s

My current configuration:

Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555; 2019-04-04T15:00:29-04:00)
Java version: 11.0.1, vendor: Oracle Corporation, 

Fetching the latest changes, now the errors have moved to 3 specific runs, and this is the current output I'm getting:

[ERROR]   Run 19: ExecutionDynamicTest>Arquillian.run:138->testSpecification:88->runTest:128 bankbalance failed data.updateBankBalance.bankBalance
Expected: R 80435.34
     got: R 80435,34
...
...
...
[ERROR]   Run 65: ExecutionDynamicTest>Arquillian.run:138->testSpecification:88->runTest:128 bankbalanceZAR failed data.updateBankBalanceInZAR.bankBalance
Expected: R 106963.87
     got: R 106963,00
...
...
...
[ERROR]   Run 79: ExecutionDynamicTest>Arquillian.run:138->testSpecification:88->runTest:128 basicScalar failed data.testScalarsInPojo.formattedByteObject
Expected: SFr.123
     got: CHF123
 ; data.testScalarsInPojo.formattedLongObject
Expected: 123'456'789
     got: 123?456?789
 ; data.testScalarsInPojo.formattedLongPrimitive
Expected: 123'456'789
     got: 123?456?789
[INFO]
[INFO]
[ERROR] Tests run: 138, Failures: 1, Errors: 0, Skipped: 0
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for SmallRye: MicroProfile GraphQL Parent 1.0.1-SNAPSHOT:
[INFO]
[INFO] SmallRye: MicroProfile GraphQL Parent .............. SUCCESS [  1.218 s]
[INFO] SmallRye: MicroProfile GraphQL Implementation ...... SUCCESS [  5.795 s]
[INFO] SmallRye: MicroProfile GraphQL Implementation :: Servlet SUCCESS [  0.517 s]
[INFO] SmallRye: MicroProfile GraphQL Implementation :: VertX SUCCESS [  2.682 s]
[INFO] SmallRye: MicroProfile GraphQL Implementation :: JAX-RS SUCCESS [  0.401 s]
[INFO] SmallRye: MicroProfile GraphQL TCK ................. FAILURE [ 49.899 s]
[INFO] SmallRye: MicroProfile GraphQL Runner .............. SKIPPED
[INFO] Empty Release Project to Avoid Maven Bug ........... SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  01:00 min
[INFO] Finished at: 2020-02-25T11:36:50-05:00
[INFO] ------------------------------------------------------------------------

This is the output of my build indicating the specific errors (for last week):

[ERROR]   Run 4: ExecutionDynamicTest>Arquillian.run:138->testSpecification:88->runTest:127 jsonbProps failed data.allHeroes[dateOfLastCheckin=08/27/2019].patrolStartTime
Expected: 12:30
     got: 12:00
 ; data.allHeroes[dateOfLastCheckin=08/27/2019].timeOfLastBattle
Expected: 05:17:33 26-08-2019
     got: null
...
...
...
[ERROR]   Run 19: ExecutionDynamicTest>Arquillian.run:138->testSpecification:88->runTest:127 bankbalance failed data.updateBankBalance.bankBalance
Expected: R 80435.34
     got: R 80435,34
...
...
...
[ERROR]   Run 63: ExecutionDynamicTest>Arquillian.run:138->testSpecification:88->runTest:127 bankbalanceZAR failed data.updateBankBalanceInZAR.bankBalance
Expected: R 106963.87
     got: R 106963,00
...
...
...
[ERROR]   Run 74: ExecutionDynamicTest>Arquillian.run:138->testSpecification:88->runTest:127 basicScalar failed data.testScalarsInPojo.formattedByteObject
Expected: SFr.123
     got: CHF123
 ; data.testScalarsInPojo.formattedLongObject
Expected: 123'456'789
     got: 123?456?789
 ; data.testScalarsInPojo.formattedLongPrimitive
Expected: 123'456'789
     got: 123?456?789
[INFO]
[INFO]
[ERROR] Tests run: 138, Failures: 1, Errors: 0, Skipped: 0
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for SmallRye: MicroProfile GraphQL Parent 1.0.0-SNAPSHOT:
[INFO]
[INFO] SmallRye: MicroProfile GraphQL Parent .............. SUCCESS [  4.839 s]
[INFO] SmallRye: MicroProfile GraphQL Implementation ...... SUCCESS [ 11.154 s]
[INFO] SmallRye: MicroProfile GraphQL Implementation :: Servlet SUCCESS [  0.532 s]
[INFO] SmallRye: MicroProfile GraphQL Implementation :: VertX SUCCESS [  4.972 s]
[INFO] SmallRye: MicroProfile GraphQL Implementation :: JAX-RS SUCCESS [  0.468 s]
[INFO] SmallRye: MicroProfile GraphQL TCK ................. FAILURE [01:07 min]
[INFO] SmallRye: MicroProfile GraphQL Runner .............. SKIPPED
[INFO] Empty Release Project to Avoid Maven Bug ........... SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  01:29 min
[INFO] Finished at: 2020-02-25T11:01:41-05:00
[INFO] ------------------------------------------------------------------------

Thank you in ahead for any insight you can provided and congrats for this first release

Support for multiple apps

When I use this implementation, I find I can only make it work when I package the impl JARs in the same web app as the rest of the application. If I try to package it as an OpenLiberty feature, then it fails due to (1) classloading issues and (2) lack of separation between the apps (i.e. the same types end up in the schema for multiple apps). I haven't tried it, but I assume that the same issues might occur if the SmallRye impl JARs are in a shared library referenced by multiple applications.

NoSuchMethodException logged when query/mutation returns a `Collections.singletonList(...)`

I have a test case with a query like:

    @Query("allWidgetsUnableToSerialize")
    public List<Widget> getAllWidgetsThatWeCannotSerialize() {
        return Collections.singletonList(new WidgetWithSerializationFailure("Eraser", 50, 0.3));
    }

It's actually testing the error handling, but I don't think it is getting that far. Instead it is failing in CollectionHelper with the following exception:

java.lang.NoSuchMethodException: java.util.Collections$SingletonList.<init>()
	at java.base/java.lang.Class.newNoSuchMethodException(Class.java:637)
	at java.base/java.lang.Class.getConstructor(Class.java:679)
	at io.smallrye.graphql.bootstrap.schema.helper.CollectionHelper.newCollection(CollectionHelper.java:50)
	at io.smallrye.graphql.bootstrap.datafetcher.TransformableDataFetcherHelper.transform(TransformableDataFetcherHelper.java:48)
	at io.smallrye.graphql.bootstrap.datafetcher.ReflectionDataFetcher.get(ReflectionDataFetcher.java:98)
	at graphql.execution.ExecutionStrategy.fetchField(ExecutionStrategy.java:272)
	at graphql.execution.ExecutionStrategy.resolveFieldWithInfo(ExecutionStrategy.java:200)
	at graphql.execution.AsyncExecutionStrategy.execute(AsyncExecutionStrategy.java:74)
	at graphql.execution.Execution.executeOperation(Execution.java:165)
	at graphql.execution.Execution.execute(Execution.java:106)
	at graphql.GraphQL.execute(GraphQL.java:623)
	at graphql.GraphQL.parseValidateAndExecute(GraphQL.java:556)
	at graphql.GraphQL.executeAsync(GraphQL.java:520)
	at graphql.GraphQL.execute(GraphQL.java:450)
	at io.smallrye.graphql.execution.ExecutionService.execute(ExecutionService.java:125)
	at io.smallrye.graphql.servlet.SmallRyeGraphQLExecutionServlet.handleInput(SmallRyeGraphQLExecutionServlet.java:108)
	at io.smallrye.graphql.servlet.SmallRyeGraphQLExecutionServlet.doPost(SmallRyeGraphQLExecutionServlet.java:81)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:706)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
	at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1230)
	at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:729)
	at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:426)
	at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1226)
	at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1010)
	at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:75)
	at com.ibm.ws.webcontainer40.servlet.CacheServletWrapper40.handleRequest(CacheServletWrapper40.java:83)
	at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:938)
	at com.ibm.ws.webcontainer.osgi.DynamicVirtualHost$2.run(DynamicVirtualHost.java:279)
	at com.ibm.ws.http.dispatcher.internal.channel.HttpDispatcherLink$TaskWrapper.run(HttpDispatcherLink.java:1134)
	at com.ibm.ws.http.dispatcher.internal.channel.HttpDispatcherLink.wrapHandlerAndExecute(HttpDispatcherLink.java:415)
	at com.ibm.ws.http.dispatcher.internal.channel.HttpDispatcherLink.ready(HttpDispatcherLink.java:374)
	at com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:551)
	at com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.handleNewRequest(HttpInboundLink.java:484)
	at com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.processRequest(HttpInboundLink.java:346)
	at com.ibm.ws.http.channel.internal.inbound.HttpICLReadCallback.complete(HttpICLReadCallback.java:70)
	at com.ibm.ws.tcpchannel.internal.WorkQueueManager.requestComplete(WorkQueueManager.java:504)
	at com.ibm.ws.tcpchannel.internal.WorkQueueManager.attemptIO(WorkQueueManager.java:574)
	at com.ibm.ws.tcpchannel.internal.WorkQueueManager.workerRun(WorkQueueManager.java:958)
	at com.ibm.ws.tcpchannel.internal.WorkQueueManager$Worker.run(WorkQueueManager.java:1047)
	at com.ibm.ws.threading.internal.ExecutorServiceImpl$RunnableWrapper.run(ExecutorServiceImpl.java:239)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:825)

I think that we only need to check whether the object passed to newCollection in an instance of Collection or List rather than checking it's exact type. I have a fix in mind - PR should be coming soon.

Make the MP Metrics support pluggable

Ideally, the SmallRye GraphQL project would not depend on the SmallRye Metrics implementation - but instead would only depend on the MP Metrics APIs. That would allow containers like Open Liberty to plug-in different Metrics implementations.

Error message logged in CollectionHelper

I see a lot of ERROR [io.smallrye.graphql.bootstrap.schema.helper.CollectionHelper] (default task-1) Can not create new collection of [java.util.Collections$SingletonList] and [java.util.Collections$UnmodifiableRandomAccessList] messages in my logs. That's because the CollectionHelper has a leaky logic for determining what type to create.

A fix should not be very hard. I don't see any tests except for the TCK, so there's nothing to update there, is it? Should I go for a PR?

Add support for Interfaces

This include whe case where the return type is an interface, when the class is marked with @Interface and adding @Queries in an Interface.

NPE while implementing java.io.Serializable

Implementing java.io.Serializable in a bean used in the GraphQL-schema leads to

java.lang.NullPointerException
at deployment.person-example-1.0.0-SNAPSHOT.war//io.smallrye.graphql.schema.type.OutputTypeCreator.createInterface(OutputTypeCreator.java:166)

Attached you find the full stacktrace and a modified graphql-example-project for reproduction. There I changed com.github.phillipkruger.user.Person, so that it implements java.io.Serializable.

Thank you very much.

modifed_graphql-example-master.zip
stacktrace.txt

Schema doesn't include parent class fields

I have the following JPA classes:

@XmlTransient
@XmlAccessorType(XmlAccessType.FIELD)
@MappedSuperclass
public abstract class AbstractEntity {

    @Getter
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "id", updatable = false, nullable = false)
    public Long id;

}

This class extends the abstract parent class.

@XmlAccessorType(XmlAccessType.FIELD)
@Entity
@Table(name = "person")
public class Person extends AbstractEntity {

    @Getter @Setter
    private String name;

    @Getter @Setter
    @Column(name = "last_name")
    private String lastName;

    @Getter
    @OneToMany(mappedBy = "person", fetch = FetchType.EAGER)
    private Set<Book> books = new HashSet<>();

}

Generated schema.graphql bellow doen't include the id field:

"Directs the executor to include this field or fragment only when the `if` argument is true"
directive @include(
    "Included when true."
    if: Boolean!
  ) on FIELD | FRAGMENT_SPREAD | INLINE_FRAGMENT

"Directs the executor to skip this field or fragment when the `if`'argument is true."
directive @skip(
    "Skipped when true."
    if: Boolean!
  ) on FIELD | FRAGMENT_SPREAD | INLINE_FRAGMENT

"Marks the field or enum value as deprecated"
directive @deprecated(
    "The reason for the deprecation"
    reason: String! = "No longer supported"
  ) on FIELD_DEFINITION | ENUM_VALUE

type Book {
  name: String
}

"Mutation root"
type Mutation {
}

type Person {
  books: [Book]
  lastName: String
  name: String
}

"Query root"
type Query {
  people(limit: Int, offset: Int): [Person]
  "Get a person using the person's Id"
  person(id: BigInteger): Person
}

Thanks,
Bruno

Source method calling broken

In the latest snapshot version the caling to the source fields happens twice on a call and once even if the query does not contain that call. This did not happen in 1.0.1.

We need a fix and a test case to make sure we do not break this again.

Restructure

change the root level pom to have better structure.

Thorntail to Wildfly in the TCK

Change the TCK to use Wildfly (rather than Thorntail)

It kind of work if you uncomment the pom profile (and comment out the thorntail part) however it only run 1 of the 2 TCK tests when using Wildfly.

There are 2 tests (so the server needs to start twice).

  1. Validation against the schema (Thorntail and Wildfly works)
  2. Test some executions (Thorntail work, Wildfly does not pick up this test ??)

Implement all "Serving over HTTP" use cases (e.g. HTTP GET, HTTP POST application/graphql)

Looking at the source code smallrye-graphql currently only supports the basic POST use case.

As described on https://graphql.org/learn/serving-over-http/ there are more use cases:

  • When receiving an HTTP GET request, the GraphQL query should be specified in the "query" query string.
  • For HTTP POST requests, if the "query" query string parameter is present (as in the GET example above), it should be parsed and handled in the same way as the HTTP GET case.
  • For HTTP POST requets, if the "application/graphql" Content-Type header is present, treat the HTTP POST body contents as the GraphQL query string.

E.g. in the micronaut-graphql implementation we support all these use cases: https://github.com/micronaut-projects/micronaut-graphql/blob/master/graphql/src/main/java/io/micronaut/configuration/graphql/GraphQLController.java

If you are interested I could help out implementing these use cases.

Let me know.

`@JsonbProperty` name vs `@Query` name on getter

In Open Liberty, this test is failing with the 1.0.1 version of SmallRye GraphQL but passed with the 1.0 version (which was based on a snapshot):
https://github.com/OpenLiberty/open-liberty/blob/e4fac035f7b47befc73e548975df26350ecad662/dev/com.ibm.ws.microprofile.graphql.1.0_fat/test-applications/outputFieldsApp/src/mpGraphQL10/outputFields/OutputFieldsTestServlet.java#L125

The entity object in question is at:
https://github.com/OpenLiberty/open-liberty/blob/e4fac035f7b47befc73e548975df26350ecad662/dev/com.ibm.ws.microprofile.graphql.1.0_fat/test-applications/outputFieldsApp/src/mpGraphQL10/outputFields/Widget.java#L122

The getter method has both @Query("name1") and @JsonbProperty("name2"). In both SPQR and SmallRye 1.0.0, the behavior would have created a schema field named "name1" (based on the Query annotation), but in 1.0.1, it creates a schema field named "name2".

It doesn't look like the spec is clear about this field, but my personal preference is that all MP GraphQL annotations should take precedence over other annotations (like JSON-B, etc.).

Problem with Hibernate PersistentSet

I am using JPA with Hibernate implementation to persist my beans. I am using the same beans in the GraphQL-API. In one of these beans I have a OneToMany-mapping to a Set

	@OneToMany
	@JoinColumn(name = "konzernId")
	private Set<Gesellschaft> gesellschaften;

If I load these beans at runtime this will be a org.hibernate.collection.internal.PersistentSet. When serializing the GraphQL implementation creates a new instance of the PersistentSet in

io.smallrye.graphql.execution.datafetcher.AnnotatedPropertyDataFetcher.get(AnnotatedPropertyDataFetcher.java:73)

and copies the elements of the previous PersistentSet in

io.smallrye.graphql.execution.datafetcher.AnnotatedPropertyDataFetcher.get(AnnotatedPropertyDataFetcher.java:75).

However this leads to a

org.hibernate.LazyInitializationException: failed to lazily initialize a collection, could not initialize proxy - no Session
...
at [email protected]//org.hibernate.collection.internal.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:581)
at [email protected]//org.hibernate.collection.internal.PersistentSet.add(PersistentSet.java:210)

as the session is already and correctly closed at this position. This issue is similar to Hibernate JPA fetch type LAZY #71, however the Set is correctly fetched when the beans are loaded. I also have a REST-API and there the beans including this Set are correctly serialized. The problem only occurs when calling the add-method at the newly initialized PersistentSet.

If the elemtens of the PersistentSet must be copied to a new Set maybe it would be possible to use a new instance of HashSet instead of PersistentSet? As it seems the used Collection-type is determined in

CollectionHelper.getCorrectCollectionType(Class)

Thank you very much.

ClassCastException occurs during error processing

I'm running through some of my older test cases and found a problem with the error processing. Here is the exception I am seeing:

java.lang.ClassCastException: graphql.schema.CoercingParseValueException incompatible with graphql.validation.ValidationError
	at io.smallrye.graphql.execution.error.ExecutionErrorsService.getValidationExtensions(ExecutionErrorsService.java:92)
	at io.smallrye.graphql.execution.error.ExecutionErrorsService.getOptionalExtensions(ExecutionErrorsService.java:84)
	at io.smallrye.graphql.execution.error.ExecutionErrorsService.toJsonError(ExecutionErrorsService.java:70)
	at io.smallrye.graphql.execution.error.ExecutionErrorsService.toJsonErrors(ExecutionErrorsService.java:51)
	at io.smallrye.graphql.execution.ExecutionService.addErrorsToResponse(ExecutionService.java:159)
	at io.smallrye.graphql.execution.ExecutionService.execute(ExecutionService.java:130)
	at io.smallrye.graphql.servlet.SmallRyeGraphQLExecutionServlet.handleInput(SmallRyeGraphQLExecutionServlet.java:108)
	at io.smallrye.graphql.servlet.SmallRyeGraphQLExecutionServlet.doPost(SmallRyeGraphQLExecutionServlet.java:81)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:706)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
	at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1230)
	at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:729)
	at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:426)
	at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1226)
	at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:5021)
	at com.ibm.ws.webcontainer.osgi.DynamicVirtualHost$2.handleRequest(DynamicVirtualHost.java:314)
	at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:1007)
	at com.ibm.ws.webcontainer.osgi.DynamicVirtualHost$2.run(DynamicVirtualHost.java:279)
	at com.ibm.ws.http.dispatcher.internal.channel.HttpDispatcherLink$TaskWrapper.run(HttpDispatcherLink.java:1134)
	at com.ibm.ws.http.dispatcher.internal.channel.HttpDispatcherLink.wrapHandlerAndExecute(HttpDispatcherLink.java:415)
	at com.ibm.ws.http.dispatcher.internal.channel.HttpDispatcherLink.ready(HttpDispatcherLink.java:374)
	at com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:551)
	at com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.handleNewRequest(HttpInboundLink.java:484)
	at com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.processRequest(HttpInboundLink.java:346)
	at com.ibm.ws.http.channel.internal.inbound.HttpICLReadCallback.complete(HttpICLReadCallback.java:70)
	at com.ibm.ws.tcpchannel.internal.WorkQueueManager.requestComplete(WorkQueueManager.java:504)
	at com.ibm.ws.tcpchannel.internal.WorkQueueManager.attemptIO(WorkQueueManager.java:574)
	at com.ibm.ws.tcpchannel.internal.WorkQueueManager.workerRun(WorkQueueManager.java:958)
	at com.ibm.ws.tcpchannel.internal.WorkQueueManager$Worker.run(WorkQueueManager.java:1047)
	at com.ibm.ws.threading.internal.ExecutorServiceImpl$RunnableWrapper.run(ExecutorServiceImpl.java:239)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:825)

Here is the related code:

    private Optional<JsonObject> getOptionalExtensions(GraphQLError error) {
        if (error.getErrorType().equals(ErrorType.ValidationError)) {
            return getValidationExtensions(error);
        } else if (error.getErrorType().equals(ErrorType.DataFetchingException)) {
            return getDataFetchingExtensions(error);
        }
        return Optional.empty();
    }

    private Optional<JsonObject> getValidationExtensions(GraphQLError graphQLError) {
        ValidationError error = (ValidationError) graphQLError;
        JsonObjectBuilder objectBuilder = Json.createObjectBuilder();

        addKeyValue(objectBuilder, DESCRIPTION, error.getDescription());
        addKeyValue(objectBuilder, VALIDATION_ERROR_TYPE, error.getValidationErrorType().toString());
        objectBuilder.add(QUERYPATH, toJsonArray(error.getQueryPath()));
        addKeyValue(objectBuilder, CLASSIFICATION, error.getErrorType().toString());

        return Optional.of(objectBuilder.build());
    }

So it seems like even though the error type is equal to ValidationError, it is not necessarily an instance of ValidationError. I think that this can be fixed by using instanceof checks instead of checking the errorType. I'll code up my proposed solution shortly.

Generated Schema for SuperHero idNumber is incorrect

According to the graphql-mp spec 1.0.1 -

On SuperHero we see.

@JsonbNumberFormat("ID-########")
private Long idNumber;
``

The generated graphql schema is 

"0000,0000"
idNumber: BigInteger


Shouldn't this be

"ID-########""
idNumber: String

Variables failing when used for objects

I have a mutation that has an argument that is an Input type - schema looks like this:

"Mutation root"
type Mutation {
  "Create a new widget for sale."
  createWidget(widget: WidgetInput): Widget
  quantityOnAllWidgets(newQuantity: Int!): [Widget]
}

"Query root"
type Query {
  allWidgets: [Widget]
}

"A for-sale item."
type Widget {
  name: String
  quantity: Int!
  weight: Float!
}

"A for-sale item."
input WidgetInput {
  name: String
  quantity: Int!
  weight: Float!
}

My client (curl) uses variables to invoke the createWidget mutation:

curl http://localhost:9080/basicMutationApp/graphql -d '{"query":"mutation createWidget ($widget: WidgetInput) { createWidget(widget: $widget) {name, weight}}","variables":{"widget":{"name":"Earbuds","quantity":20,"weight":1.2}},"operationName":"createWidget"}'

That fails with this message:

"Variable 'widget' has an invalid value : Expected type 'Map' but was 'String'. Variables for input objects must be an instance of type 'Map'."

I believe that this happens because the ExecutionService is converting Objects to Strings when creating the map to pass to the executionBuilder. In the toObject method, this code just returns the JsonValue's string:

case OBJECT:
    ret = jsonValue.toString();
    break;

The problem with fixing this is that it is not easy to tell at this point what type of object it is - so it is hard to deserialize it here... The rest of the query tells us that it is supposed be of type, WidgetInput, but that isn't available at this point. Even with that, we'd need a way to map "WidgetInput" back to the actual type (i.e. com.mypkg.Widget) and then deserialize it.

I'll plan to investigate this, but could probably use some help on this one.

Hibernate JPA fetch type LAZY

How can I properly use JPA relationships?

I'm running Thorntail 2.6.0.Final with smallrye-graphql-servlet 1.0.0

I Have the following classes bellow:

@Entity
@Table(name = "person")
public class Person extends AbstractEntity {

    @Getter @Setter
    private String name;

    @Getter @Setter
    @Column(name = "last_name")
    private String lastName;

    @Getter
    @OneToMany(mappedBy = "person", fetch = FetchType.LAZY)
    private Set<Book> books = new HashSet<>();

}
@XmlAccessorType(XmlAccessType.FIELD)
@Entity
@Table(name = "book")
public class Book extends AbstractEntity {

    @Getter
    @Setter
    private String name;

    @Getter @Setter
    @JsonbTransient
    @ManyToOne
    @JoinColumn(name = "fk_person")
    private Person person;

}

I request the following query:

{
  person(id: 1) {
    name
    books {
      name
    }
  }
}

I get the following error from lazy initialization with no session

{
  "errors": [
    {
      "message": "Server Error",
      "locations": [
        {
          "line": 4,
          "column": 5
        }
      ],
      "path": [
        "person",
        "books"
      ],
      "extensions": {
        "exception": "org.hibernate.LazyInitializationException",
        "classification": "DataFetchingException"
      }
    }
  ],
  "data": {
    "person": {
      "name": "Bruno",
      "books": null
    }
  }
}

And the following stakctrace:

2020-03-10 17:16:06,091 ERROR [io.smallrye.graphql.execution.error.ExceptionHandler] (default task-1) Data Fetching Error: org.hibernate.LazyInitializationException: failed to lazily initialize a collection of role: io.bpic.poc.graphql.demo.entity.Person.books, could not initialize proxy - no Session
	at org.hibernate.collection.internal.AbstractPersistentCollection.throwLazyInitializationException(AbstractPersistentCollection.java:602)
	at org.hibernate.collection.internal.AbstractPersistentCollection.withTemporarySessionIfNeeded(AbstractPersistentCollection.java:217)
	at org.hibernate.collection.internal.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:581)
	at org.hibernate.collection.internal.AbstractPersistentCollection.read(AbstractPersistentCollection.java:148)
	at org.hibernate.collection.internal.PersistentSet.iterator(PersistentSet.java:188)
	at io.smallrye.graphql.execution.datafetcher.AnnotatedPropertyDataFetcher.get(AnnotatedPropertyDataFetcher.java:74)
	at io.smallrye.graphql.execution.datafetcher.AnnotatedPropertyDataFetcher.get(AnnotatedPropertyDataFetcher.java:59)
	at graphql.execution.ExecutionStrategy.fetchField(ExecutionStrategy.java:272)
	at graphql.execution.ExecutionStrategy.resolveFieldWithInfo(ExecutionStrategy.java:200)
	at graphql.execution.AsyncExecutionStrategy.execute(AsyncExecutionStrategy.java:74)
	at graphql.execution.ExecutionStrategy.completeValueForObject(ExecutionStrategy.java:656)
	at graphql.execution.ExecutionStrategy.completeValue(ExecutionStrategy.java:440)
	at graphql.execution.ExecutionStrategy.completeField(ExecutionStrategy.java:390)
	at graphql.execution.ExecutionStrategy.lambda$resolveFieldWithInfo$0(ExecutionStrategy.java:202)
	at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
	at java.util.concurrent.CompletableFuture.uniApplyStage(CompletableFuture.java:614)
	at java.util.concurrent.CompletableFuture.thenApply(CompletableFuture.java:1983)
	at graphql.execution.ExecutionStrategy.resolveFieldWithInfo(ExecutionStrategy.java:201)
	at graphql.execution.AsyncExecutionStrategy.execute(AsyncExecutionStrategy.java:74)
	at graphql.execution.Execution.executeOperation(Execution.java:165)
	at graphql.execution.Execution.execute(Execution.java:106)
	at graphql.GraphQL.execute(GraphQL.java:623)
	at graphql.GraphQL.parseValidateAndExecute(GraphQL.java:556)
	at graphql.GraphQL.executeAsync(GraphQL.java:520)
	at graphql.GraphQL.execute(GraphQL.java:450)
	at io.smallrye.graphql.execution.ExecutionService.execute(ExecutionService.java:84)
	at io.smallrye.graphql.execution.ExecutionService$Proxy$_$$_WeldClientProxy.execute(Unknown Source)
	at io.smallrye.graphql.servlet.SmallRyeGraphQLExecutionServlet.doPost(SmallRyeGraphQLExecutionServlet.java:53)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:523)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:590)
	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
	at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at org.wildfly.swarm.generated.FaviconErrorHandler.handleRequest(FaviconErrorHandler.java:61)
	at io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:91)
	at io.undertow.servlet.handlers.RedirectDirHandler.handleRequest(RedirectDirHandler.java:68)
	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:269)
	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
	at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504)
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99)
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:376)
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
	at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
	at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
	at java.lang.Thread.run(Thread.java:748)

Thanks,
Bruno

CI/CD

Create the pipeline to build and release this.

Mutation-only server not supported

When creating a server with only mutations, the following error appear:

{"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"server.war\".undertow-deployment" => "java.lang.RuntimeException: graphql.AssertException: queryType can't be null
    Caused by: java.lang.RuntimeException: graphql.AssertException: queryType can't be null
    Caused by: graphql.AssertException: queryType can't be null"}}

Example of Java code to reproduce:

@GraphQLApi
public class TckGraphQLApi {

    @Mutation
    public String myMutation() {
        return "mutation";
    }
}

Improve error mapping (client)

Currently, when there is an error response, a GraphQlClientException is thrown with the error list in the message... as a String.

  • 1. Make the full error structure available to an exception handler.
  • 2. Allow for a field in the expected result to contain error results (e.g. for partial results).
  • 3. Introduce an error mapper that can throw specific exceptions derived from the errors received.

Documentation

Do documentation and add graphql to the project page in smallrye.io

Error when app contains only queries - no mutations

I have a simple "echo" app that contains a single query. When I run this app in OpenLiberty using graphiql HTML client, I see this error message before I run any queries:

Error: Mutation fields must be an object with field names as keys or a function which returns such an object.
    at invariant (https://cdn.jsdelivr.net/npm/[email protected]/graphiql.js:24809:11)
    at defineFieldMap (https://cdn.jsdelivr.net/npm/[email protected]/graphiql.js:28078:27)
    at GraphQLObjectType.getFields (https://cdn.jsdelivr.net/npm/[email protected]/graphiql.js:28035:44)
    at typeMapReducer (https://cdn.jsdelivr.net/npm/[email protected]/graphiql.js:29752:25)
    at Array.reduce (<anonymous>)
    at new GraphQLSchema (https://cdn.jsdelivr.net/npm/[email protected]/graphiql.js:29641:34)
    at buildClientSchema (https://cdn.jsdelivr.net/npm/[email protected]/graphiql.js:31049:10)
    at https://cdn.jsdelivr.net/npm/[email protected]/graphiql.js:2131:55

I think the implementation must be creating a Mutation type even if there are no @Mutation-annotated methods. I am planning to investigate.

Extract metric naming strategy into a manageable piece

At the moment we "duplicate" the metric naming strategy (logic that transforms an operation/field into its respective metric name)

  • in the Bootstrap class where it is used for eager registration of metrics during bootstrap
  • in the MetricDecorator class where it is used to access and update metrics

It perhaps should be factored out into one place so it will be more manageable. Integration code that binds SmallRye GraphQL into runtimes could make use of it too, if it wants to access the metrics for some reason, it should not be forced to "guess" how to compute the metric names, but should have a reliable API to compute them.

@Source on a collection response.

When the response is a collection that contains a pojo that is linked to another method with a @Source the field should be populated.

MP Metrics Support

It would be nice to track statistics for GraphQL Query/Mutation invocations using MP Metrics.

Indexer doesn't work in JDK11 or with Wildfly

I tried to integrate this lib into my Wildfly JakartaEE project, but the indexer couldn't find my annotated @GraphQLApi classes.

The (open)JDK11 case is reproducible with the example project (https://github.com/phillip-kruger/graphql-example) too.

In Wildfly I've debugged the classpath resolution logic, and found, that only the jboss-modules.jar is processed by the indexer.

The only successful execution was with JDK8 and Thorntail.

Not thread safe when multiple apps are running in same JVM

The reference queues in the ReferenceCreator code are all static. When running in Open Liberty with multiple apps, they end up clobbering each other - for example, input types from app1 end up getting put into app2's schema (I think), and then app1 ends up with an NPE because it app2 polled it's Reference from the queue.

I think the queues in the ReferenceCreator ought to be instance variables rather than static, and then the referring classes (like SchemaBuilder) must have an instance reference to the ReferenceCreator.

Maven plugin

Request from Twitter: create a maven and gradle plugin that can generate and safe the graphql-schema on build.

Default value json

The default value of an object that marshals to json in the schema does not work. There is now a test in the TCK to test for this (1.1-SNAPSHOT)

We need to fix this for SmallRye

Create a UI module

Add a workabke UI module (from webjars) that can be included in runtimes that wants to include a UI

Add support for Bean Validation

It would be very convenient, if mutators would check input objects using jakarta.validation:jakarta.validation-api. To a lesser extent, the same would be helpful for parameters used in queries.

To be more consistent with JAX-RS, the validation could only be executed, if the bean/parameter is annotated as @Valid.

This had been suggested for MP GraphQL #210, but as long as MP doesn't endorse BV, it won't be added to MP GraphQL and it's up to implementations to add support.

Array of primitive scalar type not supported

Version of smallrye-graphql-servlet: 1.0.1

I noticed that only the "Object version" of scalar types are working when using arrays: Integer[], Float[], Double[]... .
If you try to use the "Primitive version" (int[], float[], boolean[]) you get an error.

Only exception is char[] that works (also Character[] is working).

Java Code to reproduce:

public class IntArrayHolder {
    private int[] intPrimitiveArray;
    private Integer[] intObjectArray;

    public IntArrayHolder() {
    }

    public int[] getIntPrimitiveArray() {
        return intPrimitiveArray;
    }

    public void setIntPrimitiveArray(int[] intPrimitiveArray) {
        this.intPrimitiveArray = intPrimitiveArray;
    }

    public Integer[] getIntObjectArray() {
        return intObjectArray;
    }

    public void setIntObjectArray(Integer[] intObjectArray) {
        this.intObjectArray = intObjectArray;
    }
} 

And for the API part:

    @Query
    public IntArrayHolder intArrayHolder(IntArrayHolder intArrayHolder) {
        return intArrayHolder;
    }

GraphQL request:

query {
  intArrayHolder(intArrayHolder:{
    intObjectArray:[123, 456, 789],
    intPrimitiveArray: [123, 456, 789]
  }) {
    intObjectArray
    intPrimitiveArray
  }
}

GraphQL output:

{
  "errors": [
    {
      "message": "Server Error",
      "locations": [
        {
          "line": 3,
          "column": 3
        }
      ],
      "path": [
        "intArrayHolder"
      ],
      "extensions": {
        "exception": "java.lang.ClassCastException",
        "classification": "DataFetchingException"
      }
    }
  ],
  "data": {
    "intArrayHolder": null
  }
}

Java stacktrace:

16:40:01,292 ERROR [io.smallrye.graphql.execution.error.ExceptionHandler] (default task-1) Data Fetching Error: java.lang.ClassCastException: class [I cannot be cast to class [Ljava.lang.Object; ([I and [Ljava.lang.Object; are in module java.base of loader 'bootstrap')
	at deployment.server.war//io.smallrye.graphql.execution.datafetcher.helper.AbstractHelper.recursiveTransformArray(AbstractHelper.java:110)
	at deployment.server.war//io.smallrye.graphql.execution.datafetcher.helper.AbstractHelper.recursiveTransform(AbstractHelper.java:65)
	at deployment.server.war//io.smallrye.graphql.execution.datafetcher.helper.ArgumentHelper.correctComplexObjectFromMap(ArgumentHelper.java:200)
	at deployment.server.war//io.smallrye.graphql.execution.datafetcher.helper.ArgumentHelper.correctObjectClass(ArgumentHelper.java:162)
	at deployment.server.war//io.smallrye.graphql.execution.datafetcher.helper.ArgumentHelper.afterRecursiveTransform(ArgumentHelper.java:144)
	at deployment.server.war//io.smallrye.graphql.execution.datafetcher.helper.AbstractHelper.recursiveTransform(AbstractHelper.java:78)
	at deployment.server.war//io.smallrye.graphql.execution.datafetcher.helper.ArgumentHelper.getArgument(ArgumentHelper.java:101)
	at deployment.server.war//io.smallrye.graphql.execution.datafetcher.helper.ArgumentHelper.getArguments(ArgumentHelper.java:64)
	at deployment.server.war//io.smallrye.graphql.execution.datafetcher.ReflectionDataFetcher.get(ReflectionDataFetcher.java:86)
	at deployment.server.war//graphql.execution.ExecutionStrategy.fetchField(ExecutionStrategy.java:272)
	at deployment.server.war//graphql.execution.ExecutionStrategy.resolveFieldWithInfo(ExecutionStrategy.java:200)
	at deployment.server.war//graphql.execution.AsyncExecutionStrategy.execute(AsyncExecutionStrategy.java:74)
[ ... ]

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.