By default, CXF performs validation against the WSDL schema. While this is generally a good practice, it can become problematic in dynamic environments where the API contract might not always be perfectly aligned with the deployed WSDL.

This blog post demonstrates how to disable incoming message validation in your Quarkus CXF client to handle such scenarios gracefully.

The Problem: Strict WSDL Validation

Imagine your Quarkus application consumes a SOAP service defined by a WSDL. If the service provider adds a new, optional field to their response that isn’t described in the current WSDL your client has, CXF’s default validation will likely throw an exception, preventing you from processing the response.

While ideally, you would update your client’s WSDL and generated code whenever the service changes, this might not always be feasible or immediately possible. In such cases, temporarily disabling validation can provide a workaround.

The Solution: A Custom Interceptor

We can create a custom CXF interceptor to disable the JAXB validation event handler, which is responsible for enforcing the schema compliance. Here’s the Java code for the interceptor:

import org.apache.cxf.message.Message;
import org.apache.cxf.phase.AbstractPhaseInterceptor;
import org.apache.cxf.phase.Phase;
import org.apache.cxf.interceptor.Fault;

public class DisableMessageValidationInterceptor extends AbstractPhaseInterceptor<Message>
{
    public DisableMessageValidationInterceptor()
    {
        super(Phase.PRE_PROTOCOL);
    }

    public void handleMessage(Message message) throws Fault
    {
        message.put("set-jaxb-validation-event-handler", "false");
    }
}

Explanation:

We create a class DisableMessageValidationInterceptor that extends AbstractPhaseInterceptor. The constructor calls the superclass constructor with Phase.PRE_PROTOCOL. This ensures that our interceptor runs early in the interceptor chain, before the protocol-specific processing. The handleMessage method is where the core logic resides. We use message.put("set-jaxb-validation-event-handler", "false"); to instruct CXF to disable the JAXB validation event handler for the current message. This effectively tells the JAXB unmarshaller to ignore validation errors.

Integrating the Interceptor in Quarkus

To use this interceptor with your Quarkus CXF client, you need to register it in your application.properties file. Assuming your CXF client is named “my-soap-client”, you would add the following line:

quarkus.cxf.client."my-soap-client".in-interceptors=com.example.DisableMessageValidationInterceptor

Conclusion

By implementing and registering this custom interceptor, you can effectively disable incoming message validation for your Quarkus CXF client. This can be a useful strategy when dealing with SOAP APIs that might evolve without strict adherence to the published WSDL.

However, it’s crucial to understand the implications of disabling validation:

• You lose the guarantee that incoming messages strictly conform to the WSDL.
• Your application might need to be more resilient and handle unexpected data or missing fields.
• Disabling validation should be considered a temporary workaround. Ideally, you should strive to keep your client’s WSDL and generated code up-to-date with the service definition.

Use this technique judiciously and ensure your application is prepared to handle potentially non-compliant messages.

variable "email_addresses" {
  type = list(object({
    name          = string
    email_address = string
  }))
  default = []
}

resource "azurerm_monitor_action_group" "monitoring_action_group" {
  name                = "Application Monitoring"
  resource_group_name = azurerm_resource_group.resource_group.name
  short_name          = "EmailAlert"

  dynamic "email_receiver" {
    for_each = var.email_addresses
    content {
      name          = email_receiver.value["name"]
      email_address = email_receiver.value["email_address"]
    }
  }
}

Azure Pipelines allow parameters of type object, and therefore, complex types. To transform this into a usable JSON data structure, I am using an additional script step, in which the parameter is converted to JSON and written to a JSON file. The generated JSON file with the list of email receivers can then be used as a command option within the TerraformTaskV4@4.

parameters:
  - name: alertEmails
    type: object
    default: []

steps:
  - script: |
      echo "{\"email_addresses\": $ALERT_EMAILS_JSON}" > $(terraform_working_dir)/terraform.tfvars.json
    env:
      ALERT_EMAILS_JSON: $\
    displayName: Generate terraform.tfvars.json from parameters
  ...
  - task: TerraformTaskV4@4
    name: terraformPlan
    displayName: Create Terraform Plan
    inputs:
      provider: azurerm
      command: plan
      commandOptions: >-
        -var environment=dev
        -var-file="terraform.tfvars.json"
      workingDirectory: $(terraform_working_dir)

With this workaround, we can easily define a list of email receivers in our pipeline script.

      - template: terraform.yml
        parameters:
          alertEmails:
            - name: "Foo Bar"
              email_address: "foobar@development.de"
            - name: "John Due"
              email_address: "mail@john.com"

