Posts Tagged ‘Jonathan Lalou’

Abstract

I am glad and proud to announce the publication of “Android Application Development with Maven”, on March 15th 2015, by Packt.

Direct link: https://www.packtpub.com/apache-maven-dependency-management/book

Alternate locations: Amazon.com, Amazon.co.uk, Barnes & Noble.

On this occasion, I’d like to thank all Packt team for allowing me achieving this project.

What you will learn from this book

• Integrate Maven with your favorite Android IDE
• Install and configure Maven with your local development environment
• Create the proper Maven structure for both standalone Android applications or applications that are part of a bigger project
• Run unit tests using popular frameworks such as Robolectric and collect coverage information using Maven plugins
• Configure a variety of different tools such as Robotium, Spoon, and Selendroid to run integration tests
• Handle dependencies and different versions of the same application
• Manage and automate the release process of your application inside/outside Google Play
• Discover new tools such as Eclipse, IntelliJ IDEA/Android Studio, and NetBeans, which perfectly integrate with Maven and boost your productivity

In Detail

Android is an open source operating system used for smartphones and tablet computers. The Android market is one of the biggest and fastest growing platforms for application developers, with over a million apps uploaded every day.

Right from the beginning, this book will cover how to set up your Maven development environment and integrate it with your favorite IDE. By sequentially working through the steps in each chapter, you will quickly master the plugins you need for every phase of the Android development process. You will learn how to use Maven to manage and build your project and dependencies, automate your Android application testing plans, and develop and maintain several versions of your application in parallel. Most significantly, you will learn how to integrate your project into a complete factory.

Approach

Learn how to use and configure Maven to support all phases of the development of an Android application

Who this book is for

Android Application Development with Maven is intended for Android developers or devops engineers who want to use Maven to effectively develop quality Android applications. It would be helpful, but not necessary, if you have some previous experience with Maven.

Table of content

• 1: Beginning with the Basics
• 2: Starting the Development Phase
• 3: Unit Testing
• 4: Integration Testing
• 5: Android Flavors
• 6: Release Life Cycle and Continuous Integration
• 7: Other Tools and Plugins

Abstract

I am glad and proud to announce the publication of “Apache Maven Dependency Management”, by Packt.

Direct link: https://www.packtpub.com/apache-maven-dependency-management/book

Alternate locations: Amazon.com, Amazon.co.uk, Barnes & Noble.

On this occasion, I’d like to thank all Packt team for allowing me achieving this project.

What you will learn from this book

• Learn how to use profiles, POM, parent POM, and modules
• Increase build-speed and decrease archive size
• Set, rationalize, and exclude transitive dependencies
• Optimize your POM and its dependencies
• Migrate projects to Maven including projects with exotic dependencies

In Detail

Managing dependencies in a multi-module project is difficult. In a multi-module project, libraries need to share transitive relations with each other. Maven eliminates this need by reading the project files of dependencies to figure out their inter-relations and other related information. Gaining an understanding of project dependencies will allow you to fully utilize Maven and use it to your advantage.

Aiming to give you a clear understanding of Maven’s functionality, this book focuses on specific case studies that shed light on highly useful Maven features which are often disregarded. The content of this book will help you to replace homebrew processes with more automated solutions.

This practical guide focuses on the variety of problems and issues which occur during the conception and development phase, with the aim of making dependency management as effortless and painless as possible. Throughout the course of this book, you will learn how to migrate from non-Maven projects to Maven, learn Maven best practices, and how to simplify the management of multiple projects. The book emphasizes the importance of projects as well as identifying and fixing potential conflicts before they become issues. The later sections of the book introduce you to the methods that you can use to increase your team’s productivity. This book is the perfect guide to help make you into a proud software craftsman.

Approach

An easy-to-follow, tutorial-based guide with chapters progressing from basic to advanced dependency management.

Who this book is for

If you are working with Java or Java EE projects and you want to take advantage of Maven dependency management, then this book is ideal for you. This book is also particularly useful if you are a developer or an architect. You should be well versed with Maven and its basic functionalities if you wish to get the most out of this book.

Table of content

• Preface
• Chapter 1: Basic Dependency Management
• Chapter 2: Dependency Mechanism and Scopes
• Chapter 3: Dependency Designation (advanced)
• Chapter 4: Migration of Dependencies to Apache Maven
• Chapter 5: Tools within Your IDE
• Chapter 6: Release and Distribute
• Appendix: Useful Public Repositories
• Index

Case

I got the project described in MK Yong’s website. This projects is a sample code of JSF + Spring + Hibernate. The laying DB is a MySQL. For many reasons, I’d rather not to detail, I prefered to a HSQLDB instead of the MySQL.

(Notice: the zip you can download at MK Yong’s website contains many errors, not related to the persistance layer but to JSF itself.)

