Use Camel Routes in Java EE components

Use Camel Routes in Java EE components
[Editor's note] Markus Eisele, Developer Advocate of Red Hat, is mainly engaged in JBoss Middleware research and has more than 14 years of Java EE experience. In this blog, Markus mainly shares the Camel Routes application practices based on Java EE components. After using Camel in the production environment for a while, I became more and more fond of its simplicity. There are indeed some challenges to use Java EE, and I mentioned how to implement this in my last speech. In Java EE, we can use Camel in different ways. We recommend that you use the WildFly-Camel subsystem. In the next series, I will explore different ways to implement it and provide examples that are not covered in my speech. We look forward to receiving your feedback and questions by leaving a message or asking questions. Camel On WildFly 8.2 getting started WildFly-Camel subsystem provides an integrated environment for Apache Camel and WildFly application servers. It allows you to add a Camel Routes (route) as part of the WildFly configuration. Routes can be deployed as part of a Java EE application. Java EE components can use the core APIs of Camel and multiple Camel Component APIs. Your enterprise-level integrated solution can be built on the joint functions of Java EE and Camel. Note: The latest WildFly9 is expected to be supported by WildFly-Camel 3.x. In the preparation phase, download and decompress WildFly 8.2.0.Final to the directory you specified, download and decompress wildfly-camel patch (2.3.0) to the wildfly directory. Run the following command to start WildFly: bin/standalone [. bat |. sh]-c the fastest way to start and run the standalone-camel.xml is by using Docker and WildFly Camel image. The image here requires the WindFly8.1 and Camel subsystems to be installed in advance. Defining and using Camel ContextCamelContext represents a Camel routing rule repository. CamelContext is similar to Spring ApplicationContext. It contains all the routes for your application. You can use any number of CamelContext as needed. Of course, they must be defined by different names. WildFly-Camel can be defined and deployed in three different ways: in standalone-camel.xml and domain. xml is defined as part of the subsystem; deploy in a deployment artifact that supports them, of course, this deployment artifact must contain files suffixed with-camel-context.xml; use RouteBilder and CDI integration to define deployment and provide route information. A defined CamelContext can be used in two different ways: through Camel-CDI injection through the JNDI tree. In the following example, we will use the Context of an associated Route, which is provided through CDI and RouteBuilder. Is an application-level bean that is automatically started when the application is started. @ ContextName: The annotation gives CamelContext a specific name.

@ApplicationScoped@Startup@ContextName("cdi-context")public class HelloRouteBuilder extends RouteBuilder {    @Inject    HelloBean helloBean;    @Override    public void configure() throws Exception {        from("direct:start").transform(body().prepend(helloBean.sayHello()).append(" user."));    } }

 

Routing itself is not really challenging. It has an empty information subject from direct: start and uses the CDI bean method "sayHello" prepends output, and then append the string "user .". For reference, the complete code can be found in my GitHub (https://github.com/myfear/camel-javaee. Therefore, what we need to know next is how to use this route in various Java EE components. Using CamelCamel in CDI supports CDI since version 2.10. Before a subsystem exists, it needs to be bootstrapped. But you don't need it now. You can just use a deployed or defined CamelContext to inject its name into @ Named CDI bean through simple @ Injecting. @ Inject @ ContextName ("cdi-context") private CamelContext context; using Camel in Java EE components using Camel Routes in JSF, JAX-RS, and EJBs you may think, it should be as simple as using JSF, but this is not the case-you cannot inject it into ManagedBeans or CDI Beans bound to the JSF component. In addition, it cannot be used in EJB. I did not dig into details here, but I think it does need to be improved in terms of border control. A reasonable solution, in fact, a better application design is to put a complete Camel logic into a separate CDI bean and inject it.

@Namedpublic class HelloCamel {    @Inject    @ContextName("cdi-context")    private CamelContext context;private final static Logger LOGGER = Logger.getLogger(HelloCamel.class.getName());public String doSomeWorkFor(String name) {      ProducerTemplate producer = context.createProducerTemplate();     String result = producer.requestBody("direct:start", name, String.class);     LOGGER.log(Level.INFO, result);     return result;}}

 

The ProducerTemplate interface allows you to exchange information from the Java code to the endpoint, making it easy to collaborate with the Camel Endpoint instance in a variety of ways. In this special case, it only starts the route and adds a string that represents the component name to the body. CDI Bean plays the backing-bean role for components that use it:

@Inject    HelloCamel helloCamel;public String getName() {      return helloCamel.doSomeWorkFor("JSF");}

 

The returned string is "Hello JSF user." And is also written into the server log of WildFly. This method is also the best for other Java EE components. If you use Camel in EJB as your main application component module, it is reasonable to use the JNDI method: CamelContext camelctx = (CamelContext) inicxt. lookup ("java: jboss/camel/context/cdi-context"); Hawtio: one Camel console in the subsystem, and the other hidden baby is the Hawtio console. This is a modular Web console used to manage your Java components. It has an Apache Camel plug-in to visualize your context and routing information. Remember, it is automatically configured. To ensure security, you must add a management user before using it.