A JBoss Project
Red Hat

Latest posts

JBoss Developer Studio allows you publish and run your Eclipse projects on OpenShift. This post shows you how to get started using the JBoss Developer Ticket Monster demo application.
In a 2nd part I will show you how to change your code in Eclipse and have those changes instantly available on OpenShift using the JRebel cartridge.

Deploy and Run Ticket Monster on OpenShift

Get the code

The JBoss Developer project created the Ticket Monster demo to showcase a modern angularjs and JavaEE application. The code for this blog is at:

The original code for the Ticket Monster is available at Github.
The webapp with its maven pom is located in the demo folder. OpenShift on the other hand is expecting a pom in the root of the git repository. Without it OpenShift will not know how to build the code when you push it. To fix this I created a fork of the webapp where I put the content of the demo folder to the root of the git repository
  1. Copy this url to your clipboard and in your Eclipse, switch to the Git perspective.

  2. Launch the Clone Git Repository wizard. It will popup with all the values already in place. Hit Next

  3. Pick the master branch and hit Finish to get the repo cloned to your local machine.

  4. Once the cloning is done the new repo will appear in the Git Repositories view.

  5. Import the project within it by using menu:Import Projects…​ in the context menu.

  6. Back to the JBoss or Jave EE perspective you will spot the new project ticket-monster in your workspace.

OpenShift, create an Application for my project, please!

You are now ready to deploy it to OpenShift. Pick Configure  New/Import OpenShift Application from the context menu of the ticket-monster project.

configure openshift application

The OpenShift application wizard that you now get prompts you to provide your OpenShift credentials. Either use an existing account from the combo or create a new one, providing server, username and password.
In the next page we choose to create a new OpenShift application and pick the application type. We will use WildFly 8 which you’ll find by filtering the available choices with "wildfly". The latest version of OpenShift has it in the Basic Cartridges (previous versions - like the one used in the screencast - had it in the quickstarts).

wildfly8 application

Once you picked it you can choose the application name in the next wizard page.
The wizard suggests a name that is based on the project name. OpenShift doesn’t allow non-alphanumeric characters for the name, you therefore have to correct it, remove the hyphen and get "ticketmonster".
You may also select the domain (if you have several ones) and possibly adjust the gear size and have your application scaling.

application settings

If you now hit Finish the wizard will create your OpenShift application, prepare your local project to run on OpenShift and create a server adapter for easy publishing.
Once the wildfly cartridge is created on OpenShift, the tooling presents you the credentials to access the wildfly administrative console in a dialog. You should copy those for later usage:

wildfly admin console

In a last step the wizard informs you that it’ll prepare your local ticket-monster project to run on OpenShift. Confirm these changes by hitting OK.

prepare project for openshift

You are now ready to publish your ticket-monster projcet to OpenShift.

Deploy your project!

Get to the "Servers" view, select the freshly created server adapter and tell it to menu:publish ticket-monster to OpenShift via its context menu.

publish to openshift
publish to openshift 2

The dialog prompts you to provide a commit message and select the files that you want to commit and publish.
Among the listed files is the .gitignore. Double clicking it shows you that it now includes Eclipse specific project settings.
The wizard also added OpenShift configurations in the .openshift folder.
Further interesting bits are a marker to have wildFly running on java 8 (.openshift/markers/java8). OpenShift markers allow you to configure specific bits like enabling debugging (Enable JPDA marker), hot deployment (Hot Deploy marker) etc. You may choose among java 7 and java 8 via marker files in .openshift/markers. You can also spot a wildfly configuration file in .openshift/config/standalone.xml that you can modify to your needs. Once you checked all files by clicking the Select All button and provided a commit message, you’re good to go. You can now publish your project to OpenShift by hitting Commit and Publish

The tooling then informs that it will overwrite the current code in OpenShift by doing a push force. It asks you to confirm this.

push force

This is required since the wizard does not properly include the remote history in our local project/git repo. It clones the remote repo and then copies some of its content into the local project, it does not recursive merge since this is/was not fully reliable yet (see JBIDE-14890 for further details). It is therefore required to overwrite the remote content when you do the initial deployment. Once you hit OK the server adapter is pushing the local code to OpenShift.

