jbonofre's blog

In the first part of the “Talend ESB Continuous Integration” serie, we saw how to test the Camel routes created by the studio, by leveraging Camel Test Kit. We saw how to have automatic testing using Jenkins. The Maven POM that we did assumes that the route has been deployed (on the local repository or on a remote repository like Apache Archiva). But, it’s not so elegant that a Studio directly publish to the Archiva repository, especially from a continuous integration perspective. In this second article, I will show how to use the Talend commandline with Maven, and do nightly builds using Jenkins. Talend CommandLine CommandLine introduction The Talend commandline is the Talend Studio without the GUI. Thanks to the commandline, you can do a lot of actions, like checkout, export route, publish route, execute route. Actually, you can do all actions except the design itself 😉 You can find commandline*.sh scripts directly in your Talend Studio installation, or you can launch the commandlin

Introduction In this serie of articles, I will show how to setup a Continuous Integration solution mixing Talend ESB tools, Maven, and Jenkins. The purpose is to decouple the design (performed in the studio), the tests (both unit and integration tests), and the deployment of the artifacts. The developers that use the studio should never directly upload to the Maven repository (Archiva in my case). I propose to implement the following steps: the developers use the studio to design their routes: the metadata (used to generate the code) are stored in the subversion. The studio “only” checkouts and commits on subversion: it never directly upload to the artifact repository. a continuous integration tool (Jenkins in my case) uses Maven. The Maven POM leverages the Talend commandline (a studio without the GUI) to checkout, generate the code, and publish to the artifact repository. The Maven POM is also used to execute unit tests, eventually integration tests, and cleanly cut off the releases.

If you are a Karaf user, you probably know that Karaf is very extensible: you can add features in Karaf to provide new functionalities. For instance, you can install Camel, ActiveMQ, CXF, Cellar, etc in your Karaf runtime. Most of these features provide new commands: – Camel provides camel:* commands to manipulate the Camel Context, the routes, etc. – CXF provides cxf:* commands to manipulate the CXF buses, endpoints, etc. – ActiveMQ provides activemq:* commands to manipulate brokers. – Cellar provides cluster:* commands to manipulate cluster nodes, cluster groups, etc. – and so on If you install some features like this, the number of commands available in the Karaf shell console is really impressive. And it’s not always easy to find the one that we need. That’s why subshell support has been introduced. Subshell Karaf now uses commands scope to create “on the fly” a subshell: the commands are grouped by subshell. As you will see later, depending of the completion mode that you will use

This week I worked with David Booschaert. David proposed a patch for Karaf 3.0.0 to add the notion of groups and use ACL for JMX. He posted a blog entry about that: http://coderthoughts.blogspot.fr/2013/10/jmx-role-based-access-control-for-karaf.html . David’s blog is very detailed, mostly in term of implementation, the usage of the interceptor, etc. This blog is more about the pure end-user usage: how to configure group, JMX ACL, etc. JAAS users, groups, and roles Karaf uses JAAS for user authentication and authorisation. By default, it uses the PropertiesLoginModule, which use the etc/users.properties file to store the users. The etc/users.properties file has the following format: user=password,role For instance: karaf=karaf,admin that means we have an user karaf, with password karaf, and admin for role. Actually, the roles are not really used in Karaf: for instance, when you use ssh or JMX, Karaf checks the principal and credentials (basically the username and password) but it doesn

With my ActiveMQ friends (especially Dejan and Claus), I’m working on ActiveMQ 5.9 next release. Today, I focus on the HA with ActiveMQ, and especially Master-Slave configuration. Update of the documentation The first thing that I noticed is that the documentation is not really up to date. If you do a search on the ActiveMQ website about Master-Slave, you will probably find these two links: http://activemq.apache.org/kahadb-master-slave.html http://activemq.apache.org/shared-file-system-master-slave.html On the first link (about KahaDB), we can see a note “This is under review – and not currently supported”. It’s confusing for the users as this mechanism is the prefered one ! On the other hand, the second link should be flagged as deprecated as this mechanism is no more maintained. I sent a message on the dev mailing list to updated these pages. Lease Database Locker to avoid “dual masters” In my test cases, I used a JDBC database backend (MySQL) for HA (instead of using KahaDB). I hav