How to migrate any project from MySQL to HSQLDB?

Solution

You have to follow these steps:

Maven

In the pom.xml, replace:
[xml]<!– MySQL database driver –>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>5.1.9</version>
</dependency>
[/xml]
with:
[xml] <!– driver for HSQLdb –>
<dependency>
<groupId>org.hsqldb</groupId>
<artifactId>hsqldb</artifactId>
<version>2.2.8</version>
</dependency>
[/xml]
By the way, you can add Jetty plugin to have shorter development cycles:
[xml] <plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>maven-jetty-plugin</artifactId>
<configuration>
<webApp>${basedir}/target/jsf.war</webApp>
<port>8088</port>
</configuration>
</plugin>[/xml]

Persistence

Properties

Replace the content of db.properties file with:[java]jdbc.driverClassName=org.hsqldb.jdbcDriver
jdbc.url=jdbc:hsqldb:hsql://localhost:9001
jdbc.username=sa
jdbc.password=[/java]

Hibernate Mapping

In the *.hbm.xml files:

• in the tag <class>, remove the attribute catalog="..."
• replace the types with fully qualified object types, eg:
  • long with java.lang.Long,
  • string with java.lang.String,
  • timestamp with java.util.Date,
  • etc.

Hibernate Properties

For the property of key hibernate.dialect, replace the value: org.hibernate.dialect.MySQLDialectorg.hibernate.dialect.HSQLDialect with the value: org.hibernate.dialect.HSQLDialect.
To match my needs, I tuned Hibernate properties a bit more, but it may not be needed in all situations:
[xml] <property name="hibernateProperties">
<props>
<prop key="hibernate.dialect">org.hibernate.dialect.HSQLDialect</prop>
<prop key="hibernate.show_sql">true</prop>
<prop key="hbm2ddl.auto">create-drop</prop>
<prop key="hibernate.hbm2ddl.auto">create-drop</prop>
<prop key="connection.pool_size">1</prop>
<prop key="current_session_context_class">thread</prop>
<prop key="cache.provider_class">org.hibernate.cache.NoCacheProvider</prop>
</props>
</property>
[/xml]

Run

Run the HSQLDB server. IMHO, the quickest is to run the following Maven command:

mvn exec:java -Dexec.mainClass="org.hsqldb.Server"

But you may prefer the old school java -cp hsqldb-XXX.jar org.hsqldb.Server ;-).

Tip! To get a GUI to check the content of the DB instance, you can run:

mvn exec:java -Dexec.mainClass="org.hsqldb.util.DatabaseManager"

Then build and launch Jetty:

mvn clean install jetty:run-exploded

Here you can see the great feature of HSQLDB, that will allow you to create, alter and delete tables on the fly (if hibernate.hbm2ddl.auto is set to create-drop), without any SQL scripts, but only thanks to HBM mapping files.

From now and then, I am certified Scrum Master.

I attended the training lead by Jeff Sutherland (co-founder of Scrum method, CEO of Scrum Inc.).
Jeff gathers both practical knowledge from his personnal experience, and a deep work of research and reflexion on IT and processes around IT. As s skilled manager, engineer and orator, his training brings a lot of information and added value. Many thanks to him!

I’d like to thank Xebia France for their welcome, and, of course, Sungard Global Services and the BKN “Lean and Agile” for investing in its architects continuous improvement.

Case

From an Agile and TDD viewpoint, performing uni tests on DAO is a requirement. Sometimes, instead of using DBUnit datasets “out of the box”, the developper need test on actual data. In the same vein, when a bug appears on production, isolating and reproducing the issue is a smart way to investigate, and, along the way, fix it.
Therefore, how to export actual data from Oracle DB (or even MySQL, Sybase, DB2, etc.) to a DBUnit dataset as a flat XML file?

Here is a Runtime Test I wrote on this subject:

Fix

Spring

Edit the following Spring context file, setting the login, password, etc.
[xml]
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">

<!– don’t forget to write this, otherwise the application will miss the driver class name, and therfore the test will fail–>
<bean id="driverClassForName" class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
<property name="targetClass" value="java.lang.Class"/>
<property name="targetMethod" value="forName"/>
<property name="arguments">
<list>
<value>oracle.jdbc.driver.OracleDriver</value>
</list>
</property>
</bean>
<bean id="connexion" class="org.springframework.beans.factory.config.MethodInvokingFactoryBean"
depends-on="driverClassForName">
<property name="targetClass" value="java.sql.DriverManager"/>
<property name="targetMethod" value="getConnection"/>
<property name="arguments">
<list>
<value>jdbc:oracle:thin:@host:1234:SCHEMA</value>
<value>myLogin</value>
<value>myPassword</value>
</list>
</property>
</bean>

