I will use “hello” sample project from Mule installation.

hello.zip contains modified “hello” Mule project where I removed “.bat” file, commented out “version” tag in pom.xml to make maven build work, added [...]]]> This article shows how to get Maven based Mule project to easily work within Eclipse without the need of constant redeployment to mule lib/user directory.

I will use “hello” sample project from Mule installation.

hello.zip contains modified “hello” Mule project
where I removed “.bat” file, commented out “version” tag in pom.xml to make maven build work, added dependency to vm and stream transports and put log4j.properties for easy access.

1. Run “mvn eclipse:eclipse” on your project to create Eclipse project from it and go to “File->Import->General\Existing Projects into Workspace” to import it into Eclipse.
2. Go-to Run->Run menu open “Run” dialog. It should look like this:
   
   
   
3. Now we need to create a new Java Application configuration that will launch Mule. Right click on “Java Application” node and select “New” you should see this:
   
   
   
4. • Type “mule-example-hello” in the “Name:” field.
   • For project click “Browse” and select the mule project you imported, in our case it will be “mule-example-hello”.
   • Type “org.mule.MuleServer” in “Main class:” field.
   • Check “Include libraries when searching for main class” and “Include inherited mains when searching for a main class”

   After all it should look like this:
   
   
   

5. Select “Arguments” tab and type “-config ${resource_loc}” in “Program Arguments” field. Type “-Dlog4j.configuration=file:///${project_loc}\log4j.properties” in “VM Arguments” field for Mule to find the log4j config file.
   This assumes that log4j config file is in the root of the project (you can change the path to your own log4j config location).
   
   
   
6. Click “Close”.
7. Now to run mule ESB with desired mule config file select the desired config file and click run button in the toolbar.
   To bypass the config file selection change the “Program arguments” to “-config ${project_loc}\conf\hello-config.xml” to always run “hello-config.xml” configuration.

Download project – dwr-test.zip Download WAR – dwr-test-war-1.0.0.war Test (default weblogic install) – http://localhost:7001/dwr-test-war-1.0.0/test.html When promted type user name “weblogic” password “weblogic” for default weblogic install.

Screenshot.

This article shows how to implement pure AJAX application that does round trip communication to Java back end using custom DOJO widgets for client, DWR for JavaScript to Java communication and Spring that [...]]]> Intro:

Download project – dwr-test.zip
Download WAR – dwr-test-war-1.0.0.war
Test (default weblogic install) – http://localhost:7001/dwr-test-war-1.0.0/test.html
When promted type user name “weblogic” password “weblogic” for default weblogic install.

Screenshot.

This article shows how to implement pure AJAX application that does round trip communication to Java back end using custom DOJO widgets for client, DWR for JavaScript to Java communication and Spring that will manage back end Java objects.
Full Maven2 project is provided for download.

There are two ways of building AJAX applications.

The approach I like and took is Single page (1) because its more natural to client/server development where the only thing passed in-between is data.
But I wont be shy of using multi page approach if need arises.


The reason for technology choices:

DOJO – a very comprehensive cross browser JavaScript framework with good
support for packaging, AJAX, AOP like method interceptors, event handling and most
important built in and custom widgets that can be composed together much like in Swing.

DWR – you can use plain AJAX for client server communication or simply let
DWR marshal your JavaScript object to Java.

Spring – it is always my choice of Java integration/container framework.

The project I put together is J2EE Web application which contain Java back end components and simple html file that will bootstrap our Dojo widget which in turn will use DWR to communicate back to Java backend (no JSP is involved).
In addition I incorporated Servlet security to show how to authorize your Dojo app user against Java back end.

DOJO:

In earlier Dojo releases no custom widget could have been developed outside of Dojo source package. This was fixed in latest releases where it is possible to move custom
widget code base outside of Dojo package but with one restriction which is the custom package needs to share same parent directory as the Dojo package, like this:

js/dojo/src (dojo packaging)
js/app/widget (custom packaging)

Dojos recommended packaging structure for custom widgets is “namespace/widget” directory structure. From above directory layout “app” is will be our namespace.
Theoretically it is possible to have deeper directory structure for custom widgets after “app” directory but it never worked for me.
For more information how to Dojo finds custom package look at “manifest.js” file under “app” directory and widgets themselves.
Included with the sample project is non widget code that shows how to package non widget package outside of Dojo (yes it is different), it is under “js/app/common/data”.

One of issues I had with Dojo is its documentation. Most of my time was spent on investigating widget API which is close to impossible with dynamic nature of JavaScript.
The best place to get familiar with Dojo is DojoBook, to see Dojo widgets in action and how to use them look here http://archive.dojotoolkit.org/nightly/tests/widget/ (click on links that start with “test”) and finally the discussion group can be found at http://news.gmane.org/gmane.comp.web.dojo.user.