Eclipse then shows you the Console with the output of the publishing operation. You can see how the maven build is triggered, WildFly is restarted and your project is then deployed.

build and deploy

In order to verify that your server is fully you can have a look at the logs. Pick OpenShift  Tail files…​ from the OpenShift submenu in the context menu of your ticketmonster server adapter. The upcoming wizard allows you to fine-tune the tail files options and include the gears that your application is running on. You can stick to the default which are usually just fine.

tail files

A fully started Wildfly will output 'Wildfly 8.1.0.Final "Kenny" started' in the logs.

wildfly started

You’re now ready to have a look at your running project. Pick menu:[Show In > Web Browser] from the context menu of your ticketmonster server adapter and see how the browser is pointed to your deployed webapp.

open browser
ticket monster webapp

Change locally, see OpenShift change instantly!

Install JRebel

We are now getting a step further and show you how we can change the application code locally and have those changes instantly available on OpenShift.
To achieve this you need to install the JRebel plugin into your JBoss Developer Studio. The Eclipse plugin is available from JBoss Central. Switch to the Software/Updates tab, search for JRebel, check it once it is listed and hit "Install/Update". Once you restarted Eclipse your have JRebel enabled in your IDE

install jrebel

Enable JRebel for your Project

Open up the context menu of your project and enable the JRebel Nature for your project (menu:[JRebel > Add JRebel Nature]). In a 2nd step then enable JRebel Remoting.

enable jrebel remoting

You have to configure the local JRebel where to publish to. You therefore need the public URL of your ticket monster as it runs on OpenShift. You get this in the application details: pick OpenShift  Details and copy the Public URL.

application public url

Paste it to the JRebel Deployment URL(s) by picking Advanced Properties from the JRebel context menu of your ticket-monster project.

jrebel deployment url

Downgrade to Java 7

Wildfly is configured to run with Java 8 by default. With JRebel enabled the OpenShift small gear that you get for free tends to run out of memory. It is therefore suggested that you downgrade to Java 7. You go to the context menu of your project and pick *OpenShift  Configure Markers…​, uncheck java8 and check Java 7.

java7 marker

Add the JRebel cartridge in OpenShift

The JRebel cartridge for OpenShift, available from Github, makes it very easy to enable JRebel for any Java app on OpenShift. To add this cartridge to your application you get to the Servers view and choose menu: OpenShift[Edit Embedded Catridges…​].
In the upcoming wizard you check the Code Anything cartridge and paste the following url:

code anything cartridge

Once you hit Finish the wizard will add the cartridge to your OpenShift application and enable JRebel for it.

Publish your project to OpenShift

You now have to push all your local changes to OpenShift (you added the JRebel nature and downgraded to java7). You have to tell the server adapter to publish: Choose Publish in the context menu of your OpenShift server adapter.
The upcoming commit- and publish-dialog shows your local changes:

jrebel changes

You replaced the java8 with a java7 marker and added 2 xml files that configure JRebel. Once you add a commit message you’re ready to hit Commit and Publish.
If you now go to the Console view and pick the ticketmonster, you will see how OpenShift picks those changes and rebuilds your code.

ticketmonster console

You can inspect the server logs to make sure wildfly the procedure is all finished and widlfly fully restarted. In the Servers view, pick OpenShift  Tail Files…​, stick to the default options and hit Finish.

wildfly started

'WildFly 8.1.0.Final "Kenny" started' in the logs tells you that wildfly was successfully restarted. You are now ready to change code locally and have them picked up in OpenShift instantly.

Pick my local changes instantly, OpenShift!

We will change the ticket price and we will therefore first check the current price. Use Show In  Browser in the context menu of your server adapter which will open up the application in your browser. In your browser then hit hit Buy tickets now, Book Ticket, choose some venue, date, time and section. You will then see the current price:

ticket price1