<bean id="databaseConnection" class="org.dbunit.database.DatabaseConnection">
<constructor-arg ref="connexion"/>
</bean>
<bean id="queryDataSet" class="org.dbunit.database.QueryDataSet">
<constructor-arg ref="databaseConnection"/>
</bean>
</beans>[/xml]

The bean driverClassForName does not look to be used ; anyway, if Class.forName("oracle.jdbc.driver.OracleDriver") is not called, then the test will raise an exception.
To ensure driverClassForName is created before the bean connexion, I added a attribute depends-on="driverClassForName". The other beans will be created after connexion, since Spring will deduce the needed order of creation via the explicit dependency tree.

Java

[java]public class Oracle2DBUnitExtractor extends TestCase {
private QueryDataSet queryDataSet;

@Before
public void setUp() throws Exception {
final ApplicationContext applicationContext;

applicationContext = new ClassPathXmlApplicationContext(
"lalou/jonathan/Oracle2DBUnitExtractor-applicationContext.xml");
assertNotNull(applicationContext);

queryDataSet = (QueryDataSet) applicationContext.getBean("queryDataSet");

}

@Test
public void testExportTablesInFile() throws DataSetException, IOException {
// add all the needed tables ; take care to write them in the right order, so that you don’t happen to fall on dependencies issues, such as ones related to foreign keys

queryDataSet.addTable("MYTABLE");
queryDataSet.addTable("MYOTHERTABLE");
queryDataSet.addTable("YETANOTHERTABLE");

// Destination XML file into which data needs to be extracted
FlatXmlDataSet.write(queryDataSet, new FileOutputStream("myProject/src/test/runtime/lalou/jonathan/output-dataset.xml"));

}
}[/java]

Abstract

The application I work on packages Mule ESB 2.2.1 in a WAR and deploys it under a WebLogic 10.3 server. My team mates and I noticed that, on multiple deploy/undeploy cycles, the PermGen size dramatically decreased. The cause of this was the number of threads, which hardly decreased on undeployment phases, unlike the expected behaviour.
Indeed, Mule is seldom deployed as a WebApp. Rather, it is designed to be run as a standalone application, within a Tanuki wrapper. When the JVM is killed, all the threads are killed, too, and therefore no thread survives ; hence, the memory is freed and there is no reason to fear a thread leak.

Moreover, when the application is redeployed, new threads -with the same names as the “old” threads- are created. The risk is that, for any reason, a thread-name-based communication between threads may fail, because the communication pipe may be read by the wrong thread.

In my case: on WebLogic startup, there are 31 threads ; when the application is deployed, there are 150 ; when the application works (receives and handles messages), the number of threads climbs to 800 ; when the application is undeployed, only 12 threads are killed, the other remaining alive.

The question is: how to kill Mule-created threads, in order to avoid a Thread leak?

WebLogic Threads

I performed a thread dump at WebLogic startup. Here are WebLogic threads, created before any deployment occurs:

[java]Attach Listener
DoSManager
DynamicListenThread[Default[1]]
DynamicListenThread[Default]
ExecuteThread: ‘0’ for queue: ‘weblogic.socket.Muxer’
ExecuteThread: ‘1’ for queue: ‘weblogic.socket.Muxer’
ExecuteThread: ‘2’ for queue: ‘weblogic.socket.Muxer’
Finalizer
JMX server connection timeout 42
RMI Scheduler(0)
RMI TCP Accept-0
RMI TCP Connection(1)-127.0.0.1
RMI TCP Connection(2)-127.0.0.1
Reference Handler
Signal Dispatcher
Thread-10
Thread-11
Timer-0
Timer-1
VDE Transaction Processor Thread
[ACTIVE] ExecuteThread: ‘0’ for queue: ‘weblogic.kernel.Default (self-tuning)’
[ACTIVE] ExecuteThread: ‘2’ for queue: ‘weblogic.kernel.Default (self-tuning)’
[STANDBY] ExecuteThread: ‘1’ for queue: ‘weblogic.kernel.Default (self-tuning)’
[STANDBY] ExecuteThread: ‘3’ for queue: ‘weblogic.kernel.Default (self-tuning)’
[STANDBY] ExecuteThread: ‘4’ for queue: ‘weblogic.kernel.Default (self-tuning)’
[STANDBY] ExecuteThread: ‘5’ for queue: ‘weblogic.kernel.Default (self-tuning)’
main
weblogic.GCMonitor
weblogic.cluster.MessageReceiver
weblogic.time.TimeEventGenerator
weblogic.timers.TimerThread
[/java]

Dispose Disposables, Stop Stoppables…

The application being deployed in a WAR, I created a servlet implementing ServletContextListener. In the method contextDestroyed(), I destroy Mule objects (Disposable, Stoppable, Model, Service, etc.) one per one.
Eg#1:

[java] final Collection<Model> allModels;
try {
allModels = MuleServer.getMuleContext().getRegistry().lookupObjects(Model.class);
if (LOGGER.isDebugEnabled()) {
LOGGER.debug("Disposing models " + allModels.size());
}
for (Model model : allModels) {
model.dispose();
}
allModels.clear();
} catch (Exception e) {
LOGGER.error(e);
}[/java]

Eg#2:

[java] private void stopStoppables() {
final Collection<Stoppable> allStoppables;
try {
allStoppables = MuleServer.getMuleContext().getRegistry().lookupObjects(Stoppable.class);
if (LOGGER.isDebugEnabled()) {
LOGGER.debug("Stopping stoppables " + allStoppables.size());
}
for (Stoppable stoppable : allStoppables) {
stoppable.stop();
}
allStoppables.clear();
} catch (MuleException e) {
LOGGER.error(e);
}
}[/java]

This first step is needed because default mechanism is flawed: Mule re-creates objects that were destroyed.

Kill Threads

The general idea to kill Mule threads is the following: perform a Unix-style “diff” between WebLogic native threads, and the threads still alive once all Mule objects have been stopped and disposed.

On Application Startup

In the ServletContextListener, I add a field that will be set in a method called in the constructor:
[java] private List<String> threadsAtStartup;
(…)
/**
* This method retrieves the Threads present at startup: mainly speaking, they are Threads related to WebLogic.
*/
private void retrieveThreadsOnStartup() {
final Thread[] threads;
final ThreadGroup threadGroup;
threadGroup = Thread.currentThread().getThreadGroup();
try {
threads = retrieveCurrentActiveThreads(threadGroup);
} catch (NoSuchFieldException e) {
LOGGER.error("Could not retrieve initial Threads list. The application may be unstable on shutting down ", e);
threadsAtStartup = new ArrayList<String>();
return;
} catch (IllegalAccessException e) {
LOGGER.error("Could not retrieve initial Threads list. The application may be unstable on shutting down ", e);
threadsAtStartup = new ArrayList<String>();
return;
}

threadsAtStartup = new ArrayList<String>(threads.length);
for (int i = 0; i < threads.length; i++) {
final Thread thread;
try {
thread = threads[i];
if (null != thread) {
threadsAtStartup.add(thread.getName());
if (LOGGER.isDebugEnabled()) {
LOGGER.debug("This Thread was available at startup: " + thread.getName());
}
}
} catch (RuntimeException e) {
LOGGER.error("An error occured on initial Thread statement: ", e);
}
}
}
/**
* Hack to retrieve the field ThreadGroup.threads, which is package-protected and therefore not accessible
*
* @param threadGroup
* @return
* @throws NoSuchFieldException
* @throws IllegalAccessException
*/
private Thread[] retrieveCurrentActiveThreads(ThreadGroup threadGroup) throws NoSuchFieldException, IllegalAccessException {
final Thread[] threads;
final Field privateThreadsField;
privateThreadsField = ThreadGroup.class.getDeclaredField("threads");
privateThreadsField.setAccessible(true);

threads = (Thread[]) privateThreadsField.get(threadGroup);
return threads;
}
[/java]

On application shutdown

In the method ServletContextListener.contextDestroyed(), let’s call this method:
[java] /**
* Cleanses the Threads on shutdown: theorically, when the WebApp is undeployed, should remain only the threads
* that were present before the WAR was deployed. Unfornately, Mule leaves alive many threads on shutdown, reducing
* PermGen size and recreating new threads with the same names as the old ones, inducing a kind of instability.
*/
private void cleanseThreadsOnShutdown() {
final Thread[] threads;
final ThreadGroup threadGroup;
final String currentThreadName;

currentThreadName = Thread.currentThread().getName();

if (LOGGER.isDebugEnabled()) {
LOGGER.debug("On shutdown, currentThreadName is: " + currentThreadName);
}

threadGroup = Thread.currentThread().getThreadGroup();
try {
threads = retrieveCurrentActiveThreads(threadGroup);
} catch (NoSuchFieldException e) {
LOGGER.error("An error occured on Threads cleaning at shutdown", e);
return;
} catch (IllegalAccessException e) {
LOGGER.error("An error occured on Threads cleaning at shutdown", e);
return;
}

for (Thread thread : threads) {
final String threadName = thread.getName();
final Boolean shouldThisThreadBeKilled;

shouldThisThreadBeKilled = isThisThreadToBeKilled(currentThreadName, threadName);
if (LOGGER.isDebugEnabled()) {
LOGGER.info("should the thread named " + threadName + " be killed? " + shouldThisThreadBeKilled);
}
if (shouldThisThreadBeKilled) {
thread.interrupt();
thread = null;
}
}

}

