Posts Tagged ‘Mule ESB’

The following error is among of the most hated ones in Mule ESB:
[java]java.util.MissingResourceException: Can’t find bundle for base name META-INF.services.org.mule.i18n.core-messages, locale en_US[/java].

I am not going to describe how to fix it, since several and various reasons may induce it. Anyway, here is an action plan to track and isolate the bug when it happens.

Usually, this MissingResourceException hides the actual error, instead of encapsulating and throwing it. For instance, consider the following stacktrace:
[java]Can’t find bundle for base name META-INF.services.org.mule.i18n.core-messages, locale en_USjava.util.MissingResourceException: Can’t find bundle for base name META-INF.services.org.mule.i18n.core-messages, locale en_US
at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:1427)
at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1250)
at java.util.ResourceBundle.getBundle(ResourceBundle.java:952)
at org.mule.config.i18n.MessageFactory.getBundle(MessageFactory.java:211)
at org.mule.config.i18n.MessageFactory.getString(MessageFactory.java:181)
at org.mule.config.i18n.MessageFactory.createMessage(MessageFactory.java:108)
at org.mule.config.i18n.MessageFactory.createMessage(MessageFactory.java:59)
at org.mule.config.i18n.CoreMessages.initialisationFailure(CoreMessages.java:400)
at org.mule.module.scripting.expression.AbstractScriptExpressionEvaluator.getScript(AbstractScriptExpressionEvaluator.java:93)
at org.mule.module.scripting.expression.AbstractScriptExpressionEvaluator.evaluate(AbstractScriptExpressionEvaluator.java:54)
at org.mule.expression.DefaultExpressionManager.evaluate(DefaultExpressionManager.java:274)
at org.mule.expression.DefaultExpressionManager.evaluate(DefaultExpressionManager.java:210)
at org.mule.expression.DefaultExpressionManager.evaluate(DefaultExpressionManager.java:170)
at org.mule.transformer.simple.MessagePropertiesTransformer.addProperties(MessagePropertiesTransformer.java:165)
at org.mule.transformer.simple.MessagePropertiesTransformer.transformMessage(MessagePropertiesTransformer.java:93)
at org.mule.transformer.AbstractMessageTransformer.transform(AbstractMessageTransformer.java:145)
at org.mule.transformer.AbstractMessageTransformer.transform(AbstractMessageTransformer.java:93)
at org.mule.DefaultMuleMessage.applyAllTransformers(DefaultMuleMessage.java:1305)
at org.mule.DefaultMuleMessage.applyTransformers(DefaultMuleMessage.java:1265)
at org.mule.DefaultMuleMessage.applyTransformers(DefaultMuleMessage.java:1258)
at org.mule.transformer.AbstractTransformer.process(AbstractTransformer.java:118)
at org.mule.processor.ExceptionHandlingMessageProcessor.process(ExceptionHandlingMessageProcessor.java:25)
at org.mule.transport.AbstractMessageReceiver.routeMessage(AbstractMessageReceiver.java:185)
at org.mule.transport.AbstractReceiverWorker$1.doInTransaction(AbstractReceiverWorker.java:126)
at org.mule.transaction.TransactionTemplate.execute(TransactionTemplate.java:116)
at org.mule.transport.AbstractReceiverWorker.doRun(AbstractReceiverWorker.java:149)
at org.mule.transport.AbstractReceiverWorker.run(AbstractReceiverWorker.java:64)
at org.mule.work.WorkerContext.run(WorkerContext.java:309)
at org.mule.work.SyncWorkExecutor.doExecute(SyncWorkExecutor.java:41)
at org.mule.work.MuleWorkManager.executeWork(MuleWorkManager.java:251)
at org.mule.work.MuleWorkManager.doWork(MuleWorkManager.java:175)
at org.mule.transport.jms.MultiConsumerJmsMessageReceiver$SubReceiver.onMessage(MultiConsumerJmsMessageReceiver.java:326)
at com.ibm.mq.jms.MQMessageConsumer$FacadeMessageListener.onMessage(MQMessageConsumer.java:399)
at com.ibm.msg.client.jms.internal.JmsMessageConsumerImpl$JmsProviderMessageListener.onMessage(JmsMessageConsumerImpl.java:1023)
at com.ibm.msg.client.wmq.internal.WMQAsyncConsumerShadow.honourNoLocal(WMQAsyncConsumerShadow.java:566)
at com.ibm.msg.client.wmq.internal.WMQAsyncConsumerShadow.consumer(WMQAsyncConsumerShadow.java:400)
at com.ibm.mq.jmqi.remote.internal.RemoteAsyncConsume.driveConsumer(RemoteAsyncConsume.java:1527)
at com.ibm.mq.jmqi.remote.internal.RemoteDispatchThread.run(RemoteDispatchThread.java:395)
at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.runTask(WorkQueueItem.java:209)
at com.ibm.msg.client.commonservices.workqueue.SimpleWorkQueueItem.runItem(SimpleWorkQueueItem.java:100)
at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.run(WorkQueueItem.java:224)
at com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.runWorkQueueItem(WorkQueueManager.java:298)
at com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplementation$ThreadPoolWorker.run(WorkQueueManagerImplementation.java:1220)V.
[/java]