- dojo.debugDeep(obj) is quite a useful utility which will pop up dialog and allow to drill down the object properties. This helps a lot when you are dealing with object of unknown type.

DWR:
What I like about DWR java support is that it is very straightforward (more like Spring Framework, I think it should be integrated more into Spring at some point).

DWR allows different ways of exposing Java objects, one of which is exposing them through Spring context. For more info check out “WEB_INF/dwr.xml”,
“WEB-INF/servlet-context.xml” and “web.xml” to see how DWR gets integrated with our Service objects.
Official DWR/Spring examples can be found here http://getahead.ltd.uk/dwr/server/spring.

In a nutshell we use DWR Servlet that will find Spring context previously loaded by configured Servlet Listener and automatically marshal JavaScript to Java calls
probably using JSON underneath.

Security – Authentication and Authorization:

JavaScript has always been regarded as a security issue. One of the main issues DWR lists is that anyone from outside can call Java objects which are exposed through DWR and JavaScript.
Personally I consider this more of generic Web client/server security issue which is commonly solved in J2EE Web clients thought Servlet security model.
Since our Dojo widgets are loaded from Servlet container we can secure them same way as we secure JSPs and Servlets. All we have to do is tell Servlet container
to secure html file that bootstraps Dojo widgets so that when we first access it the container will prompt for user name/password.

DWR can automatically pass “HttpServletRequest” object from which we can get logged in user for further authorization (check http://getahead.ltd.uk/dwr/server/javaapi for more information). This does pollute Service interface but we have to threat this object more like JavaScript proxy which will delegate calls to actual Service object that contains actual business logic.
Current implementation uses BASIC Servlet authentication but it should be easy to change it to FORM based and embed into our DOJO widget.

Download project – dwr-test.zip
Download WAR – dwr-test-war-1.0.0.war
Test (default weblogic install) – http://localhost:7001/dwr-test-war-1.0.0/test.html
When promted type user name “weblogic” password “weblogic” for default weblogic install.

Note:
Looks like Tomcat authentication does not like

defined in web.xml.
To get authentication working on Tomcat change

to

in web.xml and add “user” to “conf/tomcat-users.xml” like this:

This is a simplified and more flexible version of build plugin.

This plugin allows to execute specified goals on all project and sub projects under current base directory.

The plugin is using “maven.multiproject.type” and “command” property to determine project and command types in order to execure appropriate list of goals.

The plugin will append the value specified in [...]]]> maven-run-plugin-1.0.jar

This is a simplified and more flexible version of build plugin.

This plugin allows to execute specified goals on all project and sub projects under current base directory.

The plugin is using “maven.multiproject.type” and “command” property to determine project and command types in order to execure appropriate list of goals.

The plugin will append the value specified in “maven.multiproject.type” and “command” properties to “.goals” to get list of maven goals to run.

NOTE: There should not be any space in goals or ignore failures list.

Use cases:

1. Command specified but no goals and ignore failurs are specified. The command will be used as goal name.

#Goal
maven -Dcommand=clean run

#Property Files (build.properties or project.properties at base or parent level)
Nothing

OR

#Goal
maven run

#Property Files (build.properties or project.properties at base or parent level)
command=clean

Will run clean goal on base and sub projects.

2. Command, goals and ingnore failures are specified.

#Goal
maven -Dcommand=build run

#Property Files (build.properties or project.properties at base or parent level)
jar.build.goals = clean,jar:jar,jar:install
ejb.build.goals = clean,ejb:ejb,ejb:install
war.build.goals = clean,war:war,war:install
ear.build.goals = clean,ear:ear,ear:install

OR

#Goal
maven run

#Property Files (build.properties or project.properties at base or parent level)
command=build
jar.build.goals = clean,jar:jar,jar:install
ejb.build.goals = clean,ejb:ejb,ejb:install
war.build.goals = clean,war:war,war:install
ear.build.goals = clean,ear:ear,ear:install

Will run “clean” ,”jar:jar” and “jar:install” on jar project, “clean” ,
“ejb:ejb” and “ejb:install” on ejb project an same for war and ear.

3. If “command” or “maven.multiproject.type” are not specified the plugin will
replace them with empty string.
The following will achieve same as above, since command is not specified it
is replaced with empty string in goals:

#Goal
maven run

#Property Files (build.properties or project.properties at base or parent level)
jar..goals = clean,jar:jar,jar:install
ejb..goals = clean,ejb:ejb,ejb:install
war..goals = clean,war:war,war:install
ear..goals = clean,ear:ear,ear:install

