Endpoints

[hide]

JmsEndpointBuilder checks

The documentation of JmsEndpointBuilder points out a few criteria that need to be met in order for it to be configured properly:

12.3.1 JMS topic subscriber:
The auto-start option is only valid in combination with pub-sub-domain enabled. Other combinations may be ignored or lead to configuration failure at start-up.

12.4 JMS topic durable subscription:
The auto-start setting is required to be enabled for this reason when using durable subscriptions.

Not mentioned in the docs, but according to the Citrus implementation, the durable subscriber name is used only when durable subscription is enabled.

KafkaEndpointBuilder checks

The documentation and underlying Citrus implementation of KafkaEndpointBuilder points out a few criteria that needs to be met, in order for it to be configured properly:

The offset reset value must be one of earliest, latest and none:

The partition value must be non-negative:

Code completion of Endpoint and other Spring beans

To make the discovery of various Endpoint and types of beans easier in test code, methods in Citrus that accept endpoint URI strings or other Spring bean names/ids, are extended with code completion of beans of their respective types (and its subtypes).

Java DSL

Code completion is currently supported at the following locations:

Code completed bean type	Locations	Java DSL	Groovy DSL
`Endpoint`	`SendMessageAction.Builder.send()`	+	+
	`ReceiveMessageAction.Builder.receive()`	+	+
	`MessageActionBuilder.endpoint()` – used in send and receive actions	+	+
	`ReceiveTimeoutAction.Builder`: `expectTimeout()`, `receiveTimeout()`	+	+
	`CamelEndpointBuilder.endpointUri()`	+	+
	`PurgeEndpointAction.Builder.endpoint()`	+	+
	`MessageBuilderSupport.endpoint()`	+	+
`HttpClient`	`HttpActionBuilder.client()`	+	+
	`OpenApiClientActionBuilder.client()`	+	+
`HttpServer`	`HttpActionBuilder.server()`	+	+
	`OpenApiClientActionBuilder.server()`	+	+
`Server`	`StopServerAction.Builder.server()`	+	+
	`StartServerAction.Builder.server()`	+	+
`WebServiceClient`	`SoapActionBuilder.client()`	+	+
	`AssertSoapFault.Builder.endpoint()`	+	+
`WebServiceServer`	`SoapActionBuilder.client()`	+	+
`SoapFaultValidator`	`AssertSoapFault.Builder.validator()`	+	+
`SoapAttachmentValidator`	`ReceiveSoapMessageAction.SoapMessageBuilderSupport.attachmentValidatorName()`	+	+
`org.apache.camel.CamelContext`	`@CamelEndpointConfig#camelContext`	+
	`@CamelSyncEndpointConfig#camelContext`	+
`MessageConverter`	`@CamelEndpointConfig#messageConverter`	+
	`@CamelSyncEndpointConfig#messageConverter`	+
`MessageValidator`	`ReceiveMessageAction.Builder.validator()`	+	+
	`ReceiveMessageAction.Builder.validators()`	+	+
`HeaderValidator`	`HeaderValidationContext.addHeaderValidator()`	+	+
`DataDictionary`	`MessageBuilderSupport.dictionary()`	+	+
`SimpleJsonSchema / XsdSchema`	`XmlValidationContextBuilder.schema()`	+	+
`JsonSchemaRepository / XsdSchemaRepository`	`XmlValidationContextBuilder.schemaRepository()`	+	+
`org.apache.tools.ant.BuildListener`	`AntRunAction.Builder.listenerName()`	+	+

The type text on the right hand side of each completion item shows the Spring configuration class the bean is defined in.
Also, while the completion list is displayed, one can also navigate to the bean definition via Ctrl+B and similar shortcuts.

YAML DSL

For the YAML DSL, the logic is the same as in case of the Java DSL. However, there are too many properties supported to list them all here.

XML and Spring XML DSLs

For the XML DSLs, the logic is almost the same as in case of the Java DSL, but in case of Spring bean completion in the Spring XML DSL, only those beans are completed that are defined in the same Citrus test file they are used in. Beans created in context configurations are not taken into account at the moment.

Code completed bean type	Locations	XML DSL	Spring XML DSL
`SimpleJsonSchema`	`message@schema`	+
	`message@schema`		+
	`http:[GET,POST,...].http:body@schema`		+
`JsonSchemaRepository`	`message@schema-respository`	+
	`message@schema-repository`		+
	`http:[GET,POST,...].http:body@schema-repository`		+
`XsdSchema`	`message@schema`	+
	`message@schema`		+
	`http:[GET,POST,...].http:body@schema`		+
	`ws:fault-detail@schema`		+
`XsdSchemaRepository`	`message@schema-respository`	+
	`message@schema-repository`		+
	`http:[GET,POST,...].http:body@schema-repository`		+
	`ws:fault-detail@schema-repository`		+
`Endpoint`	`send@endpoint`	+	+
	`receive@endpoint`	+	+
	`expect-timeout@endpoint`	+	+
	`purge-endpoint@endpoint`	+
	`camel:endpoint@endpoint-uri`	+
	`purge-endpoint.endpoint@name`		+
`DataDictionary`	`message@data-dictionary`	+	+
`Server`	`stop@server`	+	+
	`start@server`	+	+
`HttpClient`	`send-request@client`	+	+
	`receive-response@client`	+	+
	`http:send-request@client`	+	+
	`http:receive-response@client`	+	+
	`http@client`	+
	`openapi@client`	+
`HttpServer`	`send-response@server`	+	+
	`receive-request@server`	+	+
	`http:send-response@server`	+	+
	`http:receive-request@server`	+	+
	`http@server`	+
	`openapi@server`	+
`HeaderValidator`	`receive@header-validator`	+	+
	`receive-request@header-validator`	+	+
	`receive-response@header-validator`	+	+
`WebServiceClient`	`soap@client`	+
	`ws:send@endpoint`	+	+
`WebServiceServer`	`soap@server`	+
`SoapFaultValidator`	`soap.assert-fault@validator`	+
	`ws:assert-fault@fault-validator`	+	+
`SoapAttachmentValidator`	`soap.receive-request@attachment-validator`	+
	`soap.receive-response@attachment-validator`	+
	`ws:receive.ws:attachment@validator`	+	+
`org.apache.camel.CamelContext`	`camel@camel-context`	+
`org.apache.tools.ant.BuildListener`	`ant@build-listener`		+

Code completion of Kafka offset reset strategies

This code completion provides Kafka offset reset strategies:

Java and Groovy DSLs: in KafkaEndpointBuilder.offsetReset() calls.
Spring XML DSL: in the {http://www.citrusframework.org/schema/kafka/config}endpoint@offset-reset attribute.

The item earliest is also extended with the text default value since that is the default offset reset value in Citrus.

Endpoint config annotation checks

The Citrus Framework provides many @*EndpointConfig, @*ClientConfig and @*ServerConfig annotations for their respective endpoint types, so that in case field injections, the injected endpoints’ properties can be overridden by these annotations.

A handful of these annotations specify some rules on how their attributes must be configured. This inspection implements and reports those rules for: