The Loop

If your using the scala-maven plugin and need to enable some of the cool extra functionality then check out these pom.xml snippets:

To enable launchers which let you do

mvn scala:run

use an XML snippet like:

<configuration>
  <scalaVersion>${scala.version}</scalaVersion>
  <args>
    <arg>-target:jvm-1.5</arg>
    <arg>-unchecked</arg>
   </args>
   <launchers>
     <launcher>
       <id>main-launcher</id>
       <mainClass>com.myproj.TheMainClass</mainClass>
       <args>
         <arg>/some/intial/argument</arg>
       </args>
     </launcher>
  </launchers>
</configuration>

Also note the “-unchecked” compiler argument… this will then prompt you if you have any deprection warnings and suggest how you could go about fixing them.

Any one who has ever implemented a SOAP consuming client service will appreciate that the tooling for various languages is a very welcome feather in SOAP’s cap. Without the WSDL tooling that web service developers are accustomed to, a large portion of those developers would probably struggle to use the said service as the sher verbosity of the SOAP entity payload is simply overwhelming.

REST: A idealist view of the web or serious technology?

When REST came onto the scene it appeared to be met with two very different view points. The open source communities and web purists rejoiced… a resource orientated architecture which allowed them to scrap there verbose SOAP and XML-RPC service flow. However, from what I saw first-hand, the reaction from enterprise was somewhat different; namely, one of “So now we have to implement clients by hand? Sod that!”.

For a number of developers, including myself, we could see that REST was a much better architectural style for distributed computing on the web, but with ever decreasing budgets and squeezed time scales the added overhead of creating totally bespoke services – and therefore clients – was one that proved somewhat of a bitter pill to swallow.

WADL: Here to save the day?

Recently, WADL is coming to the fore as a structured way for providing description and automated development workflow for using REST services. WADL is based around similar principles to WSDL in that it provides a contract of service between service resource and the client.

If WADL can provide a robust framework for automated tooling with REST, I really think that we’ll see REST pick up a second wind of uptake in the enterprise setting. With players like Yahoo! leading by example, how long will it be before others follow suit?

Only time will tell…

Check out this great open source mind mapping tool called FreeMind – I recently came accross it whilst reading this article about hibernate 2nd level caching.

A true testament to the power of OSS and the great software it can produce.

I recently thought that it would be good to run a Servlet container alongside IIS which is so well embedded in the clients that I deal with as they are mainly .NET types…

Anyone who has read my blog before will now that I have somewhat of a penchant for Resin – so once again, this was my choice of servlet container. Luckily for me, Caucho are awesome enough to supply an ISAPI filter which drops right into your IIS system, making Resin just an other ISAPI filter! Very sweet.

If you too would like to have some Java sweetness on your M$ box, then check out this walkthrough

I just came across a great Scala presentation from JavaOne. If your not looking at learning Scala, then this presentation will give you a whole heap of reasons to get up and do something about it.

Download the article from here

As a number of you are aware, I have spent quite a bit of time wrestling with XMPie uProduce SOAP API with the CXF service framework in Java. I finally (and with quite a lot of disappointment on my part) gave up trying to get that to work. CXF just does not want to play nice and I cant seem to make the XJB bindings work correctly with it and the mish-mash WSDL coming from uProduce

Anyway… with that rant over, I tried to be objective and switched to using Metro – ok, out of the box I still had a whole heap of problems, exactly as I did with CXF. However, I have managed to wangle it!

Step 1

You will need access to an XMPie server with the API’s installed and working. For the sake of this example i just wget’d the WSDL file so the generation code was not so bloated.

Step 2

You’ll need an XSD XJB binding file which looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<bindings xmlns="http://java.sun.com/xml/ns/jaxb" 
          xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
          xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc" 
          version="2.0">

  <globalBindings>
    <xjc:simple />
  </globalBindings>

  <bindings scd="~xsd:complexType">
    <class name="ComplexTypeType"/>
  </bindings>

  <bindings scd="~xsd:simpleType">
    <class name="SimpleTypeType"/>
  </bindings>

  <bindings scd="~xsd:group">
    <class name="GroupType"/>
  </bindings>

  <bindings scd="~xsd:attributeGroup">
    <class name="AttributeGroupType"/>
  </bindings>

  <bindings scd="~xsd:element">
    <class name="ElementType"/>
  </bindings>

  <bindings scd="~xsd:attribute">
    <class name="attributeType"/>
  </bindings>