In IntelliJ IDEA, do Analyse > Analyse Stacktrace... > paste the trace (I have been shown the same tool for Eclipse, somewhere in the Console view). Now you can navigate easily in the code. Then you can notice, line #11, that the Exception you receive is raised by AbstractScriptExpressionEvaluator.
The corresponding piece of code is:
[java] try
{
script.initialise();
}
catch (InitialisationException e)
{
throw new MuleRuntimeException(
CoreMessages.initialisationFailure("An error occurred initialising script."), e);
}[/java]

Add a breakpoint at the level of the throw. Start the debugger, reproduce the bug. In the debugger, you can see the actual error, that is hidden in the stacktrace. In my case, it was a:
[java]org.mule.api.lifecycle.InitialisationException: Scripting engine ‘groovy’ not found. Available engines are: [com.sun.script.javascript.RhinoScriptEngineFactory@3d2227][/java]. Without the debugger, it would have been hard to guess that the original MissingResourceException was linked to a missing Groovy resource ;-).

Case

I have the following block in my Mule config file:

[xml]<servlet:inbound-endpoint path="authenticationService" address="http://localhost:1234">[/xml]

. Even though this block matches XSD constraints, it is illegal from a functionnal point of view.

I get the following stacktrace:

[java]Offending resource: mule-config.xml; nested exception is org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected exception parsing XML document from class path resource [lalou/jonathan/mule-config.xml]; nested exception is org.mule.config.spring.parsers.processors.CheckExclusiveAttributes$CheckExclusiveAttributesException: The attributes of Element servlet:inbound-endpoint{address=http://localhost:1234, name=.authenticationService:inbound.157:inbound-endpoint.158, path=authenticationService} do not match the exclusive groups [address] [ref] [path][/java]

Explanation and Fix

The exception is meaningful: for the tag <servlet:inbound-endpoint>, only one among the three following attributes is needed: path, ref and address.

To fix the issue, keep only the relevant attribute.

Case

I try to deploy a Mule ESB configuration, using this XML:

[xml]<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:pattern="http://www.mulesoft.org/schema/mule/pattern"
xsi:schemaLocation="http://www.mulesoft.org/schema/mule/core
http://www.mulesoft.org/schema/mule/core/3.1/mule.xsd
http://www.mulesoft.org/schema/mule/pattern
http://www.mulesoft.org/schema/mule/pattern/3.1/mule-pattern.xsd
">
<pattern:simple-service name="authenticationService"
address="http://localhost:1234/authenticationService"
component-class="lalou.jonathan.esb.components.AuthenticationComponent"
type="direct" />
</mule>[/xml]

I get the following error:

[java]Ignored XML validation warning
org.xml.sax.SAXParseException: schema_reference.4: Failed to read schema document ‘http://www.mulesoft.org/schema/mule/pattern/3.1/mule-pattern.xsd'[/java]

Extended Stacktrace

[java]2011-11-22 16:10:25,375 WARN  xml.XmlBeanDefinitionReader         – Ignored XML validation warning
org.xml.sax.SAXParseException: schema_reference.4: Failed to read schema document ‘http://www.mulesoft.org/schema/mule/pattern/3.1/mule-pattern.xsd’, because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not <xsd:schema>.
at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:195)
at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.warning(ErrorHandlerWrapper.java:96)
at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:380)[/java]

Notice that Mule ESB files are similar to classic Spring files. Of course, I first checked the pointed XSD was actually reachable.
Anyway, this error should be raised when your application, for any reason -firewall, proxies, network interruption-, cannot access the remote site where the XSD is hosted.

Fix

• Copy the XSD to a local folder
• Create a file spring.schemas
• Make it available in the classpath in META-INF.
• Add the following line
• [java]http\://www.mulesoft.org/schema/mule/pattern/3.1/mule-pattern.xsd=WEB-INF/classes/mule-pattern.xsd[/java]

  The pattern is: missing resource (beware of escaping colon) = path in classpath of the local XSD

• Rebuild, pack and run!

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

In Mule 2.2.1, getting the global variables was allowed. Therefore, such a block worked:

[xml]
<add-message-property key="jonathanProperty"
value="#[groovy:MULE_ORIGINATING_ENDPOINT]" />[/xml]

In Mule 3, this is no more possible. Therefore, how to access -former- global variables within a Mule 3 config file?

Fix

Access the global variables owing to their scope, such as Invocation, Inbound, Outbound, Session, thanks to the methods MuleMessage.get<Scope>Property(), eg:

[xml]<add-message-property key="jonathanProperty"
value="#[groovy:message.getInboundProperty(&quot;MULE_ORIGINATING_ENDPOINT&quot;)]" />[/xml]

Case