/**
* Says whether a thread is to be killed<br/>
* Rules:
* <ul><li>a Thread must NOT be killed if:</li>
* <ol>
* <li>it was among the threads available at startup</li>
* <li>it is a Thread belonging to WebLogic (normally, WebLogic threads are among the list in the previous case</li>
* <li>it is the current Thread (simple protection against unlikely situation)</li>
* </ol>
* <li>a Thread must be killed: in all other cases</li>
* </ul>
*
* @param currentThreadName
* @param threadName
* @return
*/
private Boolean isThisThreadToBeKilled(String currentThreadName, String threadName) {
final Boolean toBeKilled;
toBeKilled = !threadsAtStartup.contains(threadName)
&amp;&amp; !StringUtils.contains(threadName, "weblogic")
&amp;&amp; !threadName.equalsIgnoreCase(currentThreadName);
return toBeKilled;
}
[/java]

EhCache

My application uses an EhCache. Its threads names usually end with “.data”. They are not killed by the previous actions. To get rid of them, the most elegant way is to add this block in the web.xml:
[xml] <listener>
<listener-class>net.sf.ehcache.constructs.web.ShutdownListener</listener-class>
</listener>
[/xml]
cf EhCache documentation

With all these operations, almost all threads are killed. But Java VisualVM still displays 34, vs. 31 at startup.

Tough Threads

A thread dump confirms that, at this point, 3 rebellious threads still refuse to be kill:
[java]MuleServer.1
SocketTimeoutMonitor-Monitor.1
SocketTimeoutMonitor-Monitor.1
[/java]
Let’s examine them:

• MuleServer.1: This thread is an instance of the inner class MuleServer.ShutdownThread. Indeed, this is the first thread created by Mule, and therefore appears among the threads available at startup, before the ServletContextListener is called… I did not succeed in killing it, even why trying to kill it namely, which makes sense: killing the father thread looks like suiciding the ServletContextListener.
• SocketTimeoutMonitor-Monitor.1: This thread is created by Mule’s TcpConnector and its daughter classes: HttpConnector, SslConnector, etc. Again, I could not kill them.

Conclusion

We have seen Mule suffers of major thread leaks when deployed as a WAR. Anyway, most of these leaks may be sealed.
I assume MuleSoft was aware of this issue: in the version 3 of Mule, the deployment of webapps was refactored.

Case

You would like to start a Mule ESB instance as an NT service, under a Windows server. You would also like to give a specific name and description

Fix

• add an environment variable MULE_HOME, with value the path of Mule install, for instance: C:\jonathan\mule-standalone-3.0.1
• edit the file %MULE_HOME%\conf\wrapper.conf
• replace the following properties default values:
  [java]wrapper.ntservice.name=%MULE_APP%
  wrapper.ntservice.displayname=%MULE_APP_LONG%
  wrapper.ntservice.description=%MULE_APP_LONG%[/java]
• (you can also set other properties related to NT service configuration)
• launch the command:

[java]%MULE_HOME%\bin\mule.bat install -config %MULE_HOME%\bin\mule-conf.xml[/java]

• then you can see in the administration services that the service has started
• to remove the service, only launch the following command

[java]%MULE_HOME%\bin\mule.bat remove[/java]

Known issue:

On certain installations (among them the servers on which CygWin is installed), a conflict may happen between the files %MULE_HOME%\bin\mule (standard launcher for Unix and Linux) and %MULE_HOME%\bin\mule.bat (standard launcher for Windows). In this case, rename %MULE_HOME%\bin\mule as %MULE_HOME%\bin\mule.OLD

Case

You have to deliver Mule 2.2.1 as a standalone application, or, more accurately, as a simple archive ready-to-use by someone else (customer, co-team worker, etc.).

In this tutorial, we assume that:

• you have to include external jars, eg. MQ and WebLogic jars
• you have written your XML configuration file for Mule, of which all properties are externalized in an external property file. We don’t mind the actual workflow, we assume you’re skilled enough with Mule 😉

Build

Prerequisites

Prior to building standalone:

• get Mule ESB 2.2.1 standalone archive, available on MuleSoft website
• get the JARs needed by MQ
  • providerutil.jar
  • fscontext.jar
  • dhbcore.jar
  • connector.jar
  • commonservices.jar
  • com.ibm.mqjms.jar
  • com.ibm.mq.jar
