Andrej Koelewijn

I did a small proof of concept yesterday: a wicket web application using embedded Mule to connect to some services. Problem is that it had to run on OC4J 10.1.3.4.0 with Java 5. Got it running pretty fast, some tips:

• Oracle’s xml parser didn’t like some of Mule’s xsd files. You can solve this by including the Xerxes xml parser in the web application, and making sure that local classes are loaded first: The maven dependency required:

          <dependency>
            <groupId>xerces</groupId>
            <artifactId>xercesImpl</artifactId>
            <version>2.9.1</version>        
          </dependency>
  

  The orion-web.xml file required to load local classes first, so the oracle xml parser isn’t used:

  <?xml version="1.0" encoding="ISO-8859-1"?>
  <orion-web-app directory-browsing="allow">
    <web-app-class-loader search-local-classes-first="true"
     include-war-manifest-class-path="true" />
  </orion-web-app>
  

• OC4J has some problems displaying wicket pages if you use the wicket filter as follows in your web.xml:

  <filter>
    <filter-name>wicket.ZmWeb</filter-name>
    <filter-class>org.apache.wicket.protocol.http.WicketFilter</filter-class>
    <init-param>
      <param-name>applicationClassName</param-name>
      <param-value>nl.iteye.poc.WicketApplication</param-value>
    </init-param>
  </filter>
  <filter-mapping>
    <filter-name>wicket.ZmWeb</filter-name>
    <url-pattern>/*</url-pattern>
  </filter-mapping>
  

  If you run it like this OC4J will complain that directory browsing isn’t allowed. Just adding a simple html file in your web folder solves the issue, for example src/main/webapp/index.html if you’re using the default maven project layout.

Having mule embedded in your web application makes using services really easy. From your java code you just call a mule service with a vm transport, and from there you can call web services with a http connector for example. I did the XOM (Xml Object Mapping) using a bit of groovy scripting in a response transformer using the XML slurper. The result is that there’s no need for code generation based on wsdls, and you can put integration patterns into your mule configuration. No need to have a separate deploy to a standalone ESB server.