That’s why I transitioned to Azure ARM templates for deploying an Event Hub with both log compaction and authorization rules.

resource "azurerm_resource_group" "resource_group" {
  name     = var.application_name
  location = var.location
}

resource "azurerm_resource_group_template_deployment" "eventhub" {
  name                = "eventhub-template"
  resource_group_name = azurerm_resource_group.resource_group.name
  deployment_mode     = "Incremental"
  template_content    = <<TEMPLATE
{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.EventHub/namespaces",
      "apiVersion": "2023-01-01-preview",
      "name": "${var.application_name}",
      "location": "${azurerm_resource_group.resource_group.location}",
      "sku": {
          "name": "Premium",
          "tier": "Premium"
      },
      "properties": {
        "zoneRedundant": true
      },
      "resources": [
        {
          "apiVersion": "2023-01-01-preview",
          "name": "${var.eventhub_name}",
          "type": "eventhubs",
          "dependsOn": [
              "Microsoft.EventHub/namespaces/${var.application_name}"
          ],
          "properties": {
            "partitionCount": "1",
            "retentionDescription": {
              "cleanupPolicy": "Compact",
              "tombstoneRetentionTimeInHours": 96
            }
          },
          "resources": [
            {
              "type": "authorizationRules",
              "apiVersion": "2023-01-01-preview",
              "name": "default",
              "dependsOn": [
                "[resourceId('Microsoft.EventHub/namespaces/eventhubs/', '${var.application_name}', '${var.eventhub_name}')]"
              ],
              "properties": {
                "rights": ["Send", "Listen"]
              }
            }
          ]
        }
      ]
    }
  ],
  "outputs": {
    "RootManageSharedAccessKeyConnectionString": {
      "type": "string",
      "value": "[listkeys(resourceId('Microsoft.EventHub/namespaces/AuthorizationRules', '${var.application_name}', 'RootManageSharedAccessKey'), '2017-04-01').primaryConnectionString]"
    },
    "defaultConnectionString": {
      "type": "string",
      "value": "[listkeys(resourceId('Microsoft.EventHub/namespaces/eventhubs/AuthorizationRules', '${var.application_name}', '${var.eventhub_name}', 'default'), '2017-04-01').primaryConnectionString]"
    },
    "eventHubNamespaceId": {
      "type": "string",
      "value": "[resourceId('Microsoft.EventHub/namespaces', '${var.application_name}')]"
    }
  }
}
  TEMPLATE
}

To access the defined output variables, you can utilize the jsondecode function.

output "authorization_rule_primary_connection_string" {
  value       = jsondecode(azurerm_resource_group_template_deployment.eventhub.output_content).defaultConnectionString.value
  sensitive   = true
}