• get WebLogic’s wlfullclient.jar
• install the zip and the jars on your local repository:

  mvn install:install-file -DgroupId=org.mulesource -DartifactId=mule-esb -Dversion=2.2.1 -Dpackaging=zip -Dfile=mule-standalone-2.2.1.zip
  mvn install:install-file -Dfile=wlfullclient.jar  -DgroupId=weblogic -DartifactId=wlfullclient -Dversion=10.3 -Dpackaging=jar -DgeneratePom=true
  mvn install:install-file -Dfile=fscontext.jar  -DgroupId=fscontext -DartifactId=fscontext -Dversion=1.2 -Dpackaging=jar -DgeneratePom=true
  mvn install:install-file -Dfile=providerutil.jar  -DgroupId=fscontext -DartifactId=providerutil -Dversion=1.2 -Dpackaging=jar -DgeneratePom=true
  mvn install:install-file -DgroupId=mq -DartifactId=com.ibm.mq -Dversion=6.0.2.0 -Dpackaging=jar -Dfile=com.ibm.mq.jar
  mvn install:install-file -DgroupId=mq -DartifactId=com.ibm.mqjms -Dversion=6.0.2.0 -Dpackaging=jar -Dfile=com.ibm.mqjms.jar
  mvn install:install-file -DgroupId=mq -DartifactId=dhbcore -Dversion=6.0.2.0 -Dpackaging=jar -Dfile=dhbcore.jar
  mvn install:install-file -DgroupId=mq -DartifactId=commonservices -Dversion=6.0.2.0 -Dpackaging=jar -Dfile=commonservices.jar
  mvn install:install-file -DgroupId=connector -DartifactId=connector -Dversion=1.0 -Dpackaging=jar -Dfile=connector.jar

Files to be edited

• Create a mule-jonathan.xml file in src/main/resources/ folder.
• Externalize all properties in mule-jonathan.properties file in src/main/resources/ folder. As you may anticipate it, you will have add this property file in Mule classpath
• To perform that:
  • Copy the wrapper.conf of Mule standalone archive as src/main/resources/wrapper.conf
  • After the line:[java]wrapper.java.classpath.3=%MULE_HOME%/lib/boot/*.jar[/java]

    , add the line:

    [java]wrapper.java.classpath.4=%MULE_HOME%/etc[/java]

• in src/main/resources/, create a file start-mule-jonathan.bat, with the content:[java]
  set MULE_HOME=%CD%
  cd %MULE_HOME%\bin
  mule.bat -config mule-jonathan.xml
  [/java]

Maven

Here is the pom.xml of our project:

[xml]
<?xml version="1.0"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<parent>
<groupId>lalou-jonathan</groupId>
<artifactId>jonathan-parent</artifactId>
<version>1.0</version></parent>
<modelVersion>4.0.0</modelVersion>
<groupId>lalou.jonathan</groupId>
<artifactId>jonathan-lalou-standalone-esb</artifactId>
<packaging>jar</packaging>
<version>${jonathan.version}</version>
<name>jonathan-lalou-standalone-esb</name>
<url>http://maven.apache.org</url>
<dependencies>
<dependency>
<groupId>org.mulesource</groupId>
<artifactId>mule-esb</artifactId>
<version>2.2.1</version>
<type>zip</type></dependency>
<dependency>
<groupId>weblogic</groupId>
<artifactId>wlfullclient</artifactId>
<version>10.3</version></dependency>
<dependency>
<groupId>fscontext</groupId>
<artifactId>fscontext</artifactId>
<version>1.2</version></dependency>
<dependency>
<groupId>fscontext</groupId>
<artifactId>providerutil</artifactId>
<version>1.2</version></dependency>
<dependency>
<groupId>mq</groupId>
<artifactId>com.ibm.mq</artifactId>
<version>6.0.2.0</version></dependency>
<dependency>
<groupId>mq</groupId>
<artifactId>com.ibm.mqjms</artifactId>
<version>6.0.2.0</version></dependency>
<dependency>
<groupId>mq</groupId>
<artifactId>commonservices</artifactId>
<version>6.0.2.0</version></dependency>
<dependency>
<groupId>mq</groupId>
<artifactId>dhbcore</artifactId>
<version>6.0.2.0</version></dependency>
<dependency>
<groupId>connector</groupId>
<artifactId>connector</artifactId>
<version>1.0</version></dependency></dependencies>
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
<excludes>
<exclude>**/*</exclude></excludes></resource></resources>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.2-beta-2</version>
<configuration>
<descriptors>
<descriptor>src/main/assembly/assembly.xml</descriptor></descriptors></configuration>
<executions>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>

[/xml]

Maven Assembly

We will use Maven Assembly: this plugin allows unpack archives, copy files, insert files, delete folders, etc.

Here is the assembly.xml file that should be located in src/main/assembly/ folder of your project. The code is commented so that you understand what we do.

