måndag 26 augusti 2013

Debugging Maven based, embedded Mule ESB Community Edition projects in Mule Studio

If you are running Mule ESB Community Edition embedded in an app server and you are deploying your Mule projects as .war archives to that server you might have come across issues regarding using Maven as build tool for your projects in Mule Studio to enable stand alone debugging of your Mule apps.

When using this setup you are not following Mulesofts recommended format of Maven projects and will probably struggle trying to import them into Mule studio.
Furthermore having a pom.xml building .war files for deploy will not be compatible with the standalone nature of Mule studios setup.

You could of course do remote debugging on your app server platform but I want to be able to completely work in Mule studio first making sure everything works standalone before deploying anything to the embedded Mule CE runtime. Another way is to simply debug as Mule application without Maven, but then come across issues having to add user libraries manually to Mule Studio each time to avoid runtime classloading issues.

My solution to this challenge was to create different profiles in your pom.xml and invoke them based on if you are developing / debugging in Mule or if you are about to deploy and a small trick to make that setup work with Mule studio.

First import your Mule project into Mule studio (you may need to do it without Maven support enabled to be able to import it if you are not following their project format). Then from within the package explorer enable Maven support.
Now edit your pom.xml and add your build plugin if its not there already.


 <build>   
  <plugins>   
   <plugin>   
    <groupId>org.mule.tools</groupId>   
    <artifactId>maven-mule-plugin</artifactId>   
    <version>1.4</version>   
    <extensions>true</extensions>  
   </plugin>   
  </plugins>   
 </build>  

Now to the solution edit your pom.xml and add two profiles one "war" profile and one "standalone" profile.
Make the war version activated by default and set packaging type on it to "war".
In the "standalone" profile set packaging type to "mule" and have the activation being triggered if an environment variable called "environment" is set to "mule" like this:
  <profiles>  
     <profile>  
       <id>war</id>  
       <activation>  
         <activeByDefault>true</activeByDefault>  
       </activation>  
       <properties>  
         <packaging.type>war</packaging.type>  
       </properties>  
     </profile>  
     <profile>  
       <id>standalone</id>  
       <activation>  
             <property>  
                    <name>environment</name>  
                    <value>mule</value>  
                   </property>  
             </activation>  
       <properties>  
         <packaging.type>mule</packaging.type>  
       </properties>  
     </profile>  
  </profiles>  

Now you should be able to build your project as as .war file for deployment on the embedded server just by running your normal maven commands like "mvn clean package".

To be able to do "Debug as Mule application with Maven" in the package explorer menu of Mule Studio you will however need to trigger the other profile.
To do this go into
Windows -> Properties -> Mule Studio -> Maven Settings
and set MAVEN_OPTS environment variable to "-Denvironment=mule".

Now when you do "Debug As Mule Application with Maven" on all your Mule Studio projects it will try to find profiles that are triggered by the "environment" environment variable with value set to "mule" and run it accordingly making sure packaging is .zip rather than .war and that all dependencies and settings for that profile follows your pom structures.

Note that even though projects will build just fine. If you have libraries not included in the Mule CE runtime referenced in a pom project structure with parent pom's that reside outside of the Mule project, the Mule Studio runtime will not find these libraries if they are set as "provided" (read  provided by the parent pom) in the pom.xml. One solution for this is to actually have the dependencies defined inside corresponding profile with "provided" set on the dependency inside the "war" profile and without in the "standalone" profile. Example:

  <profile>  
       <id>war</id>  
       <activation>  
         <activeByDefault>true</activeByDefault>  
       </activation>  
       <dependencies>  
           <dependency>  
                <groupId>org.json</groupId>  
                <artifactId>json</artifactId>  
                <version>20090211</version>  
                <scope>provided</scope>  
           </dependency>  
       </dependencies>    
       <properties>  
         <packaging.type>war</packaging.type>  
       </properties>  
     </profile>  
     <profile>  
       <id>standalone</id>  
       <activation>  
           <property>  
               <name>environment</name>  
               <value>mule</value>  
           </property>  
       </activation>  
       <dependencies>  
       <dependency>  
            <dependency>  
              <groupId>org.json</groupId>  
              <artifactId>json</artifactId>  
              <version>20090211</version>  
            </dependency>  
       </dependencies>              
       <properties>  
         <packaging.type>mule</packaging.type>  
       </properties>  
     </profile>  


Embedded Mule project Mavenized!

4 kommentarer:

  1. Ragon Systems is a leading IT solutions provider in the Indian sub continent. We offer a wide range of solutions and services in various verticals such as strategic IT consulting, training, networking, platform delivery, onsite service and support, outsourcing, customizing and implementing solutions, facility management and application management support.

    SvaraRadera
  2. the blog is about Mule integration hacks it is useful for students and Mulesoft Developers for more updates on Mulesoft follow the link

    mulesoft Online course

    For more info on other technologies go with below links

    Python Online Training

    tableau online training hyderabad

    SvaraRadera
  3. • Nice and good article. It is very useful for me to learn and understand easily. Thanks for sharing your valuable information and time. Please keep updatingAzure Online Training

    SvaraRadera

  4. the blog is good and Interactive it is about Mulesoft API Developer it is useful for students and Mulesoft Developers for more updates on Mulesoft mulesoft Online training

    SvaraRadera