Tim On Computer Science

You are here because you are following the “Building a GraphQL service“, and specifically the testing section using GraphQlTest, and you keep getting a runtime error:

java.lang.IllegalStateException: Failed to load ApplicationContext for [MergedContextConfiguration@5b202ff testClass = com.tiemens.fullstack.controller.BookControllerTests, locations = [], classes = [com.tiemens.fullstack.FullstackApplication], contextInitializerClasses = [], activeProfiles = [], propertySourceDescriptors = [], propertySourceProperties = ["org.springframework.boot.test.autoconfigure.graphql.GraphQlTestContextBootstrapper=true"]

Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'graphQlSource' defined in class path resource [org/springframework/boot/autoconfigure/graphql/GraphQlAutoConfiguration.class]: Failed to instantiate [org.springframework.graphql.execution.GraphQlSource]: Factory method 'graphQlSource' threw exception with message: Name for argument of type [java.lang.String] not specified, and parameter name information not found in class file either.

Caused by: org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.springframework.graphql.execution.GraphQlSource]: Factory method 'graphQlSource' threw exception with message: Name for argument of type [java.lang.String] not specified, and parameter name information not found in class file either.

Caused by: java.lang.IllegalArgumentException: Name for argument of type [java.lang.String] not specified, and parameter name information not found in class file either.

The fix is in BookController, bookById: simply change “@Argument String id” to be “@Argument(“id”) String id”, as shown below:

@Controller
public class BookController {
    @QueryMapping
    public Book bookById(@Argument("id") String id) {
        return Book.getById(id);
    }
    ...etc...
}

Magically injected error that is magically fixed.

Note: this was caused by Spring Boot v3,4,1 (or 3.4, or 3.2 or something in the “3”s)

Argo CD (github source) is a Continuous Delivery tool done “GitOps” style. Here, that means keeping all of your (Kubernetes) application definitions and configurations under source code control (git).

Assuming you follow GitOps CI/CD best practices of separate repositories (one for application code and a second for your YAML configurations), your development process is likewise split into two discrete problems:

1. Application Code – build the container images (CI)
2. Configuration Code – keep your (Kubernetes) configuration files synchronized with the repository (CD)

Argo CD solves the second bullet. And does it pretty well. It supports writing your configuration code in any of: plain YAML, Helm charts. Kustomize, and Jsonnet.

It also supports enforcing that all Kubernetes changes “from the command line” are at least detected (and if desired, automatically rolled back). E.g. if some rogue administrator issues a “kubectl scale –replicas=3 …” command, Argo CD will at least change the status to “Out of Sync”, and is capable of automatically re-synchronizing, and therefore un-doing the change.

Reference: compare Argo CD versus Tekton versus Jenkins X

Question: do you need separate repositories or just separate directories? i.e. Argo CD takes a repository and a path to configure an “application” – does it ignore commits to files outside of the directory? Answer: yes, it ignores them, so no, you don’t technically need separate repositories. Which means all of the Monorepo fans out there are in luck.