[xml]
<assembly xmlns="http://maven.apache.org/xsd/1.1.0/assembly" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/xsd/assembly-1.1.2.xsd http://maven.apache.org/xsd/1.1.2/assembly">
<id/>
<baseDirectory>jonathan-lalou-standalone-esb-${version}</baseDirectory>
<formats>
<format>zip</format></formats>
<includeBaseDirectory>false</includeBaseDirectory>
<dependencySets>
<dependencySet>
<outputDirectory>/</outputDirectory>
<includes>
<include>org.mulesource:mule-esb</include></includes>
<unpack>true</unpack>
<unpackOptions>
<excludes>
<!– excluse original wrapper.conf, to include our tuned wrapper.conf–>
<exclude>**/conf/wrapper.conf</exclude>
<!–remove the these folders, useless in a standalone client–>
<exclude>**/examples/**</exclude>
<exclude>**/docs/**</exclude>
<exclude>**/src/**</exclude></excludes></unpackOptions></dependencySet>
<dependencySet>
<outputDirectory>mule-standalone-2.2.1/lib/user</outputDirectory>
<excludes>
<exclude>org.mulesource:mule-esb</exclude></excludes></dependencySet></dependencySets>
<fileSets>
<fileSet>
<directory>${basedir}/src/main/resources</directory>
<outputDirectory>/mule-standalone-2.2.1/etc</outputDirectory>
<includes>
<!–include the property file –>
<include>**/*jonathan*.properties</include></includes></fileSet>
<fileSet>
<directory>${basedir}/src/main/resources</directory>
<outputDirectory>/mule-standalone-2.2.1/bin</outputDirectory>
<includes>
<!– include Mule XML config file–>
<include>**/*jonathan*.xml</include></includes></fileSet>
<fileSet>
<directory>${basedir}/src/main/resources</directory>
<outputDirectory>/mule-standalone-2.2.1/conf</outputDirectory>
<includes>
<!– modified wrapper.conf to stake in account the etc/ folder, containing the property file–>
<include>**/wrapper.conf</include></includes></fileSet>
<fileSet>
<directory>${basedir}/src/main/resources</directory>
<outputDirectory>/mule-standalone-2.2.1/</outputDirectory>
<includes>
<include>**/*-mule-jonathan.bat</include>
</includes>
</fileSet>
</fileSets>
</assembly>

[/xml]

Build process

To build go to the folder yourproject/jonathan, then launch a mvn clean install. A complete installation package is output on target folder: jonathan-lalou-standalone-esb-1.0.zip.

The archive is built thanks to Maven Assembly plugin.

Install

Install

Copy or move the archive jonathan-lalou-standalone-esb-1.0.zip to any folder of your choice. Then unzip it.

(optionnal) Checks

Tree

Here is a tree of the installation, with some important file that must appear:

+---start-mule-jonathan.bat
+---bin
¦   +---mule-jonathan.xml
+---conf
¦   +---wrapper.conf
+---etc
¦   +---mule-jonathan.properties
+---lib
¦   +---boot
¦   ¦   +---exec
¦   +---endorsed
¦   +---mule
¦   +---opt
¦   +---user
¦       +------com.ibm.mq-6.0.2.0.jar
¦       +------com.ibm.mqjms-6.0.2.0.jar
¦       +------commonservices-6.0.2.0.jar
¦       +------connector-1.0.jar
¦       +------dhbcore-6.0.2.0.jar
¦       +------fscontext-1.2.jar
¦       +------providerutil-1.2.jar
¦       +------wlfullclient-10.3.jar
¦       +------connector-1.0.jar
+---licenses
+---logs

Files

Check the files listed above in the tree appear. Besides, check the conf/wrapper.conf file contains the line wrapper.java.classpath.4=%MULE_HOME%/etc

Config

Edit etc/mule-jonathan.properties file and set the right properties.

Use

Execute start-mule-jonathan.bat to launch Mule on Windows. On first attempt, Mule will display the user licence and ask you your confirmation you accept the terms of the agreement.

Abstract

You have a non-clustered installation, on the host with DNS name jonathanDevDesktop, with an admin (port: 7001), a muletier (port: 7003) and a webtier (port: 7005) instances.
You need set your muletier as a clustered installation, with two nodes, on the same server. The second node will dedeployed on port 7007.

We assume you have a configured JMS Modules (in our case: JmsMqModule, even though the bridge between WebLogic and MQ has no impact here).

Process

Batches

• Copy $DOMAINS\jonathanApplication\start-muletier-server.bat" as $DOMAINS\jonathanApplication\start-muletier-server-2.bat"
• Edit it:
  • Possibly, modify the debug port (usually: 5006)
  • Replace the line

    call "%DOMAIN_HOME%\bin\startManagedWebLogic.cmd" muletier t3://jonathanDevDesktop:7001

    with

    call "%DOMAIN_HOME%\bin\startManagedWebLogic.cmd" muletier2 t3://jonathanDevDesktop:7001

Second Node Creation

• Following points are not required.
  • Copy the folder %DOMAIN_HOME%\servers\muletier as %DOMAIN_HOME%\servers\muletier2
  • Delete the folders %DOMAIN_HOME%\servers\muletier2\cache and %DOMAIN_HOME%\servers\muletier2\logs
• Stop the server muletier
• On WebLogic console:
  • Servers > New > Server Name: muletier2, Server Listen Port: 7007 > Check Yes, create a new cluster for this server. > Next
  • Name: jonathanApplication.cluster.muletier > Messaging Mode: Multicast, Multicast Address: 239.235.0.4, Multicast Port:5777
  • Clusters > jonathanApplication.cluster.muletier > Configuration > Servers > Select a server: muletier
  • Clusters > jonathanApplication.cluster.muletier > Configuration > Servers > Select a server: muletier2
• Start the instances of muletier and muletier2 in MS-DOS consoles.
• On the WebLogic console:
  • Deployments > jonathanApplication-web (the mule instance) > Targets > check “jonathanApplication.cluster.muletier” and “All servers in the cluster” > Save
• On the muletier2 DOS console, you can see the application is deployed.

JMS Configuration

The deployment of JMS on clustered environment is a little tricky.

• On WebLogic console: JMS Modules > JmsMqModule > Targets > check “jonathanApplication.cluster.muletier” and “All servers in the cluster“
• Even though it is not required, restart your muletiers. Then you can send messages either on port 7003 or 7007, they will be popped and handled the same way.

Overview

Introduction

Let’s consider a application, JonathanGwtApplication, divided in three main panels

• a panel to select animal name name
• a panel to display, expand and collapse trees of the animal ancestors
• a panel of information to display many indicators (colors, ages, etc.).

An issue we encounter is: how to make the different panels communicate? In more technical terms, how to fire events from a panel to another one?

A first solution would be to declare each panel as listener to the other panels. Indeed, this principle may go further, and declare each component as listener to a list of other components…
Main drawbacks:

• the code becomes hard to read
• adding or removing a component requires to modify many parts of the code
• we don’t follow GWT 2’s “philosophy”, which is to use Handlers rather than Listeners.

Hence, these reasons incited us to provide a global EventBusHandler.

The EventBusHandler concept

The EventBusHandler is a global bus which is aware of all events that should be shared between different panels, and fires them to the right components.
The EventBusHandler is a field of JonathanGwtApplicationContext.

Intrastructure

• lalou.jonathan.application.web.gwt.animal.events.HandledEvent: generic interface for a event. Abstract method:
  [java]EventTypeEnum getEventEnum();[/java]
• lalou.jonathan.application.web.gwt.animal.handler.EventHandler: generic interface for a component able to handle an event. Abstract method:
  [java]void handleEvent(HandledEvent handledEvent);[/java]
• lalou.jonathan.application.web.gwt.animal.handler.EventHandlerBus: the actual bus. As a concrete class, it has two methods:
  [java]/**
  * Fires an event to all components declared as listening to this event
  * event type.
  *
  * @param baseEvent
  */
  public void fireEvent(HandledEvent baseEvent) {
  // …
  }

  /**
  * Adds an listener/handler for the event type given as parameter
  *
  * @param eventTypeEnum
  * @param eventHandler
  * @return The List of handlers for the key given as parameter. This list
  * contains the eventHandler that was given as second parameter
  */
  public List<EventHandler> put(EventTypeEnum eventTypeEnum,
  EventHandler eventHandler) {
  // …
  }[/java]

How to use the bus?

1. Define an event: in JonathanGwtApplication, an event is decribed by two elements:
   • a functionnal entity: eg: “animal”, “food”, “tree node”. The functionnal entity must be isomorph to a technical DTO, eg: AnimalDTO for an entity Animal.(in the scope of this turoriel we assume to have DTOs, even though the entities may ne sufficient)
   • a technical description of the event: “selection changed”, “is expanded”
2. Add an entry in the enum EventTypeEnum. Eg: “ANIMAL_SELECTION_CHANGED“
3. in lalou.jonathan.application.web.gwt.animal.events, create an event, implementing HandledEvent and its method getEventEnum(). The match between EventTypeEnum and DTO is achieved here. Eg:
   [java]public class AnimalSelectionChangedEvent extends
   SelectionChangedEvent<AnimalDTO> implements HandledEvent {

   public AnimalSelectionChangedEvent(
   SelectionProvider<AnimalDTO> provider,
   List<AnimalDTO> selection) {
   super(provider, selection);
   }

   public EventTypeEnum getEventEnum() {
   return EventTypeEnum.ANIMAL_SELECTION_CHANGED;
   }

   }[/java]