4. Optionally you can specify the “ignore.failures” property which will be used during maven reactor. For example the first goal will be run with ignoreFailures=true the rest with ignoreFailures=false

jar.build.goals = clean,jar:jar,jar:install
jar.build.ignore.failures = true,false,false

5. If ignore is omitted for particular goal it will be replaced with last ignore. For example this will acieve the same as above:

jar.build.goals = clean,jar:jar,jar:install
jar.build.ignore.failures = true,false

6. If nothing is specified or is undefined in ignore failures list
it will be replaced with “true” value:
For example these two will acieve the same as above:

jar.build.goals = clean,jar:jar,jar:install
jar.build.ignore.failures = ,false,false

OR

jar.build.goals = clean,jar:jar,jar:install
jar.build.ignore.failures = fsdfdsf,false,false

This article brings together Spring and XFire configuration examples to show how to expose simple POJO into SOAP service with EJB façade in between. Lets take a simple example of number add and subtract service. Here is component diagram of what we are trying to achieve.

To accomplish the above setup we’ll follow these simple steps. Create [...]]]> Full Maven Project.

This article brings together Spring and XFire configuration examples to show how to expose simple POJO into SOAP service with EJB façade in between.

Lets take a simple example of number add and subtract service.

Here is component diagram of what we are trying to achieve.

To accomplish the above setup we’ll follow these simple steps.

Create NumberService interface and implementation.

public interface NumberService{

 public int add(int n1, int n2);
 
 public int substract(int n1, int n2);
}  

public class NumberServiceImpl implements NumberService{

 public int add(int n1, int n2){
  return n1 + n2;
 }
 
 public int substract(int n1, int n2){
  return n1 - n2;
 }
}

Create app-context.xml (you can name this file anything you want).

Since we are using Spring Framework it just makes sense to define the NumberServiceImpl in spring context file to be later injected into NumberServiceSessionBean. This will allow us to decouple
NumberServiceSessionBean from NumberServiceImpl. Here is the full context file called app-context.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">
<beans>

<bean name="numberService" class="NumberServiceImpl">
</bean>

</beans>

Make sure this file is in classpath for EJB to load.

Create NumberServiceSessionBean

import java.rmi.RemoteException;
import javax.ejb.CreateException;

import org.springframework.ejb.support.AbstractStatelessSessionBean;

public class NumberServiceSessionBean extends AbstractStatelessSessionBean{  
 private NumberService numberService = null;
 
 protected void onEjbCreate() throws CreateException{
  numberService = (NumberService)getBeanFactory().getBean("numberService");
 }

 public int add(int n1, int n2) throws RemoteException {
  return numberService.add(n1, n2);
 }
 
 public int substract(int n1, int n2) throws RemoteException {
  return numberService.substract(n1, n2);
 }
}

Here are few things worth to mention.

• It extends Spring helper AbstractStatelessSessionBean class which will load spring context behind the scene and expose it through
  BeanFactory getBeanFactory() method.
  Some might ask how it knows which context file to load? Well in order to tell the AbstractStatelessSessionBean the location of context file we need to define it in EJB deployment (called ejb-jar.xml ) file like this.

  
  <br>
  <env-entry>
  <env-entry-name>ejb/BeanFactoryPath</env-entry-name>
  <env-entry-type>java.lang.String</env-entry-type>
  <env-entry-value><![CDATA[app-context.xml]]></env-entry-value>
  </env-entry>
  
  

• Each NumberServiceSessionBean instance will load context file separately and will have its own instance of NumberServiceImpl.
• It does not directly implement NumberService but implements the exact methods. The reason behind this is two-part. First it is the infamous issues of the need to declare RemoteException in NumberService. Second one will be explainined later when we expose it as proxy to Xfire servlet.

Create XFire web component.
For XFire to be able to receive SOAP calls we need to configure it as Servlet.

What we are going to do is again leverage Spring Framework by reusing its org.springframework.web.servlet.DispatcherServlet and expose XFire to it as Spring MVC controller.

The good news is that XFire already provides implementation of this controller in “org.codehaus.xfire.spring.remoting.XFireExporter” class.

To have complete web application we need to create web.xml and Spring nameservice-context.xml file that will contain Controller and EJB proxy definitions.
Put both under WEB-INF directory.

web.xml

<!DOCTYPE web-app PUBLIC
 "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd" >

<web-app>
<display-name></display-name>

<servlet>
<servlet-name>nameservice</servlet-name>
<servlet-class>
org.springframework.web.servlet.DispatcherServlet
</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
<servlet-name>nameservice </servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
  
</web-app>

Once deployed and loaded in Servlet container DispatcherServlet will assume there is Spring context file under WEB-INF directory with name {servlet-name}-servlet.xml
which is in our case nameservice-servlet.xml.