You use a filter connector in Mule ESB 2.2.1, to perform any operation (let’s say: to send them on JMS, but this does not matter). You would like to filter files owing to their size, ie stop the handling of files larger than 10,000,000 bytes for instance.

We assume the files you handle are text files (not binary).

Solution

In your Mule XML config file, add the following block, using a short Groovy script:

[xml]<message-properties-transformer name="add-properties">
<add-message-property key="fileSizeOK"
value="#[groovy:message.getPayload().size() &lt; 10000000]" />
</message-properties-transformer>[/xml]
In the tag <file:inbound-endpoint>, add the attribute: transformer-refs="add-properties"
Now, add a tag <message-property-filter pattern="fileSizeOK=true"/>. Your outbound should then be similar to:[xml] <outbound>
<filtering-router>
<jms:outbound-endpoint queue="lalou.jonathan.jms.queue"
connector-ref="jmsConnector"/>
<message-property-filter pattern="fileSizeOK=true"/>
</filtering-router>
<forwarding-catch-all-strategy>
<file:outbound-endpoint path="/my/folder/"
connector-ref="fileConnector" outputPattern="error/#[header:originalFilename].too_big.#[function:dateStamp:yyyyMMdd_HHmmss_SSSSS].KO" />
</forwarding-catch-all-strategy>
</outbound>[/xml]

Many thanks to Vincent N. for his help.

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.

Case

In a Mule ESB workflow, the endpoint is a <jms:outbound-endpoint>, pointing to a JMS queue hosted on MQ Series and accessed through WebLogic 10.3.3.

I get the following stracktrace

[java]Exception stack is:
1. MQJE001: Completion Code 2, Reason 2027 (com.ibm.mq.MQException)
com.ibm.mq.MQQueue:1624 (null)
2. MQJMS2007: failed to send message to MQ queue(JMS Code: MQJMS2007) (javax.jms.JMSException)
com.ibm.mq.jms.services.ConfigEnvironment:622 (http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/jms/JMSException.html)
3. Failed to create and dispatch response event over Jms destination "queue://MQSERVER/AMQ.4C8A5E112285475605?persistence=1". Failed to route event via endpoint: null. Message payload is of type: JMSObjectMessage (org.mule.api.transport.DispatchException)
org.mule.transport.jms.JmsReplyToHandler:154 (http://www.mulesource.org/docs/site/current2/apidocs/org/mule/api/transport/DispatchException.html)[/java]

Fix

On Mule config file, explicitly set the attribute disableTemporaryReplyToDestinations at true in the JMS outbound tag:

[xml]<jms:outbound-endpoint
queue="jonathan.lalou.jms.queue"
connector-ref="jmsConnector"
transformer-refs="foo" disableTemporaryReplyToDestinations="true"/>[/xml]

Case

I have a Mule workflow, of which outbound is a <jms:outbound-endpoint>. The destination queue is hosted on MQ Series and accessed through WebLogic 10.3.3 bridge.

I get the following error:

MQJMS3000: failed to create a temporary queue from SYSTEM.DEFAULT.MODEL.QUEUE

Complete Stacktrace

[java]2010-11-03 13:03:11,421 ERROR mule.DefaultExceptionStrategy       – Caught exception in Exception Strategy: MQJMS3000: failed to create a temporary queue from SYSTEM.DEFAULT.MODEL.QUEUE
javax.jms.JMSException: MQJMS3000: failed to create a temporary queue from SYSTEM.DEFAULT.MODEL.QUEUE
at com.ibm.mq.jms.services.ConfigEnvironment.newException(ConfigEnvironment.java:644)
at com.ibm.mq.jms.MQConnection.createTemporaryQueue(MQConnection.java:2958)
at com.ibm.mq.jms.MQSession.createTemporaryQueue(MQSession.java:4650)
at com.ibm.mq.jms.MQQueueSession.createTemporaryQueue(MQQueueSession.java:286)
at org.mule.transport.jms.Jms11Support.createTemporaryDestination(Jms11Support.java:247)
at org.mule.transport.jms.JmsMessageDispatcher.getReplyToDestination(JmsMessageDispatcher.java:483)
at org.mule.transport.jms.JmsMessageDispatcher.dispatchMessage(JmsMessageDispatcher.java:171)
at org.mule.transport.jms.JmsMessageDispatcher.doDispatch(JmsMessageDispatcher.java:73)
at org.mule.transport.AbstractMessageDispatcher$Worker.run(AbstractMessageDispatcher.java:262)
at org.mule.work.WorkerContext.run(WorkerContext.java:310)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1061)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:575)
at java.lang.Thread.run(Thread.java:619)[/java]

Explanation

A similar issue is described here on Mule support forum. Richard Swart wrote:

This not really mule specific error but an MQ authorization error. The QueueSession.createTemporaryQueue method needs access to the model queue that is defined in the QueueConnectionFactory temporaryModel field (by default this is SYSTEM.DEFAULT.MODEL.QUEUE).

Quick Fix

To fix the issue: on MQ server side, grant visibility to client applications on the default SYSTEM.DEFAULT.MODEL.QUEUE