Support ZEEBE_GATEWAY_ADDRESS as new env var to connect with a Zeebe cluster

[Zelldon]

Description

Right now we support ZEEBE_ADDRESS which is one of the oldest env var we support, and historically grown. In order to align our terminology and applications across the stack we should support ZEEBE_GATEWAY_ADDRESS and deprecate ZEEBE_ADDRESS.

See related docs PR camunda/camunda-docs#2518
See related google doc https://docs.google.com/document/d/10wZ6eMszqJHEsVbprdjaC1A-vcqoxANwaMpnwGkjE8I/edit. Especially this part
See related github issue: camunda/camunda-docs#1662

[npepinpe]

I assume for backwards compatibility purposes we need to keep supporting ZEEBE_ADDRESS? Maybe print a warning that it's deprecated when used.

[Zelldon]

Yeah for one or two versions I guess.

[korthout]

As the java client is part of our public API we can't remove it the old one. But I like the idea of adding a new one to align these.

[dipeshsingh253]

Hello @Zelldon , I would like to work on this issue. But I am a little confused (sorry this might be a very noob doubt). I went through: https://docs.camunda.io/docs/next/apis-tools/java-client/

and in the source code: https://github.com/camunda/zeebe/blob/main/clients/java/src/main/java/io/camunda/zeebe/client/impl/ZeebeClientBuilderImpl.java#L281

So as we can see the source code is accepting a string as a gateway address and in the docs we are using this code block :

ZeebeClient client =
    ZeebeClient.newClientBuilder()
        .gatewayAddress(System.getenv("ZEEBE_ADDRESS"))
        .build();

so I don't see anything related to env var in the source code at all. for example, if I create an env var MY_GATEWAY_ADDR = "gateway address". and pass it in the above code block it will work fine, right ? Or there is any validation for that?

Once again, I am very new to open source, sorry if this sounds foolish but that was my doubt.

Thanks in advance !!!

[npepinpe]

FYI, this is superseded by using ZEEBE_REST_ADDRESS and ZEEBE_GRPC_ADDRESS from now on. I propose we close this, as only the Go client remains, and I don't see us working on this any time soon. If, however, anyone wants to open an issue/PR for the Go client, go ahead.