</bindings>

Save this as xsd.xjb (or whatever you like, just make sure the name is reflected in the command below)

Step 3

Actually generate the code! Your command might look different, but heres mine:

  wsimport -b http://www.w3.org/2001/XMLSchema.xsd \
    -b src/xjb/xsd.xjb \
    -keep \
    -s src/java \
    -d target \
    -p com.xmpie.wsapi.icp \
    src/wsdl/InteractiveCampaign_SSP.wsdl

You should then see something like the following in your finder (or other OS file browser if not on mac):

These are the class files created for the InteractiveCampaign WSDL – all 128 of them!

Anyway, I have run out of time for today, but will try and get another blog up soon about how to use this in a client application from a java CLI.

Its been in the wings for some time now but the announcement has finally been made public. This is great news as it means that when were coding in Scala the classes in your web container will automatically be updated without the need to restart the container and redeploy the WAR.

For more on this check out the announcement

I recently read this article and realised that I had never blogged about the resin plugin that works perfectly with lift for development and deployment.

Heres what you need to add to your pom.xml

<build>
   ...
   <finalName>${project.name}</finalName>
   ...
    <!-- resin plugin -->
      <plugin>
        <groupId>com.caucho</groupId>
        <artifactId>resin-maven-plugin</artifactId>
        <version>3.1.6</version>
        <configuration>
          <contextPath>/</contextPath>
        </configuration>
      </plugin>
    ...
</build>

<pluginRepositories>
...
<pluginRepository>
  <id>caucho</id>
  <name>Caucho</name>
  <url>http://caucho.com/m2</url>
</pluginRepository>
...
</pluginRepositories>

Note, the final name var is important, as thats what resin uses to point at. Dont worry tho, as lift already has a name element so provided you haven’t deleted it, your laughing.

Next, to boot the server, just do:

mvn resin:run

That should be it! Enjoy!

Right, as you know, I use the lift framework a lot these days. I also use Resin as my choice container. So, i recently got to thinking, wouldn’t it be cool if i could just bosh together a simple way to expose controllers in lift via the groovy protocols made available by Resin – well, I have here an example of just such a thing.

Lift Side

Ok, before anyone has a poke at this code… it was a very quick and dirty example, so its not ideal, and obviously your code would be a whole lot more complex, but this article is just about proving concept.

I set up the object that I want to expose via remoting. Critically, there would be nothing stopping me using the persistance built into lift, or anything else available to java or scala for that matter. The key is the traits… as they are like java interfaces (broadly speaking), they let resin know what methods it can call.

package com.timperrett.resin.example.controller

trait HelloTrait {
  def hello: String
}
class HelloWorld extends Object with HelloTrait {
  def hello = "Hello from lift" 
}

Resin Configuration

Next, we add a bit of config to resin so that it knows how/where to expose the service. Critically, we could have used Hessian, Burlap or CXF (for SOAP) and all by being pushed out of the container with zero extra effort.

<web-app id="/lift-remoting-example" 
   root-directory="webapps/lift-remoting-example">
  <servlet-mapping 
   url-pattern="/api/hello-world" 
   servlet-class="com.timperrett.resin.example.controller.HelloWorld">
    <protocol uri="hessian:"/>
  </servlet-mapping>
</web-app>

Client Side (in another language!)

To proove the point, I thought I would just make a simple client in another language (namely ruby):

require 'rubygems'
require 'hessian'

url = http://127.0.0.1:8080/lift-remoting-example/api/hello-world
client = Hessian::HessianClient.new(url)
puts client.hello

Again, a very simple example, but one that proves the point. You should then see “Hello from lift” output in the terminal window.

Project Files

You can download my example from here

If you found this article interesting, or have played with this yourself also, then by all means leave a comment or get in touch.

My appologies; I hardly ever blow my own trumpet on this blog, but I just cant let this one pass without a good old toot of the proverbial horn.

Today I joined the lift committers. That might not sound much, but when you think that lift will be the next Ruby on Rails size phenomenon to hit the development community, thats pretty dang awesome.

I shall toot no more – respect to David and the rest of the other guys on lift core… you freaking rock!