The bundle includes a small bootstrap script that
can start Activator. To start Typesafe Activator's UI:

In your File Explorer, navigate into the directory that the template was extracted to, right-click on the file named "activator.bat", then select "Open", and if prompted with a warning, click to continue:

Or from a command line:

C:\Users\typesafe\akka-sample-camel-java> activator ui

This will start Typesafe Activator and open this template in your browser.

Option 3: Create a akka-sample-camel-java project from the command line

If you have Typesafe Activator, use its command line mode
to create a new project from this template.
Type activator new PROJECTNAME akka-sample-camel-java on the command line.

Preview the tutorial

Asynchronous routing and transformation

This example demonstrates how to implement consumer and producer actors that support Asynchronous routing with their Camel endpoints. The sample application transforms the content of the Akka homepage, http://akka.io, by replacing every occurrence of *Akka* with *AKKA*.

To run this example, go to the Run tab, and start the application main class sample.camel.http.HttpExample if it's not already started. Then direct the browser to http://localhost:8875 and the transformed Akka homepage should be displayed. Please note that this example will probably not work if you're behind an HTTP proxy.

The following figure gives an overview how the example actors interact with external systems and with each other. A browser sends a GET request to http://localhost:8875 which is the published endpoint of the HttpConsumer actor. The HttpConsumeractor forwards the requests to the HttpProducer.java actor which retrieves the Akka homepage from http://akka.io. The retrieved HTML is then forwarded to the HttpTransformer.java actor which replaces all occurrences of *Akka* with *AKKA*. The transformation result is sent back the HttpConsumer which finally returns it to the browser.

The jetty endpoints of HttpConsumer and HttpProducer support asynchronous in-out message exchanges and do not allocate threads for the full duration of the exchange. This is achieved by using Jetty continuations on the consumer-side and by using Jetty's asynchronous HTTP client on the producer side. The following high-level sequence diagram illustrates that.

It forwards the message to another actor that transforms the message (encloses the original message into hyphens)

The transformer actor forwards the transformed message to a producer actor

The producer actor sends the message to a custom Camel route beginning at the direct:welcome endpoint

A processor (transformer) in the custom Camel route prepends "Welcome" to the original message and creates a result message

The producer actor sends the result back to the consumer actor which returns it to the HTTP client

The producer actor knows where to reply the message to because the consumer and transformer actors have forwarded the original sender reference as well. The application configuration and the route starting from direct:welcome are done in the code above.

To run this example, go to the Run tab, and start the application main class sample.camel.route.CustomRouteExample

From the blog

While Reactive application development is off to a roaring start and becoming mainstream, this leads to demands on Operations that are simply not met by yesterday’s software architectures and technologies. The pressure facing enterprises to manage resilient, responsive systems is brutal, yet most existing technologies available today are not designed to deploy and manage Reactive systems running on clusters. It’s due to this fact that Operations face a higher risk of downtime by using inappropriate tools/practices at a time when being unavailable is more costly than ever. So why is this happening? Well, it's not 2005 anymore–and why that's a problem for Operations is explained here...

Ten months ago we posted about architectural changes to Typesafe Activator. After a few a lot of yak shaves, side projects, and detours, we have Activator 1.3.0 based on sbt server, a new setup where multiple clients can share the same instance of sbt. sbt server is also available in ABI-stable protocol-stable form for other clients (IDEs, command line, desktop status icon, whatever you can think of) to try out.