Posts Tagged ‘tutorial’
Tutorial: a Windows XP as guest VM in Virtual Box
Target and Constraints
I need a Windows XP running as a virtual machine (VM). Don’t think of using your former OEM licence, it won’t work: Windows checks and makes a difference between OEM and other licences.
Microsoft provides VHD files: you can consider them as “virtual” HDD. Officially, these VHD files are intented at developpers to test their websites on various Windows (XP to Seven) and Internet versions (6 to 9).
The VHD files provided for Windows XP need a licence key to be activated, and therefore have two main drawbacks:
- after three days and/or three reboots, the system will allow you to log in anymore. That’s quiet a limitation :-(.
- But wait, there’s even worse: the VHD file provided by Microsoft will be completely disabled on February 14th, 2013!
At last, I stress on having an absolutely legal solution, since it will be deployed both on personnal (Ubuntu) and professional (Windows 8 ) desktop computers. I do not want to waste my time playing hide and seek with authorities.
Prerequisites
In this post I will assume you are a bit familiar with working on VirtualBox. If you are not, then browse the web, ask Google, RTFM, or, at last, leave a message in the comments, I’ll try to figure out a moment to write a short tutorial.
- Download Windows XP VHD file from this page: Internet Explorer Application Compatibility VPC Image. Even though you get a
.exe
file, you can uncompress it with a regular 7-zip. - Download Windows XP SP3 iso file from that page: Windows XP Service Pack 3 – ISO-9660 CD Image File. Keep the
xpsp3_5512.080413-2113_usa_x86fre_spcd.iso
as is. - Download PCINTPC5 ethernet drivers from this page: NDIS5 Driver for Microsoft Windows Server 2003, Windows XP, Windows 2000, Windows ME and Windows 98.
- Unzip and convert this V4.51.zip as an ISO file: as a reminder, the Linux command is:
mkisofs -o target.iso -J --rock sourceFolder
- Alternatively, you can download that ISO that I prepared: ethernet_drivers_for_WinXP_VirtualBox.iso (don’t forget to thank me for the precomputed work)
- Unzip and convert this V4.51.zip as an ISO file: as a reminder, the Linux command is:
Operations
Classic
- Create a VM within VirtualBox
- Name it “Windows XP” for instance
- Set the VHD file as the one downloaded and unzipped above.
Specific
- Run the VM. You must log in as IEUser. The default password is
Password1
(on French keyboards:Pqsszord&
) - Do not validate the licence.
- The VM will require
CmBatt.sys
(and possibly another one):- On host system: mount SP3 iso
device > CD/DVD Devices> Choose a virtual CD/DVD virtual file >
select WinXP SP3 ISO (xpsp3_5512.080413-2113_usa_x86fre_spcd.iso
) - On guest system: run the CD, eg:
Windows+E > D:\ > Autoplay > Install
. All the files will be unzipped in a folder such asC:\1a2b3c4d5e...
(with hexadecimal value). - In the frame asking for
CmBatt.sys
, select it inC:\1a2b3c4d5e...\i386
- On host system: mount SP3 iso
- Windows XP will ask for drivers and try to download them. But the ethernet card has not yet been installed!
- On host system:
-
- Mount the ethernet_drivers_for_WinXP_VirtualBox.iso (cf. above for details)
- Devices > Install Guest Additions > accept all
- On guest system: manually install drivers for ethernet card.
- In order to bypass the limitation of February 14th,
- if you read this post after February 14th, 2013: set the system time to January 1st 2013 for instance (I didn’t test ; it should work)
- disable time synchronization between host and guest systems, eg:
$VIRTUALBOX_HOME/app32/VBoxManage setextradata "Windows XP" "VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled" 1
Now everything should work. I suggest to take a snapshot ;-), and then to revert to it as often as needed.
Conclusions
Officialy, the VHD files provided by Microsoft are intented at developpers who need test their websites on obsolete and out-of-date browsers like Internet Explorer. But you can imagine many other usages. On my side, the interest is to have VM as a module in a complete integrated testing environment and in the frame of a software forge.
My opinion? The solution provided by Microsoft does exist, it’s better than nothing ; anyway, implementing it is a far hard matter. Limitations and complexity of install spoil the user experience. It’s a pity, because the idea of VHD is great, but does not match that of precompiled open source Virtual Boxes: http://www.virtualboxes.org
(quick tutorial) Migration from MySQL to HSQLDB
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:
<!-- MySQL database driver --> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>5.1.9</version> </dependency>
with:
<!-- driver for HSQLdb --> <dependency> <groupId>org.hsqldb</groupId> <artifactId>hsqldb</artifactId> <version>2.2.8</version> </dependency>
By the way, you can add Jetty plugin to have shorter development cycles:
<plugin> <groupId>org.mortbay.jetty</groupId> <artifactId>maven-jetty-plugin</artifactId> <configuration> <webApp>${basedir}/target/jsf.war</webApp> <port>8088</port> </configuration> </plugin>
Persistence
Properties
Replace the content of db.properties
file with:
jdbc.driverClassName=org.hsqldb.jdbcDriver jdbc.url=jdbc:hsqldb:hsql://localhost:9001 jdbc.username=sa jdbc.password=
Hibernate Mapping
In the *.hbm.xml
files:
- in the tag
<class>
, remove the attributecatalog="..."
- replace the types with fully qualified object types, eg:
long
withjava.lang.Long
,string
withjava.lang.String
,timestamp
withjava.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:
<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>
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.
Thread leaks in Mule ESB 2.2.1
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:
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
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:
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); }
Eg#2:
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); } }
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:
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; }
On application shutdown
In the method ServletContextListener.contextDestroyed()
, let’s call this method:
/** * 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) && !StringUtils.contains(threadName, "weblogic") && !threadName.equalsIgnoreCase(currentThreadName); return toBeKilled; }
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
:
<listener> <listener-class>net.sf.ehcache.constructs.web.ShutdownListener</listener-class> </listener>
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:
MuleServer.1 SocketTimeoutMonitor-Monitor.1 SocketTimeoutMonitor-Monitor.1
Let’s examine them:
MuleServer.1
: This thread is an instance of the inner classMuleServer.ShutdownThread
. Indeed, this is the first thread created by Mule, and therefore appears among the threads available at startup, before theServletContextListener
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 theServletContextListener
.SocketTimeoutMonitor-Monitor.1
: This thread is created by Mule’sTcpConnector
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.
Tutorial: Re-package Mule ESB as a standalone client
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 insrc/main/resources/
folder. - Externalize all properties in
mule-jonathan.properties
file insrc/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:
wrapper.java.classpath.3=%MULE_HOME%/lib/boot/*.jar
, add the line:
wrapper.java.classpath.4=%MULE_HOME%/etc
- Copy the wrapper.conf of Mule standalone archive as
- in
src/main/resources/
, create a filestart-mule-jonathan.bat
, with the content:set MULE_HOME=%CD% cd %MULE_HOME%\bin mule.bat -config mule-jonathan.xml
Maven
Here is the pom.xml of our project:
<?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>
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.
<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>
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.
Tutorial: Use WebShere MQ as JMS provider within WebLogic 10.3.3, and Mule ESB as a client
Abstract
You have an application deployed on WebLogic 10 (used version for this tutorial: 10.3.3). You have to use an external provider for JMS, in our case MQ Series / WebSphere MQ.
The client side is a Mule ESB launched in standalone.
Prerequisites
You have:
- a running WebLogic 10 with an admin instance and an another instance, in our case: Muletier.
- a file
file.bindings
, used for MQ.
JARs installation
- Stop all your WebLogic 10 running instances.
- Get the JARs from MQ Series folders:
providerutil.jar
fscontext.jar
dhbcore.jar
connector.jar
commonservices.jar
com.ibm.mqjms.jar
com.ibm.mq.jar
- Copy them in your domain additional libraries folder (usually:
user_projects/domains/jonathanApplication/lib/
) - Start WebLogic 10 admin. A block like this should appear:
<Oct 15, 2010 12:09:21 PM CEST> <Notice> <WebLogicServer> <BEA-000395> <Following extensions directory contents added to the end of the classpath: C:\win32app\bea\user_projects\domains\jonathanApplication\lib\com.ibm.mq.jar;C:\win32app\bea\user_projects\domains\jonathanApplication\lib\com.ibm.mqjms.jar;C:\win32app\bea\user_projects\domains\jonathanApplication\lib\commonservices.jar;C:\win32app\bea\user_projects\domains\jonathanApplication\lib\connector.jar;C:\win32app\bea\user_projects\domains\jonathanApplication\lib\dhbcore.jar;C:\win32app\bea\user_projects\domains\jonathanApplication\lib\fscontext.jar;C:\win32app\bea\ user_projects\domains\jonathanApplication\lib\providerutil.jar>
Config
- Get
file.bindings
, copy it intouser_projects/domains/jonathanApplication/config/jms
, rename it as.bindings
(without any prefix) - Launch the console, login
JMS
>JMS Modules
>Create JMS System Module
>Name
: JmsMqModule. Leave other fields empty. >Next
> target serverMuleTier
>Finish
- Select
JmsMqModule
>New
>Foreign Server
> Name:MQForeignServer
> keep check MuleTier >Finish
- Select MQForeignServer >
- JNDI Initial Context Factory: replace
weblogic.jndi.WLInitialContextFactory
with:com.sun.jndi.fscontext.RefFSContextFactory
- JNDI Connection URL: set the URI of the folder containing the
.bindings
file, eg:file://c/win32app/bea/user_projects/domains/jonathanApplication/config/jms
- JNDI Initial Context Factory: replace
- Tab
Connection Factories
> New >- Name:
MQForeignConnectionFactory
- Local JNDI Name: the JNDI name on WebLogic side, eg:
jonathanApplication/jms/connectionFactory/local
(convention I could observe: separator on WebLogic: slash'/'
; unlike clients for which the separator in a dot'.'
) - Remote JNDI Name: the JNDI name on MQ side, eg:
JONATHAN_APPLICATION.QCF
- OK
- Name:
- Tab
Destinations
> New >- Queue of requests:
- Name:
JONATHAN.APPLICATION.REQUEST
- Local JNDI Name:
JONATHAN.APPLICATION.REQUEST
- Remote JNDI Name:
JONATHAN.APPLICATION.REQUEST
- Name:
- Queue of response:
- Name:
JONATHAN.APPLICATION.REPONSE
- Local JNDI Name:
JONATHAN.APPLICATION.REPONSE
- Remote JNDI Name:
JONATHAN.APPLICATION.REPONSE
- Name:
- NB: usually, MQ data are upper-cased and Java’s JNDI names are low-cased typed ; anyway (because of Windows not matching case?) here we use uppercase in for both names.
- Queue of requests:
- Select MQForeignServer >
Mule
This part of the tutorial deals with a case of Mule ESB being your client application (sending and/or receiving JMS messages).
- Get the archive
wlfullclient.jar
(56MB). Alternatively, you can generate it yourself: go to the server/lib directory of your WebLogic installation (usually:C:\win32app\bea\wlserver_10.3\server\lib
, and run:java -jar wljarbuilder.jar
- Copy the archive into
$MULE_HOME/lib/user
- Copy the seven jars above (
providerutil.jar
,fscontext.jar
,dhbcore.jar
,connector.jar
,commonservices.jar
,com.ibm.mqjms.jar
,com.ibm.mq.jar
) into the same folder:$MULE_HOME/lib/user
- You can launch the mule. The config file is similar to any other configuration using standard JMS.