nameservice-servlet.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">
<beans>

<!-- include xfire specific beans -->
<import resource="classpath:org/codehaus/xfire/spring/xfire.xml"/>

<bean id="NameServiceSessionBeanProxy" 
class="org.springframework.ejb.access.SimpleRemoteStatelessSessionProxyFactoryBean">
<property name="jndiName">

<!-- this name depends on how you bind your EJB. Usually it is by
its Home package name -->

<value>NameServiceSessionHome</value>
</property>
<property name="jndiEnvironment">
<props>
<prop key="java.naming.factory.initial">weblogic.jndi.WLInitialContextFactory</prop>
</props>
</property>
<property name="resourceRef">
<value>false</value>
</property>

<!-- Set this property to false so that to avoid not finding NameServiceSessionBean when servlet is deployed prior to NameServiceSessionBean is deployed -->

<property name="lookupHomeOnStartup"> 
<value>false</value>
</property>
<property name="businessInterface">
<value>NameService</value>
</property>
</bean>

<bean id="NameServiceSessionWS" class="org.codehaus.xfire.spring.remoting.XFireExporter">
<property name="style">
<value>rpc</value>
</property>
<property name="use">
<value>encoded</value>
</property>
<property name="serviceFactory">
<ref bean="xfire.serviceFactory"/>
</property>
<property name="xfire">
<ref bean="xfire"/>
</property>
<property name="serviceBean">
<ref bean="NameServiceSessionBeanProxy"/>

 <!-- Here we cheat XFireExporter into thinking that it is dealing with simple NameService POJO -->

</property>
<property name="serviceInterface">
<value>NameService</value>
</property>
</bean>

<!-- DispatcherServlet will always invoke NameServiceSessionWS controller when URL ends with "nameservice" -->
<bean class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
<property name="urlMap">
<map>
<entry key="/nameservice">
<ref bean="NameServiceSessionWS"/>
</entry>
</map>
</property>
</bean>

</beans>

Finally to test your WebService invoke http://localhost:7001/nameservice?wsdl which will generate the WSDL.

Included with the war project is JUnit test that uses Spring and XFireClientFactoryBean to remotely call XFire service using Spring and XFire proxies. For more detailed tutorial
on XFireClientFactoryBean check http://xfire.codehaus.org/Spring+Remoting.

The unit test requires “commons http client” libraries, so make sure to include them as dependencies in your war as is done in attached maven projects.

Full maven project can be downloaded from HERE.

Build Instructions

• This project is based on Maven2. Currently standard Maven2 remote repositories dont have xfire-all-1.2.2.jar. You might need to manually get it from here and put into your local repository under xfire\xfire-all\1.2 directory.
• If you are going to deploy it to Weblogic it wont work unless resolve QName issue as shown here.

Please use improved version of this plugin from this post.

This pugin will allow to run single command on one or set of maven projects to build or deploy them instead of doing separate maven goals on each project. This will even work inside a single project as well as on root project containing sub-projects. The only [...]]]> maven-build-plugin-1.0.jar

Please use improved version of this plugin from this post.

This pugin will allow to run single command on one or set of maven projects to build or deploy them instead of doing separate maven goals on each project. This will even work inside a single project as well as on root project containing sub-projects.
The only requirement is to have “maven.multiproject.type” property defined in each project.

Generic plugin which provides build and deploy goals that can be customized to run list of maven goals across maven projects using maven:rector.
The plugin is using “maven.multiproject.type” property to determine project type in order to execute appropriate list of commands.
The plugin will append the value specified in “maven.multiproject.type” to “.build.commands” and “.deploy.commands” to get list of maven goals to run.
For example here is the list of default goals to be run when doing build on jar, ejb, war and ear:

jar.build.commands = clean,jar:jar,jar:install
ejb.build.commands = clean,ejb:ejb,ejb:install
war.build.commands = clean,war:war,war:install
ear.build.commands = clean,ear:ear,ear:install

The properties can be customized in project.properties to add/remove goals.

There are no deploy commands defined by default. The deploy goals are specific to the project and need to be defined in build.properties or project.properties.
For example it would make sense to have ear.deploy.commands = weblogic:undeploy,weblogic:deploy property ser in root project.properties.

• build - will execute ${maven.multiproject.type}.build.commands on
  each project under base directory. Will stop on first build failure.
• deploy - will execute ${maven.multiproject.type}.deploy.commands on
  each project under base directory. Wont stop on failure.
• build-deploy – will execute ${maven.multiproject.type}.deploy.commands and
  ${maven.multiproject.type}.deploy.commands on
  each project under base directory. Will only stop on first build failure,
  deploy failures will be ignored.