- task: AzureCLI@2
  displayName: Register Avro Schemas
  inputs:
    azureSubscription: "Service Connection"
    scriptType: "bash"
    scriptLocation: "inlineScript"
    inlineScript: |
      response=$(az account get-access-token --resource https://<Namespace_Name>.servicebus.windows.net)
        
      token="Bearer `echo $response | jq ."accessToken" | tr -d '"'`"

      avro='{"namespace": "com.azure.schemaregistry.samples","type": "record","name": "Order","fields": [{"name": "id","type": "string"},{"name": "amount","type": "double"}]}'
        
      curl -X PUT -d $avro -H "Content-Type:application/json" -H "Authorization:$token" -H "Serialization-Type:Avro" 'https://<Namespace_Name>.servicebus.windows.net/$schemagroups/<SchemaGroup_Name>/schemas/<Schema_Name>?api-version=2020-09-01-preview'

Using the AzureCLI@2 Tasks along with a Service Connection, we have the capability to execute az commands and obtain an access token for the *.servicebus.windows.net resource. With this token, it becomes feasible to pump Avro files into the registry.

In a further step, I expanded the script to include the capability of reading Avro files from a directory.

response=$(az account get-access-token --resource https://<Namespace_Name>.servicebus.windows.net)

token="Bearer `echo $response | jq ."accessToken" | tr -d '"'`"

for file in *.avro; do
  avro_data=$(cat "$file")     
  schema_name="${file%.*}"

  echo "Publishing $file to schema registry <Namespace_Name>"
  echo "Content: $avro_data"

  curl -X PUT -d "$avro_data" -H "Content-Type:application/json" -H "Authorization:$token" -H "Serialization-Type:Avro" "https://<Namespace_Name>.servicebus.windows.net/\$schemagroups/<SchemaGroup_Name>/schemas/$schema_name?api-version=2020-09-01-preview"
done

There might already be apps out there, that let you know, which food groups generally to avoid. You might generally know, that you don’t feel well after eating strawberries or having a drink of dairy milk. But did you know that some of your favorite products might have traces of it? What does E322 even stand for? Standing in the supermarket, you usually wouldn’t suspect fructose in products that don’t state any fruit per se on the label. Whenever you go shopping it seems like a very lengthy process to study the list of ingredients on the label. It was very frustrating and I was, quite literally, fed up with having to deal with the constant stomach pain, because I accidentally ate something that I wasn’t allowed to consume. Not knowing, if you are sick after indulging on certain products, can be a burden to your social life and your family. Finally, I came up with the idea of inventing an app, that would do the work for me and warn me immediately before buying a pricy product that would end up in the bin. This seemed to be so much better healthwise and environmentally.

This app will help you as well, to source out all the food that you can’t eat and all the food that you can happily indulge on. With many processed foods out there, it’s always good to know what is safe to eat and what not. I am here to help you and make shopping easier and less time consuming and still healthy. I’m still in the early stages of development and love to get your feedback on this. Any intolerance that you are still missing? Please do let me know.

Are you sick of seeing the same hipster stickers everywhere? You attached countless stupid stickers of unknown bands? You finally want to demonstrate your love for salami and co to everyone around you? Then the sausage stickers are exactly what you need!

100% vegan, gluten-free and definitely zero calories!

–

How it started

The idea was born on my way home from the office. In Cologne, as in every major city, the streets are lined with nice and ugly stickers. After some very technical projects I was looking for something different which could build easily as MVP. So i got inspired by sticker art at the traffic lights. I don’t know anymore how I came up with the idea of sausage stickers but it immediately seemed very funny to me.

The same evening I bought the domains wurststicker.de and sausagesticker.com. On the next day I set up the site at Shopify, connected my account to the Stripe API and Paypal and uploaded some nice looking product mockups. I also wrote the product description in several minutes without too much hesitation and created some mockups of the very first products. The shop went live on Oct 02, 2015 after only two days from the initial idea.

Shopify is really nice if you need to set up a shop in a few hours and validate your product idea.

The first sales

The really difficult part was to market the site. The biggest issue, as with every project, is to get attention. If there was a chance that people really like the idea of some crazy stickers I need them to visit the site. Buying ads was no option because it was not foreseeable how well the idea will turn out. The only way for me was to get featured on some blogs or news sites with similar topics. So I wrote a short email with a personal touch describing the product in simple words.

Sausage Sticker for your Notebook

Hello XY, my name ist Stefan and I’m an software developer. Many of my friends are nerds. They stick their notebooks with the very same startup or band stickers. That was too boring for me, I wanted something crazy for my macbook. For this reason I invented the sausage sticker. Currently there is the sticker in the versions salami, mortadella, bacon and steak. Other sausages are already in the works and will follow in the near future. Maybe the topic is interesting for your site. Best regards Stefan

Unfortunately, I have not created a list of all the recipients I wrote to. But it must have been more than 200 emails. Most of them didn’t reply to me but some seemed to be really interested. One of the first Bloggers who published an article about my little project was Marc from testspiel.de. His site drove some traffic and brought the first sales. This was really impressing to me because I did not think that I could get the first sales in that short period of time and with that less effort.

Going Viral

What happened then was really amazing. Marc’s article began his journey to the www. Many different sites also started to write articles about the sausage stickers and people on Facebook shared my site and informed their friends about the project. This peaked on Oct 4, 2015 with nearly 4,000 page views and an revenue of €298.00.

After that weekend my girlfriend and I had a lot of work to do. Printing invoices, putting stamps on the envelopes, writing thank you post it’s and putting everything together.

The absolute traffic peak occured the day that germanys biggest satire magazine put a small link on their page. Although the traffic was really impressive it did not lead to an increase in sales. This might be because people who are coming from a satire magazine are neither in the correct mindset nor do they believe in the seriousness of such an project.

The Numbers

Until today the project made an revenue of €2,187.50. From this amount the fees and the printing have to be deducted. I shipped the sausages to Germany, France, Austria, US, Australia and Island. The best selling product is the “Salami Sticker” which sold 140 times. More than 75% of the payments were made through Paypal.

Conclusion

For me this project was an amazing journey and fun. I do not think that a sustainable business model can be developed from it without much effort. But it yielded some bucks and it motivated me to quickly develop and publish my ideas in the future.