Back in your JBoss Developer Studio let us now change the ticket price:
Open up the TicketPrice and get to the getPrice() method. Change it to the following:

    public float getPrice() {
    //   return price;
    	return createFakePrice();

    private float createFakePrice() {
		return 42f;

When you save your Java editor, you will see the JRebel console popping up and show you how it is updating the java classes in OpenShift.

rebel updating openshift

Now get back to your browser and refresh the page. You will have to select the venue again in order to see the new ticket price: It is now at $42!

ticket price2

We did not have to publish our code to OpenShift via the server adapter. JRebel published our local changes on the fly!

This post introduces the new service debugger for JBoss SwitchYard and provides the reader with an overview of SwitchYard’s capabilities, as demonstrated in its example “quickstart” programs.

To install this feature in Developer Studio 8 and JBoss Tools 4.2 you should enable 'Early Access' in Central and install the 'JBoss Integration and SOA Development' connector. See more in the Integration Stack Beta release blog.


One of the most useful (and by the way, also one of the coolest) features of JBoss SwitchYard (http://switchyard.jboss.org/) is its graphical process editor. The editor enables you to create composite service definitions through a graphical interface, instead of having to directly edit cumbersome raw XML. For example:

debugger 1

The big blue box in the center window is called the canvas. Here’s where you can see the graphical representation of the service definition. With SwitchYard, it’s all about the services. With the SwitchYard editor, you can create the services, and not just edit Java source code.

What’s always been missing has been a corresponding tool for debugging SwitchYard Services. This gap is now being filled by the SwitchYard Debugger.

The SwitchYard Debugger

A debugger such as GDB provides you with the ability to interrupt a program’s execution through breakpoints so that you can examine code and data. In SwitchYard, however, you’re not just dealing with Java classes, you 're creating (and debugging) services. The SwitchYard debugger lets you add a breakpoint to any service or reference to a service. The debugger supports these actions:

  • Breakpoints can be configured to stop at various points in the execution chain, including service entry or transaction setup (entry, teardown, fault).

  • If you add a breakpoint on a service, the breakpoint will trigger for any reference or composite service invoking that service. In contrast, if you add a breakpoint on a service reference, it will only break when that reference is invoked.

  • You can also set breakpoints on a composite service to debug validators and transformers (both inbound and outbound). You would do this if you want to see what’s going through a particular transformer or validator which may be used by a number of interactions.

  • If you configure a breakpoint to break on transactions, it will break into the SwitchYard TransactionHandler.handleMessage() method. This generates a stack trace that includes SwitchYard details (for example, an Exchange) that are visible in the SwitchYard context view, so that you can examine elements such as message contents and context properties.

In contrast to a Java debugger, the SwitchYard debugger enables you to invoke breakpoints during steps (such as transformation) during the execution of the service, right in the service bus:

  • Breakpoints on component services and composite references (in other words, providers) will break anytime they are invoked, regardless of who is calling them.

  • Breakpoints on composite services and component references (in other words, consumers) will break whenever they call out.

  • So, if you’re having a problem with a service, putting a breakpoint in the service, will allow you to see what’s going in or out. If you’re having a problem with a component or endpoint, putting a breakpoint on a consumer will allow you to see what’s going in/out, and where it’s going.

  • With regard to the locations within a service (for example, transformation), if you have a specific problem, such as if you’re seeing policy exceptions or transactions aren’t working the way you expect, you can set it to break during the policy phase or the transaction phase to see just what’s going on (which policies are required, which are provided).

The best way to understand the new debugger is to see it in action. We’ll do this by using the debugger with SwichYard "quickStart" example programs. Let’s get started!

Getting SwitchYard

Before we can see the debugger in action, we have to install the SwitchYard runtime and its corresponding Eclipse tooling. Luckily, downloading and installing JBoss software* is quick and painless (and free!)

The steps to install the SwitchYard runtime are:

The steps to install SwitchYard’s Eclipse tooling are:

(We’re using the latest versions of the software available when this post is being written.)

The Quickstarts

One of the helpful features included with JBoss projects are example programs referred to as “quickstarts.” As the name implies, the goal of these examples is to help users get started quickly in learning technologies provided by JBoss projects. As we mentioned earlier in this post, the approach that we’ll take is to introduce a bugs into quickstarts, and then use the debugger to locate these bugs.

To introduce SwitchYard applications to new users, we’ll examine the first quickstart that we’ll use in some detail. If you are already familiar with SwitchYard applications, you can skip over this section of the post.

Let’s start by using the debugger to interrupt a running service in a quickStart and enable us to examine the data in a message being processed by the service. After this, we’ll take things one step further and introduce a bug into a service and then use the debugger to find the cause of the bug and work around it.

Looking under the Hood of a Quickstart

Before we examine how the debugger can be used with a quickStart we’ll take a look at how quickstarts are implemented and how to use the SwitchYard editor.

The first quickstart that we’ll run makes use of Apache Camel to implement content based routing to route messages to selected services. This quickstart is aptly named: rules-camel-cbr. Before we run the quickstart, let’s take a quick look at how it works.

To understand how the quickstart is constructed and how it works, we’ll examine it by looking at these 3 elements:

  • The quickstart’s service based design. We’ll look at this through the SwitchYard visual editor.

  • SwitchYard’s integration of camel routes with the quickstart’s services.

  • The support for testing that SwitchYard provides.

Let’s start by looking at the design of the quickstart application and its services.

To import the quickstart into our JBDS workspace, navigate to File→Import→Maven→Existing Maven Projects:

debugger 2

Browse to the quickstarts directory under the directory into which you installed SwitchYard, select the quickstart and it is imported.

debugger 3

The SwitchYard Service Editor

The SwitchYard graphical application editor enables you to create services and references to services, configure gateway bindings for all the protocols that SwitchYard supports, configure message transformers (to convert messages from one format to another), create skeletons of the classes, interfaces, and unit tests for your services.

The service definitions that you create in the editor are stored in a file named switchyard.xml. In the quickstart, this file is located in the src/main/resources/META-INF directory. All the quickstarts that we’ll use in this post follow this same pattern. Let’s open this file in the editor and take a look around.

debugger 4

To open the file in the editor, simple double-click on the switchyard.xml file’s icon. When the editor opens, here’s what we see:

debugger 5

The big blue box in the center window is called the canvas. Here’s where you can see the graphical representation of the service definitions:

debugger 6

At this point, we should take a moment to understand the graphical symbols that are used in the service definitions.

The visual elements defined in switchyard.xml conform to the OASIS Service Component Architecture Assembly Model Specification (http://docs.oasis-open.org/opencsa/sca-assembly/sca-assembly-spec-v1.1.html). The Service Component Architecture (SCA) model provides standards for building SOA applications.

A green chevron represents a service definition. The corresponding purple chevron represents a reference to a service. The blue rectangles are service components. These are containers that can hold implementations or one or more services through references.

Why was this standard selected as the lingua franca of SwitchYard configuration? What advantages does using this standard give us? There are multiple levels of advantages:

  • The SwitchYard team is using a modular approach that makes it easier to define and maintain a service’s configuration. A switchyard.xml can contain binding info in the same file as the service implementation, but SCA also supports recursive composition, so that one service with just implementation details, can be included inside another. We’ll take a look at the SCA files and pictures that Switchyard tooling makes easy to create and maintain.

  • SwitchYard also wanted to make service interface (or the service "contract") information more explicit, and therefore easier to find.

  • Finally, the SwitchYard team had a choice. They could create a new configuration syntax, or they could try to use something that already existed, was an accepted open standard, and was supported by a vibrant community. (They chose the latter.) Also, SCA is a well-known model for service-oriented applications. But, it’s important to not get too hung-up over the underlying configuration model. The capabilities that the model makes possible, such as modularity, are more important. And, another reason to not worry too much about the configuration model is that SwitchYard provides you with tools such as Forge scripting (and someday soon a SCA editor) to make it easier to create and maintain services' configurations.

The set of fundamental service definition symbols is defined in the OASIS Service Component Architecture Assembly Model Specification here: http://docs.oasis-open.org/opencsa/sca-assembly/sca-assembly-1.1-spec-CD-01.html#_Toc193601722

The other symbols relate to the SwitchYard-specific service implementations and bindings. For example, the RoutingService is implemented as a Camel XML service, the DestinationService is implemented as a JBoss Drools service, and the Red, Blue, and Green services are implemented as Java Bean services.

The full range of options supported by SwitchYard is displayed in the Palette view:

debugger 7

(Yes, it’s a long list. You have to scroll to see all the options.)

One thing to keep is that while this service definitions are persisted in an .xml file, and while you are able to view the contents of that file, you should not attempt to edit the raw XML in that file. The editor has built in protections to ensure that you do not create an invalid configuration. These protections are not in effect if you edit the raw XML directly. Accordingly, while we’ll examine both the information available to you in the graphical editor and the switchyard.xml file, we’ll focus on using the editor.

Let’s start by examining the application service design as presented by the editor, in the context of the application logic flow, then we’ll look a bit deeper into how you can create and manage the application design through the editor.

What happens in the quickstart is a three step process:

  • First, the incoming message is routed, by the RoutingService to the DestinationService

  • Second, the DestinationService uses JBossDrools to determine the correct destination for that message, based on the content in the message

  • Third, the RoutingServer then routes the message to the correct final destination (the Red, Green, or Blue service

How is this all accomplished? Let’s look at the RoutingService definition. Select the RoutingService in the diagram, open the Properties view and you’ll see this:

debugger 8

Remember that this service is a Camel XML service. The implementation of that route is defined in the route.xml file. The route definitions take the form of a Spring DSL. (See http://camel.apache.org/spring-xml-extensions.html for more details.)

The contents of this file are pretty self-explanatory as the destination color determines the ultimate destination. For example:

<from uri="switchyard://RoutingService"/>
<to uri="switchyard://DestinationService"/>
        <simple>${body.destination} == 'Red'</simple>
    <to uri="switchyard://RedService"/>

SwitchYard and Routing With Camel (with help from JBoss Drools)

What happens when the quickstart processes a message is:

First, the incoming message is routed, by the RoutingService to the DestinationService.

As seen in route.xml:

    <from uri="switchyard://RoutingService"/>
    <to uri="switchyard://DestinationService”/>

Let’s look at the DestinationService definition. Select the DestinationService in the diagram, open the Properties view and you’ll see this:

debugger 9

Then, the DestinationService service uses an MVEL statement to find the Widget class’s ID, and rules defined in JBoss Drools (remember that this service is implemented as a JBoss Drools service) to set the Destination value:

As seen in DestinationServiceRules.drl:

rule "Red Destination"
        $widget : Widget(id matches "FF0000-.*")

Then, the route logic continues in a structure to route the message to the correct destination:

OK. We have the Destination value set in each widget. But, how does the widget get routed to the correct destination?

Camel provides a Java DSL (Domain Specific Language) to implement routes. In the DSL, a camel route contains a source ("from") and a destination ("to). These reference the RoutingService and DestinationService interfaces that we just saw in the SwitchYard editor.

In the case of the quickstart, the route definitions take the form of a Spring DSL. The route is self-explanatory, even if you do not have experience with Camel. The destination service is selected based on the content; Red, Green, or Blue.

Test Support in SwitchYard

There’s just one more thing we have to look at before we run the quickstart - how to start the chain reaction of tasks that the quickstart will perform.

Testing server-side applications such as those built with SwitchYard can be difficult. Since this is server-side software, you have to install and run a server, the application has to be deployed to that server, and then you have to construct a client to access the application on the server. You can end up in a situation where you have to build either a throwaway test client, or a reusable test framework. Either way, you have to invest time and effort into building something other than your application.

Luckily, JBoss SwitchYard provides a built in framework that makes testing your applications fast and easy. This QuickStart makes use of the SwitchYardRunner class. SwitchYardRunner is a JUnit Runner class, but more than that, it starts up an embedded SwitchYard runtime. When this embedded runtime starts, your application is packaged up as a SwitchYard application that is deployed to the test instance.

To make use of SwitchYard’s test support, all you have to do is to annotate the test with the SwitchYardRunner JUnit test Runner class. This class will startup an embedded SwitchYard runtime, one for each test method, and then package up the test into a SwitchYard application and deploy that application to the runtime.

In addition to the SwitchYardRunner class, SwitchYard also makes testing easy by providing the TestMixIn feature. TestMixIns enable to turn on additional test support, based on the specific needs of your application. This quickstart makes use of the CDIMixIn to register its bean services. Some of the other TestMixIns support testing http services, JBoss Smooks transformations, and JMS services.

Building, Deploying, and Running the Quickstart

OK, enough talk. Let’s run the quickstart.

First, deploy the quickstart to a SwitchYard server. In JBDS, this is a simple task. It can be done with the server either started or stopped, but let’s start the server first so that you more easily spot the server logging messages when the quickstart is deployed.

To start the server, select it in the “servers” view, and press the start button.

debugger 10

The server console window will open, and you should see something like this:

21:21:59,145 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on
21:21:59,146 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on
21:21:59,146 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.0.0.Final "WildFly" started in 4060ms

Then, to deploy the quickstart, select the server in the “servers” view again, right-click, select “Add/Remove Applications” and select the quickstart.

debugger 11

Switch back to the console view and you should see something like this:

INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018559: Deployed "switchyard-quickstart-rules-camel-cbr.jar" (runtime-name : "switchyard-quickstart-rules-camel-cbr.jar")

To run the client test program, select the rules-camel-cbr/src/test/java/org/switchyard/quickstarts/rules/camel/cbr/RulesCamelCBRTest.java Java source file, and run it as a JUnit test.

Switch back to the server console, and you’ll see the quick start’s output!

INFO  [org.switchyard.quickstarts.rules.camel.cbr.RedServiceBean] Red service processing boxed widget with id: FF0000-ABC-123
INFO  [org.switchyard.quickstarts.rules.camel.cbr.GreenServiceBean] Green service processing boxed widget with id: 00FF00-DEF-456
INFO  [org.switchyard.quickstarts.rules.camel.cbr.BlueServiceBean] Blue service processing boxed widget with id: 0000FF-GHI-789

And the green bar appears!

debugger 12

Now, we’ll use the debugger to interrupt a running service in a QuickStart and enable us to examine the data in a message being processed by the service. After this, we’ll take things one step further and introduce a bug into a service and then use the debugger to find that bug.

Setting a Breakpoint in the Debugger

Let’s start by setting a breakpoint on the Blue service. We’ll use this breakpoint to enable us to view the contents of the message received by the service. For the purposes of our first example, we’ll use the Blue service.

To set a breakpoint in the SwitchYard editor, first position the cursor over the service’s green chevron icon. A small palette of icons is displayed:

debugger 13

To set a breakpoint on the service, select the eyeglasses icon. The presence of this icon on a service definition as seen in the SwitchYard editor indicates that a breakpoint is set:

debugger 14

Notes that as we are adding a breakpoint on the service, the breakpoint will trigger for any reference or composite service invoking that service. In contrast, if you add a breakpoint on a service reference, it will only break when that reference is invoked.

To view and modify the breakpoint’s properties, open the Debug perspective and look in the breakpoints view:

debugger 15

And then right-click on the breakpoint, to view and edit the breakpoint’s properties:

debugger 16

For our example, we’ll use the default properties. We’re mainly concerned with the breakpoint being triggered at service entry.

Now that our breakpoint has been defined, let’s run the RulesCamelCBRTest program again.

To run the test with the debugger, right-click on RulesCamelCBRTest, select Debug As→JUnit Test:

debugger 17

When the breakpoint is reached, the program is suspended. If we look in the Variables view in the Debug perspective, we can see the incoming message and the values that controlled the content-based routing of a message to the Blue service:

debugger 18

Now that we’ve seen the quickstart run correctly, it’s time to introduce a bug, and then use the debugger to find it. For this illustration, we’ll use a different quickstart.

Giving a Quickstart a Bug

Remember the scene in the movie “Independence Day,” when Will Smith uploads a software virus into the evil aliens’ spaceship? Let’s do something similar and add a bug into a quickstart, and then use the debugger to find the bug and even fix it.

Some of the types of bugs that you have to deal with in a services and message based system involve when there are problems in the content in the messages, and how the services are (or are not) able to handle those problems. What sorts of bad things can happen to good messages? Missing a field, wrong namespace, malformed XML, errors in the headers, etc. The debugger makes it possible to tweak a message to debug a problem, without having to redeploy the service.

The quickstart that we’ll look at is “validate-xml.” This quickstart demonstrates the SwitchYard XML validator. The quickstart deploys a service that accepts a message and returns an object that is transformed with XLST. The incoming message is checked for XML validity, so that malformed messages are caught. Before we can run the quickstart, it must be deployed in the same manner as the rules-camel-cbr quickstart that we looked at earlier in this article.

The quickstart’s application diagram is very simple as only one service (“OrderService”) is implemented. This service only accepts a message and returns an object that is processed by the XLST transformer, but it’s adequate for our purposes. The diagram looks like this:

debugger 19

The test application that we want to run is: validate-xml/src/test/java/org/switchyard/quickstarts/validate/xml/WebServiceTest.java

This application executes separate two Junit tests. First, it verifies that a properly formatted SOAP message can be transformed and validated, and then it verifies that an intentionally malformed SOAP message (that is, a message that contains invalid XML) is caught.

Before we look at causing and catching a bug, let’s examine the message tansformation that is performed by this quickstart. The transformation is performed with the order.xslt file in the quickstart. It’s a simple transformation in that it transforms incoming messages that look like this:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <orders:order xmlns:orders="urn:switchyard-quickstart:validate-xml:0.1.0">

Into objects that look like this:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
  <orders:orderAck xmlns:orders="urn:switchyard-quickstart:validate-xml:0.1.0">
     <status>Order Accepted</status>

The change simply indicates whether the incoming order was accepted.

If we set our breakpoint on the “OrderService” service:

debugger 20

And then run/debug the WebServiceTest, we can view the message, before and after its transformation, in the debugger. Here’s the message before transformation:

debugger 21

And here’s the message after its transformation:

debugger 22

The second test in the WebServiceTest intentionally sends a message that includes an invalid XML element.

The invalid SOAP message looks like this:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <orders:order xmlns:orders="urn:switchyard-quickstart:validate-xml:0.1.0">
     <invalid-element>This element is not allowed by XML Schema.</invalid-element>

Yes, it’s easy to spot the invalid XML. ;-)

Let’s expand on this test application a bit and alter it to not gracefully trap the error resulting from the invalid XML. To do this, we’ll edit the invokeOrderWebServiceValidationFail() method and change this:

Assert.assertTrue("Unexpected response: " + response, response.contains("1 validation error(s)") && response.contains("invalid-element"));

To this:

Assert.assertFalse("Unexpected response: " + response, response.contains("1 validation error(s)") && response.contains("invalid-element"));

So that when we run the test, we see this JUnit error:

java.lang.AssertionError: Unexpected response: <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><soap:Fault><faultcode>soap:Server</faultcode><faultstring>SWITCHYARD014000: Validator 'org.switchyard.validate.xml.internal.XmlValidator' failed: 1 validation error(s):
org.xml.sax.SAXParseException: cvc-complex-type.2.4.d: Invalid content was found starting with element 'invalid-element'. No child element is expected at this point.

Before we can debug the OrderService, we must set our breakpoint:

debugger 23

Then we edit the breakpoint’s properties. For our example, we want the trigger to be set for the validation of incoming messages:

debugger 24

When we run/debug the WebServiceTest program, the breakpoint is reached and we can examine the message contents:

debugger 25

And, there’s the invalid XML element. What makes the debugger especially useful is that we can now edit the message and remove the invalid XML:

debugger 26

And then allow the program to resume its operation. In this way, we can determine if the program has any other bugs before we correct the cause of the invalid XML, redeploy, etc.

In Conclusion

We’ve taken an introductory look at the new SwitchYard debugger in this article. The debugger enables you to debug not just a class or method, but a Switchyard service. The debugger is configured through the SwitchYard graphical service/application editor and enables you to both monitor and control the operation of a service to make it easier for you to find those pesky bugs and is a great addition to the SwitchYard developer toolkit.


The author would like to thank Rob Cernich for his input and reviews of the article as it was being written, Keith Babo for his background on the SwitchYard editor, and Jiri Sedlacek for his painstaking review of my sometimes suspect grammar. (Many thanks!)


JBoss Tools 4.29.0.Final for Eclipse 2023-09

by Stéphane Bouchet on Nov 02, 2023.

JBoss Tools 4.28.0.Final for Eclipse 2023-06

by Stéphane Bouchet on Jul 03, 2023.

JBoss Tools for Eclipse 2023-06M2

by Stéphane Bouchet on Jun 05, 2023.

JBoss Tools 4.27.0.Final for Eclipse 2023-03

by Stéphane Bouchet on Apr 07, 2023.

JBoss Tools for Eclipse 2023-03M3

by Stéphane Bouchet on Mar 10, 2023.

Looking for older posts ? See the Archived entries.
back to top