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

Web API: update graphql-java 13.0 dependency to newest stable one #2181

Open
2 of 4 tasks
jhou-pro opened this issue Feb 9, 2024 · 0 comments
Open
2 of 4 tasks

Web API: update graphql-java 13.0 dependency to newest stable one #2181

jhou-pro opened this issue Feb 9, 2024 · 0 comments

Comments

@jhou-pro
Copy link
Contributor

jhou-pro commented Feb 9, 2024

Description

Our current graphql-java dependency has vulnerabilities. Also GraphQL specification has been evolved. We need to update our Web API implementation to conform to most recent specification and non-vulnerable internals.

  • Specification does not support Long / BigDecimal scalars -- define custom ones to support TG types (e.g. as for Money / Date)
  • ValuesResolver made more private and API changed -- sync with these changes
  • Fetching of entity-typed subproperty of collectional property don't work on most recent stable 21.3 graphql-java
  • to be continued...

Expected outcome

Up-to-date TG Web API GraphQL-based implementation with no vulnerabilities.

@jhou-pro jhou-pro self-assigned this Feb 9, 2024
jhou-pro added a commit that referenced this issue Feb 12, 2024
jhou-pro added a commit that referenced this issue Feb 13, 2024
jhou-pro added a commit that referenced this issue Apr 13, 2024
… as in graphql-java. This is to be able to change it as per additional requirements.
jhou-pro added a commit that referenced this issue Apr 17, 2024
At this stage we prefer pojo-like 'is/get' property accessors (aka getters) in TG. The same principle should be used for Web API field value resolving from internally fetched entities. These tests are needed to formalise this. In fact, current version of graphql-java's PropertyDataFetcher prefers record-like accessors pojo-like 'is/get' accessors and thus some of these tests fail.

Two @ignore tests and two stubs were added for potential future cases: 1. if we move from 'is/get' pojo-like getters to record-like, potentially autocompiled, accessors 2. if we support record-typed properties in TG and its Web API.
jhou-pro added a commit that referenced this issue Apr 17, 2024
…erifier.

This is to be more consistent with widely used Reflector.obtainPropertyAccessor. This will only affect boolean props that may have both 'get' and 'is' accessors (there are no constraints in this regard).
jhou-pro added a commit that referenced this issue Apr 17, 2024
… only).

This is to be more consistent with widely used Reflector.obtainPropertyAccessor. This will only affect boolean props that may have both 'get' and 'is' accessors (there are no constraints in this regard).
jhou-pro added a commit that referenced this issue Apr 17, 2024
This is to be more consistent with widely used Reflector.obtainPropertyAccessor. This will only affect boolean props that may have both 'get' and 'is' accessors (there are no constraints in this regard).
jhou-pro added a commit that referenced this issue Apr 17, 2024
…ike ones (TG way).

This change is covered by WebApiPropertyDataFetcherTest. Also previously failing WebApiCollectionalFieldTest are now passing. There User.roles() record-like accessor returned totally different data than User.getRoles() accessor.
jhou-pro added a commit that referenced this issue Apr 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants