I was thinking a long time about doing this. Writing an opinion about runtime agains checked exceptions. I decided to do it, just to form my own opinion and start doing it consistent. Please do not start the debate here, it is just my opinion. I will point you to a number of resources that can help you form you own opinion.

The reason to introduce Checked Exceptions in java is to assure that people do something with exceptions. This is made sure by the compiler. However there are a lot of side effects to this theory. Bruce Eckel has a very good entry on his blog, I quote one of his sentences that sais it all:
When someone is trying to do something and you are constantly praddin them with annoyances, they will use the quickest device available to make those annoyances go away.
One of the anti patterns is born: catch (Exception e), swallowed exceptions.

A disadvantage of Checked Exceptions is all the code you must write or rethrowing exceptions. This way you throw exceptions in layers that do not belong there or you catch exceptions and throw a new other exception. And a new anti-pattern is born. Runtime exceptions just go up untill the main thread, or you can catch them if you can can do something about it. The important part, if you do nothing you will get an exception at the top, you are not tempted to do the catch Exception part.

The blog item of Tim McCune is also a very good article about exception handling. This article states a number of anti-patterns that you will find in your code. You do not have to agree on all the items, but you can learn a lot of them. Some rules of this website that I agree upon are:

• Either log an exception or rethrow it.
• Never throw java.lang.Exception
• Never add multiple exceptions to throws that propably are handed the same, use a super class instead
• Never throw an exception from a finally block

I also have some ideas of myself, I adhere to the following rules:

• Add important runtime exceptions to the throws clause of your method. Instead of this you can also document them in your javadoc. It is important to let the users of your class/interface know what kind of exceptions they can expect
• Use a good logging framework, agree upon the levels to use and make sure to log the exception if you catch one.
• From java 1.4 there are nested exceptions, use these if you want to wrap a checked exception in a runtime exception. You can also use a special wrapper. There is one in apache commons-lang. The utility class to use from this package is:http://jakarta.apache.org/commons/lang/api-release/org/apache/commons/lang/exception/ExceptionUtils.html

Of course this is not a very extensive post, but it does give an idea about how I feel about checked exceptions.

I have created a lot of small applications that include spring and acegi. Most of the time I copy most of the resources from another project. Some time ago I learned about the maven archetypes. An easy way to create the project structure. That was the time I decided that I wanted to have my acegi springframework archetype. Last weeks I found some time to create this archetype. You can download the files here:
http://code.google.com/p/gridshore/
And the generated maven site here:
http://www.gridshore.nl/projects/springframeworkarchetype/index.html
Ofcourse there is also a maven website about creating an archetype, this is not a very extensive website. In this blog item I will explain more about the archetype I created.

First thing to know, well surprise, the archetype is just a maven project. You can start you new archetype by using a maven archetype:
mvn archetype:create
-DgroupId=nl.gridshore.samples.archetype
-DartifactId=SpringframeworkArchetype
-DarchetypeArtifactId=maven-archetype-quickstart
Have a look at the pom for the other properties; scm, distributionManagement, etc.

The project itself contains an src\main\resources\META-INF\maven\archetype.xml file that defines all the resources that need to be copied.

<archetype>

  <id>SpringframeworkArchetype</id>

  <sources>

    <source>src/main/java/App.java</source>

  </sources>

  <testSources>

    <source>src/test/java/AppTest.java</source>

  </testSources>

  <resources>

      <resource>src/main/webapp/index.jsp</resource>

      <resource>src/main/webapp/WEB-INF/web.xml</resource>

      <resource>src/main/webapp/WEB-INF/action-servlet.xml</resource>

      <resource>src/main/webapp/WEB-INF/jsps/welcome.jsp</resource>

      <resource>src/main/webapp/WEB-INF/jsps/adminwelcome.jsp</resource>

      <resource>src/main/webapp/WEB-INF/jsps/accessdenied.jsp</resource>

      <resource>src/main/webapp/WEB-INF/jsps/login.jsp</resource>

      <resource>src/main/webapp/WEB-INF/jsps/loginerror.jsp</resource>

      <resource>src/main/resources/security-springConfig.xml</resource>

      <resource>src/main/resources/views.properties</resource>

      <resource>src/main/resources/errormessages.properties</resource>

      <resource>src/main/resources/sitetext.properties</resource>

      <resource>src/main/resources/log4j.dtd</resource>

      <resource>src/main/resources/log4j.xml</resource>

  </resources>

</archetype>

The structure is pretty easy, you can find all the resources under the directory:
src\main\resources\archetype-resources

You can use the following parameters in your file as placeholders:
http://maven.apache.org/plugins/maven-archetype-plugin/create-mojo.html. Have a look at the src\main\resources\archetype-resources\pom.xml for an example:

  <groupId>$groupId</groupId>

  <artifactId>$artifactId</artifactId>

  <version>$version</version>

Hope that helps you on your way to your own archetype. If you just want to use mine:

mvn install

mvn archetype:create

	-DgroupId=your.groupid

	-DartifactId=your.artifactId

	-DarchetypeArtifactId=SpringframeworkArchetype

	-DarchetypeGroupId=nl.gridshore.samples.archetype

	-DarchetypeVersion=1.0.0-SNAPSHOT

There is a lot of talk around the web about autocomplete with ajax. I have blogged about a solution with ajaxtags and spring before (link). It is a nice solutions that works pretty well. Still I did not feel right to have to do a lot of configuration within spring and do something special in your normal code. I also had a look at dwr. This is a nice library that lets you expose a serverside service to your javascript. A number of javascript libraries are generated runtime, you can use these libraries from your scripts within the browser. There is a nice integration with script.aculo.us. Now you can use a lot of components out of the box. Next step, use the script.aculo.us autocomplete component with dwr. Well that is easy said. There are some blog items on the web that tell you how to do this. The best way is to have a look at some sample code Bram smeets made on his blog. I used his code to create a sample that uses maven to build and package. I also used the callisto ide, works very good as well. I would not try the maven plugin yet, I did but it fails for now.

After this rather long introduction, time to get the coding done.
Step1
Get your environment in place. Run the maven archetype command to create a webproject template. Alter some of the default values to make it your project and put in dependencies on the following libraries to your pom.xml file:
spring-webmvc-1.2.7 (org.springframework)
dwr-1.1.1 (uk.ltd.getahead)
Execute the command to setup your eclipse environment and startup eclipse.

commands:

mvn archetype:create -DgroupId=nl.gridshore.ajaxdwrsample -DartifactId=ajaxdwrsample -DarchetypeArtifactId=maven-archetype-webapp

mvn -Dwtpversion=1.0 eclipse:eclipse

Step 2
Time to explain a little bid what the application is going to do. Actually there is two phases in the application. First search for a known postalcode. If you have found the right one and pushed the search button, the accompanying address is obtained. Sounds easy doesn't it?
We are going to expose a service object with two methods:

public interface RemoteAddressService {

  public AddressTO findAddressByPostalCode(String postalCode);

  public List findCompletePostalCodes(String partPostalCode);

}

It should be obvious what the implementation of this interface should do. To be able to do an easy test, I created a mock implementation for this interface. The mock contains a hashtable with some postal codes as a key and the belonging address as the value. The two methods mentioned before use this hashmap to return all postalcodes or the address for a specific postal code.

public class MockRemoteAddressServiceImpl implements RemoteAddressService  {

  private Map addressByPostalCode = new HashMap();

  public void init() {

    ...

    addressByPostalCode.put("1234AA", new AddressTO("streetone","1","cityone","1234AA"));

    ...

  }

  public AddressTO findAddressByPostalCode(final String postalCode) {

    return (AddressTO)addressByPostalCode.get(postalCode);

  }

  public List findCompletePostalCodes(final String partPostalCode) {

    Set keys = addressByPostalCode.keySet();

    List retKeys = new ArrayList();

    for (Iterator iter = keys.iterator();iter.hasNext();) {

      String key = (String)iter.next();

      retKeys.add(key);

    }

    return retKeys;

  }

}

Fianlly there is a transferobject called AddressTO that contains the following 4 fields: streetname, houseNumber, city, postalCode. Download the source to have a look.
We have created the interface and an implementation. Time to do some spring configuration. We only need to create one bean, therefore the config file is very easy

<beans>

  <bean id="addressServiceFacade"

    class="nl.gridshore.ajaxdwrsample.service.impl.MockRemoteAddressServiceImpl"

    init-method="init"/>

</beans>

Step 3
After this everything is in place to configure dwr to expose the spring bean. To be able to use dwr, we first need to add the dwr servlet to the web.xml file and load the spring context:

<context-param>

  <param-name>contextConfigLocation</param-name>

  <param-value>/WEB-INF/applicationContext.xml</param-value>

</context-param>

<listener>

  <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>

</listener>

<servlet>

  <servlet-name>dwr</servlet-name>

  <servlet-class>uk.ltd.getahead.dwr.DWRServlet</servlet-class>

  <init-param>

    <param-name>debug</param-name>

    <param-value>true</param-value>

  </init-param>

</servlet>

<servlet-mapping>

  <servlet-name>dwr</servlet-name>

  <url-pattern>/dwr/*</url-pattern>

</servlet-mapping>

Dwr uses a configuration file to configure the beans that are exposed to your javascripts. This file is next to web.xml and is called dwr.xml.

<dwr>

  <allow>

    <create creator="spring" javascript="AddressServiceFacade">

      <param name="beanName" value="addressServiceFacade"/>

    </create>

    <convert converter="bean" match="nl.gridshore.ajaxdwrsample.to.AddressTO"/>

  </allow>

</dwr>

By default you allow all methods to be called, you should allow only the real ajax usable methods. The create element is like the constructor, I tell dwr to use spring to create the javascript object AddressServiceFacade based on the spring bean addressServiceFacade. Because a use a transfer object for the address I also need the converter.
Everything is ready to do the first test. Deploy the application to tomcat and call the following url: http://localhost:8080/ajaxdwrsample/drw
You should get a page with a link to AddressServiceFacade, click this link and have a look at the next page:

On this screen you can test your dwr ajax service. Use the execute buttons and input boxes to test the services (see the red box). Great isn't it?
Step 4
And now for the webpages. First add the script libraries to your war file. I added the Prototype script and the script.aculo.us. to the folder "scripts". Next to that I added to style sheets (I copied all these files from the sample by Bram Smeets). Out of the box there is no support in script.aculo.us for autocomplete via dwr. Therefore I used the excellent component from Bram to implement it. The component resides in the "autocomplete.js" file. Finally the index.jsp that implements the real automcomplete component.
The includes:

<link rel="stylesheet" type="text/css" href="/ajaxdwrsample/styles/autocomplete.css"/>

<script type='text/javascript' src='/ajaxdwrsample/dwr/interface/AddressServiceFacade.js'></script>

<script type='text/javascript' src='/ajaxdwrsample/dwr/engine.js'></script>

<script type='text/javascript' src='/ajaxdwrsample/dwr/util.js'></script>

<script type="text/javascript" src="/ajaxdwrsample/scripts/prototype/prototype.js"></script>

<script type="text/javascript" src="/ajaxdwrsample/scripts/script.aculo.us/effects.js"></script>

<script type="text/javascript" src="/ajaxdwrsample/scripts/script.aculo.us/controls.js"></script>

<script type="text/javascript" src="/ajaxdwrsample/scripts/autocomplete.js"></script>

Important in the includes is the AddressServiceFacade, this is the generated script file by dwr based on the dwr.xml file. There we configured this name ... javascript="AddressServiceFacade" .... Now the standard scripts are in place, do the html thing:

<input id="searchPostalCode" type="text" />

<input type="button" value="Search" onclick="handleAddClick();"/>

<div id="postalCodeList" class="auto_complete"></div>

<script type="text/javascript">

   new Autocompleter.DWR('searchPostalCode', 'postalCodeList', updateList,{ valueSelector: nameValueSelector, partialChars: 0 });

</script>

The constructor for the autocomplete component has 4 parameters:

1. searchPostalCode - Field to obtain the string from that has to autocompleted


2. postalCodeList - Id of the div that will be filled with the found autocomplete items


3. updateList - name of the script to use as callback function by the autocomplete script


4. Options to pass to the autocomplete script

The callback function looks like this:

function updateList(autocompleter, token) {

   AddressServiceFacade.findCompletePostalCodes(token, function(data) {   

      autocompleter.setChoices(data) 

   });

}

function nameValueSelector(tag){

   return tag;

}

Doesn't look very difficult, does it? Beware of the function nameValueSelector, it receives a tag object. This can be a simple object (like in my case, a string). It can also be a javabean representation, then you need an extra method to obtain the property to show in the autocomplete box. If you return a list with AddressTO objects and want to show the postalCode of the address, this line would be : return tag.postalCode.
The autocomplete box will now look like the following image:

Your autocomplete is done, there is one extra thing in the sample. You can select the postal code and look for the belonging address. That is done the with the following piece of html and javascript.

<span id="streetname"></span> <span id="houseNumber"></span><br/>

<span id="postalCode"></span><br/>

<span id="city"></span><br/>

The id's of the span elements resemble the fields of the AddressTO javabean. With the help of the dwr utility package we can easily fill these spans with data obtain via dwr. This is done with the following to functions.

function handleAddClick() {

   var searchString = DWRUtil.getValue('searchPostalCode');

   AddressServiceFacade.findAddressByPostalCode(fillAddress,searchString);

}

function fillAddress(anAddress) {

   formAddress = anAddress;

   DWRUtil.setValues(anAddress);

}

The handleAddClick button receives the onClick event from the search button. First we obtain the value from the input field, then we call the dwr javascript object. This method obtains 2 parameters, one more than the real method. The extra parameter is the callback function. This function gets called with the return value of the original java function. We configured the fillAddress function to be the callback function. The special util function "DWRUtil.setValues" sets the values of the address to the spans. The end result looks like this:


Download the sources here : ajaxdwrsample.zip

That's it, hope you like this article. Thanks again to Bram Smeets for his autocomplete component and of course the excellent dwr and script.aculo.us frameworks.

This is not the first luntbuild article on this website. I have been working with luntbuild for a while. Still it was only recently I found out the possibility to extend luntbuild. It struc me how easy it is. This article is about the luntbuild exntesion. You can combine it with the cobertura-luntbuild article to fill in the missing link in that article.

First some luntbuild theory, how to extend the ognl possibilities? Create a bean, put it in a jar and add a properties file named luntbuild_extension.properties to this jar with the following contents:

luntbuild.extension.name=CoberturaIntegration

luntbuild.extension.class=com.gridshore.luntbuild.addon.CoberturaIntegration

The bean is just a plain javabean with some public methods. You can create a method that checks if the report directory is available and another method that points to the page to start if you want to have a llok at the reports. This would look like the following:

  private final String coberturaReportDir = "cobertura_report_dir";

  public String getCoberturaReportDir(String publishDir) {

    return publishDir + "\\\\" + coberturaReportDir;

  }

  public String getCoberturaReportDir() {

    return coberturaReportDir;

  }

  public String getCoberturaSite(String publishDir) {

    File pathToFile = (new File(getCoberturaReportDir(publishDir)+ File.separator + "index.html"));

    if(pathToFile.exists()) {

      return coberturaReportDir + "/index.html";

    } else {

      return null;

    }

  }

These methods can be called from luntbuild. There are two important locations where the ognl expressions are used:

• The build configuration within luntbuild when a project is created.


• The tapestry view files

Lets start with the ant configuration within Luntbuild:

Pay attention to the coberturaHtmlReportDir here you can see how to pass output from the added bean to ant. From the context you can reach the class 'com.luntsys.luntbuild.web.BuildViewer'. This class has a method getBuild, this class returns a 'com.luntsys.luntbuild.db.Build'. From there there is the method getSystem, this returns the OgnlHelper object. This object has a method getExtension that takes the name of our object CoberturaIntegration as a parameter. Now you can call the methods of your own bean which are called via reflection. Now ant knows where to copy the report files to.
The reports are copied to the right place. Now we want to create a link in the build view if the reports are available. Let us have a look at the tapestry code.

  <span jwcid="@Conditional" condition="ognl:build.system.getExtension('CoberturaIntegration').getCoberturaSite(build.publishDir)!=null">

  <span jwcid="@GenericLink" 

    href="ognl:'publish/'+build.schedule.project.name+'/'+build.schedule.name+'/'

      +build.version+ '/'+build.system.getExtension('CoberturaIntegration').

      getCoberturaSite(build.publishDir)" title="cobetura reports">cobertura report</span>

</span>

With the previous explanation you should be able to understand this code. Find the junit link and put it right in front of it. Thats it. Now you should be able to create your own screen like the following.


Finally you are done, cool stuff !

Finally I found some time to start experimenting with a webservice. I know I am not the first to write about creating your own webservice, still I think this is worth reading. I am writing a step by step creation of a webservice via maven2, axis 1.4 and spring 2.0RC1. Ofcourse you can use older versions, but I want to be ready for the future and keep on using this sample. For now I am working with a HelloWorld sample. I will make it more complicated when needed to show interesting things.

Download the sources here

Step 1 - Configuring your maven project environment
We create a new directory to store all projects : ~/WebservicePoc
Within this directory use the archetype of maven to create a structure for a web project:
The groupid is used within the create pom. The artifactId is used as project id and to create the folder to store all files in. The archetypeArtifactId defines the type of structure to create, in our case a web project.

mvn archetype:create 

          -DgroupId=com.coenradie.webservicespoc 

          -DartifactId=webservice-jaxrpc-style 

          -DarchetypeArtifactId=maven-archetype-webapp

Now it is time to create the pom in the root project directory. Beware if you create this pom first, the archetype:create won't work. Execute the command in a temporary directory and copy the files into the sub-directory of the module we are creating.

...

	<groupId>com.coenradie.webservicespoc</groupId>

	<version>1.0-SNAPSHOT</version>

	<artifactId>WebservicePoc</artifactId>

	<packaging>pom</packaging>

	<name>Webservice proof of concept</name>

	<inceptionYear>2006</inceptionYear>

	<url>http://localhost:8080/webservicepoc</url>

...

	<modules>

		<module>webservice-jaxrpc-style</module>

	</modules>

...

For a complete look at the pom, have a look at the downloadable source code.

We also need to make some adjustments to the generated pom of the webservice-jaxrpc-style module. Again have a look at the sources. Time to try the first compile. Execute the following command in the root of the project:

~/WebservicePoc/mvn install

Step 2 - Decide upon the libraries that we are going to use
For the application we are going to create we are going to use some libraries. We do not want to code ourselves to much. We are going to use the spring library and axis. Add these to the module pom.

  <dependencies>

    <dependency>

      <groupId>org.springframework</groupId>

      <artifactId>spring</artifactId>

      <version>2.0-RC1</version>

    </dependency>

    <dependency>

      <groupId>axis</groupId>

      <artifactId>axis</artifactId>

      <version>1.4</version>

    </dependency>

    <dependency>

      <groupId>axis</groupId>

      <artifactId>axis-jaxrpc</artifactId>

      <version>1.4</version>

    </dependency>

You will notice a problem with spring and maven 2 at the moment of writing. Maven provides the solution in the error message, we need to install the maven library manually. There aresome other options, but for now this is the easiest one. First download spring version 2.0 RC1, than issue the following command:

mvn install:install-file 

          -DgroupId=org.springframework 

          -DartifactId=spring 

          -Dversion=2.0-RC1 

          -Dpackaging=jar

          -Dfile=%PATH_TO_JAR%/spring.jar

Step 3 - Time to get the eclipse wtp to work
I want to deploy the webservice via tomcat and ofcourse I want a nice environment for debugging, deploying, and developing. I like to work with spring WebTools project, there is a pretty good integration with maven from the maven perspective. Lets use that. Fire up your eclipse (with wtp) and create a workspace. Do not create this workspace inside our projects, do it on another part of the disk. After creating this workspace, add the maven repository as a variable by using the following command:

mvn eclipse:add-maven-repo -Declipse.workspace=%PATH_TO_WORKSPACE%/WebservicePoc

Now let maven generate the eclipse project and classpath files, issue the following command:

mvn -Dwtpversion=1.0 eclipse:eclipse

You are ready to import the project into eclipse, "File > Import > Existing projects into workspace"

step 4 - Lets publish a webservice
The webservice is deployed within a web container. Both axis and the spring container run in a servlet. There is a connection between the two via the servlet endpoint which will be discussed in a while. These servlets are configured in the web.xml file. The template for the file is generated by maven, lets add the servlets, servlet mappings and a spring specific parameter.

	<context-param>

		<param-name>contextConfigLocation</param-name>

		<param-value>

			classpath:/applicationContext.xml

		</param-value>

	</context-param>

This parameter specifies the locations where spring can find the configuration files for the container. The applicationContext.xml contains the definition of the beans in the Business service domain. There is another configuration file for spring thats needs to be present. This is the default spring config file based on the name of the servlet that configures the spring container. In our case this file does not contain any beans, but it must be available. It must be called action-servlet.xml since we have given the spring dispatcher servlet the name action. The file should reside next to the web.xml in the WEB-INF folder.

	<servlet>

		<servlet-name>action</servlet-name>

		<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>

		<load-on-startup>1</load-on-startup>

	</servlet>



	<servlet>

		<servlet-name>axis</servlet-name>

		<servlet-class>org.apache.axis.transport.http.AxisServlet</servlet-class>

		<load-on-startup>2</load-on-startup>

	</servlet>



    <servlet-mapping>

        <servlet-name>action</servlet-name>

        <url-pattern>*.html</url-pattern>

    </servlet-mapping>



	<servlet-mapping>

		<servlet-name>axis</servlet-name>

		<url-pattern>/services/*</url-pattern>

	</servlet-mapping>

Here you can see the spring dispatcher servlet and the axis servlet. Most important to notice is the load-on-startup parameter that tells the order of loading the servlets. The axis servlet connects to the loaded spring context via the special endpoint. Therefore the spring servlet needs to be loaded first. You do not need the dispatcher servlet if you plan to expose only webservices. If you also want to include spring mvc or the like, you do need the dispatcher servlet.

Next task is to configure the axis webservice, this is done via the server-config.wsdd file.

	<service name="JaxrpcwebserviceProvider" provider="java:RPC">

		<parameter name="className"

			value="com.coenradie.webservicepoc.server.jaxrpcstyle.ServiceProvider"/>

		<parameter name="allowedMethods" value="*"/>

		<beanMapping qname="webservicepoc:MessageBean" xmlns:webservicepoc="urn:MessageBean" 

			languageSpecificType="java:com.coenradie.webservicepoc.server.jaxrpcstyle.MessageBean"/>

	</service>

We are creating a jaxrpc style webservice with the name JaxrpcwebserviceProvider. Axis should redirect all calls to this service to the endpoint of type ServiceProvider. This is a subclass of a special spring implementation of the servletendpoint, this class is will be discussed later on. As you can see from the wsdd file, all public methods are exposed via the webservice. As a transport object we use the MessageBean.

Now all configuration is in place, time to do some real coding. We need to implement the following classes and interfaces.
MessageService and MessageServiceImpl - Business service interface and implementation
MessageBean - Object returned via the jaxrpc webservice
RemoteMessageService - Remote interface that is implemented by the service endpoint and therefore implemented by the webservice.
ServiceProvider - the special webservice endpoint that contains access to the laoded spring context. The endpoint contains the method that is called via axis.

public interface MessageService {

	String getMessage();

}



public class MessageServiceImpl implements MessageService {

	public String getMessage() {

		return "Message from my server";

	}

}



public interface RemoteMessageService extends Remote {

	public MessageBean getMessage() throws RemoteException;

}



public class MessageBean implements Serializable {

	private static final long serialVersionUID = -7014683074252469915L;

	private String message;

	private String createDate;

	

	public String getCreateDate() {

		return createDate;

	}

	public void setCreateDate(String createDate) {

		this.createDate = createDate;

	}

	public String getMessage() {

		return message;

	}

	public void setMessage(String message) {

		this.message = message;

	}

}

The most important class is the endpoint, this is the class that gets called by axis. The spring superclass takes care of obtaining the spring web context. You can use this context to find spring wired beans. In our case we use it to find the Business service object MessageService.

public class ServiceProvider extends ServletEndpointSupport implements RemoteMessageService {

	private MessageService messageService;

	

	protected void onInit() {

		this.messageService = (MessageService)getWebApplicationContext().getBean("messageService");

	}

	

	public MessageBean getMessage() {

		MessageBean messageBean = new MessageBean();

		messageBean.setMessage(messageService.getMessage());

		messageBean.setCreateDate(new Date().toString());

		

		return messageBean;

	}

}

Time to fire up the server. You can use the run on server with a right mouse click on the project within eclipse wtp. Popup a browser and go to the following url:
http://localhost:8080/webservice-jaxrpc-style/services
That should give you an overview of all deployed services, probably only the JaxrpcwebserviceProvider.

Step 5 - Using xml spy to send a message via soap to the webservice
The webservice is deployed, you can have a look at the wsdl file, nice. Now we want to call the webservice. We can write a special java client. There is however an easier way with xmlspy. Since this blog item is all about exposing the webservice and not about creating a client, I will use xmlspy.

Fire up xmlspy and use the menu: SOAP > Create new soap request and enter the next url in the pop-up box:
http://localhost:8080/webservice-jaxrpc-style/services/JaxrpcwebserviceProvider?wsdl
After clicking oke, choose the getMessage() operating name, the following request is generated:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

	<SOAP-ENV:Body>

		<m:getMessage xmlns:m="http://jaxrpcstyle.server.webservicepoc.coenradie.com" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>

	</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Then we can send the request over soap via xmlspy: SOAP > Send request to server

<?xml version="1.0" encoding="UTF-8"?>

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

	<soapenv:Body>

		<ns1:getMessageResponse soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns1="http://jaxrpcstyle.server.webservicepoc.coenradie.com">

			<getMessageReturn href="#id0"/>

		</ns1:getMessageResponse>

		<multiRef id="id0" soapenc:root="0" soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="ns2:MessageBean" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns2="urn:MessageBean">

			<createDate xsi:type="soapenc:string">Mon Jun 26 09:48:31 CEST 2006</createDate>

			<message xsi:type="soapenc:string">Message from my server</message>

		</multiRef>

	</soapenv:Body>

</soapenv:Envelope>

That concludes this article, I learned a lot while writing this item, hope you learned something while reading. The coming weeks I want to write about creating a client, doing document style webservices, using spring webservices component and security. Stay tuned.

After playing around with continuum I am back on my luntbuild feet. I really tried continuum, good community by the way, but the maven site integration is not really possible. That is at least a little bit strange. The same is valid for labelling builds. Why this introduction for a luntbuild maven story, well, with luntbuild it is possible. Maybe not perfect but possible.

Let me explain, luntbuild does have maven 2 integration, I wanted to be able to copy the results of the site target to the luntbuild artifacts directory. This is not possible out of the box. But with a small experiment I created a maven mojo that does the trick. First disadvantage, you need to provide an extra part to the pom that is only needed for copying the site. I do want to do some more research whether this was really necessary, but for now it works.

So what is in this blog item? I will give you some details on creating a plugin for maven. Then Ill present you with the configuration of luntbuild to pass parameters to maven by using environment variables. In the end just a screenshot with the artifacts of the different maven projects.

Creating the maven plugin, or mojo

There is a guide available on the maven website. Read this first, then come back for the step by step approach.

Use the appropriate archetype to create the project with maven:

mvn archetype:create 

       -DgroupId=nl.gridshore.maven.plugin 

       -DartifactId=maven-copy-site-plugin 

       -DarchetypeArtifactId=maven-archetype-mojo

Compile the project, create the eclipse project space and start up eclipse

mvn package eclipse:eclipse

An example for a plugin is allready available in the generated project. We will create our own by subclassing the AbstractPlugin class. I do not want to teach java specifics in this blog item. Therefore just the code:

package nl.gridshore.maven.plugin;



import java.io.File;



import org.apache.maven.plugin.AbstractMojo;

import org.apache.maven.plugin.MojoExecutionException;

import org.apache.maven.plugin.MojoFailureException;



/**

  @author Jettro.Coenradie

  

  @goal copydirectory

  

  @description Copies the provided directory to the other provided directory 

 /

public class CopyFolderMojo extends AbstractMojo {



    /**

      Location of the directory to copy from.

      @parameter expression="${project.build.directory}"

      @required

     /

    private File inputDirectory;

	

    /**

      Location of the directory to copy to.

      @parameter expression=""

      @required

     /

    private File outputDirectory;

    

    /**

      Name of the current project

      @parameter expression="${project.name}"

      @required

     /

    private String projectName;

    

    public void execute() throws MojoExecutionException, MojoFailureException {

	getLog().info("Input directory : "+inputDirectory.toString()+"\\site");

	getLog().info("Output directory : "+outputDirectory.toString());

	File in = new File(inputDirectory,"site");

	if (!in.exists()) {

		getLog().info("No site available to be copied");

		return;

	}

	File out = new File(outputDirectory,projectName);

	if (!out.exists()) {

		out.mkdirs();

	}

	in.renameTo(new File(out,in.getName()));

    }

}

If you have read the guide I mentioned, you now the javadoc attributes are important. These are used to set the parameter values and the name of the goal that is created.

Having done that, we can package and install the new goal and test it.

mvn nl.gridshore.maven.plugin:maven-copy-site-plugin:1.0-SNAPSHOT:copydirectory

You probalby get an error message, that is because you are missing a part in the pom. You need to define the outputDirectory for the move goal.

	<build>

		<plugins>

		  	<plugin>

			  <groupId>nl.gridshore.maven.plugin</groupId>

			  <artifactId>maven-copy-site-plugin</artifactId>

			  <configuration>

			    <outputDirectory>temp</outputDirectory>

			  </configuration>

			</plugin>            

  		</plugins>

	</build>

Running the command again should result into the following:

[INFO] ----------------------------------------------------------------------------

[INFO] [copy-site:copydirectory]

[INFO] Input directory : D:\sources\java\mavenplugincopysite\copy-site\target\site

[INFO] Output directory : D:\sources\java\mavenplugincopysite\copy-site\temp

[INFO] No site available to be copied

[INFO] ----------------------------------------------------------------------------

[INFO] BUILD SUCCESSFUL

Actually that is all there is to it. In order to shorten the amount of typing needed on the command line, you will need to add your plugin's group ID to the list of group IDs searched by default. To do this, you need to add the following to your settings.xml file:

<pluginGroups>

  <pluginGroup>nl.gridshore.maven.plugin</pluginGroup>

</pluginGroups>

Now you can run the following command and the result should be the same.

mvn copy-site:copydirectory

Integrating maven 2 with luntbuild

There a re two important screens in luntbuild with respect to maven:



Finally you have to prepare you pom(s):

    ....

	<version>${buildVersion}</version>

    ....

    <plugin>

        <groupId>nl.gridshore.maven.plugin</groupId>

        <artifactId>maven-copy-site-plugin</artifactId>

        <configuration>

            <outputDirectory>${artifactsDir}</outputDirectory>

        </configuration>

    </plugin>            

If you are having problems, the sample is available at:
http://svn.javaforge.com/svn/Equinox_Student_Registration_Sample/trunk/registrations

Beware that browsing source code from the javaforge website does not work very well, it does not refresh.

Hope this helps, please drop me a comment if it does help or if you are heving problems.

Today I was experimenting with maven. I wanted to add code coverage. Ofcourse I start thinking about cobertura immediately. So I dived into cobertura and maven integration. It became kind of an experience. I know a lot more about maven now. I have to figure out some stuff, but for now it is good enough. This entry gives some steps to help you get up to speed with cobertura.

1. Install maven 2
quick start guide maven
2. Create an application that knows how to handle the goals package and site.
see the quick start guide
3. The fun part begins : compile and install your own cobertura plugin.
Download the sources from the codehaus subversion repository. You can use the following url to download them anonymously with a tool like tortoisesvn
https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/cobertura-maven-plugin
Then you have the sources. Now you need to alter the pom of that project to be able to check for latest versions. See the guide on the plugins website.

<repositories>

  <repository>

    <id>Maven Snapshots</id>

    <url>http://snapshots.maven.codehaus.org/maven2/</url>

    <snapshots>

      <enabled>true</enabled>

    </snapshots>

    <releases>

      <enabled>false</enabled>

    </releases>

  </repository>

</repositories>

<pluginRepositories>

  <pluginRepository>

    <id>Maven Snapshots</id>

    <url>http://snapshots.maven.codehaus.org/maven2/</url>

    <snapshots>

      <enabled>true</enabled>

    </snapshots>

    <releases>

      <enabled>false</enabled>

    </releases>

  </pluginRepository>

</pluginRepositories>

Issue the following command for the cobertura-maven-plugin project you have just downloaded and altered.

mvn install

Now you are ready for the next step

4. Configure the pom.xml of your project to create the cobertura report.
There are two aspects, first you need to add the plugin to the build part, then to the reports part. See the usage page of the plugin home page

<build>

  <plugins>

    <plugin>

      <groupId>org.codehaus.mojo</groupId>

      <artifactId>cobertura-maven-plugin</artifactId>

      <executions>

        <execution>

          <goals>

            <goal>clean</goal>

          </goals>

        </execution>

      </executions>

    </plugin>  	

  </plugins>

</build>

<reporting>

  <plugins>

    <plugin>

      <groupId>org.codehaus.mojo</groupId>

      <artifactId>cobertura-maven-plugin</artifactId>

    </plugin>

  </plugins>

</reporting>

5. Run the site goal and start browsing your coverage files.
This is where I am having problems, it does work but you must do some parts alone. First I will give you what works, then I will give you what I am having problems with.

mvn clean package cobertura:cobertura

mvn site

The first thing that gives problems is doing the code coverage on the top project that does not have sources itself. An error due to the fact that target/classes is missing is thrown. The second problem I have is that I cannot do the two commands at once, there is a class loading issue.

I want to emphasize that this is a beginners perspective. The issues I am having might not be the complete truth. If you now more, or if I find out more, I will revise this part.

You can find the sources at my sample project at javaforge.
resources
http://mojo.codehaus.org/source-repository.html
http://cobertura.sf.net
http://mojo.codehaus.org/cobertura-maven-plugin

Yesterday I had an issue with some of the xml validations. We all know those DTD definitions in an xml document where the dtd is on the internet. We do want to use xml validation via the dtd but the dtd cannot be found if you are not on the internet. How can we resolves this?

<!DOCTYPE beans PUBLIC "-//SPRING/DTD BEAN//EN"

"http://www.springframework.org/dtd/spring-beans.dtd">

How can you add this dtd to eclipse?

Open the Preferences window of eclipse and go to:
MyEclipse > Editors > XML > XML Catalog


Now we need to add a user catalog. Push the new button.


Browse to the dtd (you can import it into your workspace at the same time. As a key enter the part after PUBLIC. -//SPRING/DTD BEAN//EN

There you have it, code completion in your xml editor.

Have fun

There are a lot of resources around for maven. Then why this blog item? Well actually because I want to capture what I do, if someone can use it along the way it would be nice. Therefore this blog item is here. This item describes the merging of my student sample application into a maven project.

First steps for maven:

• start reading the Maven Getting Started Guide


• Choose an archetype - These are a sort of project templates that come with maven and can be made company specific. In my case I want to create a web application, there is a mini guideline for webapplications



mvn archetype:create -DgroupId=nl.gridshore.registrations -DartifactId=registrations-webapp -DarchetypeArtifactId=maven-archetype-webapp



• Create java folder under main and test folder under src


• Copy sources into the java folder and resources into the resources folder


• Run mvn compile, a lot of libraries are downloaded, and see the compile hopelessly fail. The failing compile is as expected since we need the dependencies during compilation.


• Find and configure the dependencies. We list all dependencies; compile time, test time and runtime.


• Install sun files - there is a problem with the license from sun. Therefore they cannot be added to the repository. You need to do this manually. There is a very short item about installing these jars on this page (www.jugpadova.it)
  In short : download the classes from the sun site and issue the following command
  

  
  
  mvn install:install-file -Dfile=./jta-1_0_1B-classes.zip -DgroupId=javax.transaction -DartifactId=jta -Dversion=1.0.1B -Dpackaging=jar
  
  

  
  


• Install jars for mail, activation and connector - same idea as for jta



mvn install:install-file -Dfile=activation.jar -DgroupId=javax.activation -DartifactId=activation -Dversion=1.0.2 -Dpackaging=jar  

mvn install:install-file -Dfile=mail.jar -DgroupId=javax.mail -DartifactId=mail -Dversion=1.3.2 -Dpackaging=jar

mvn install:install-file -Dfile=connector.jar -DgroupId=javax.resource -DartifactId=connector -Dversion=1.0 -Dpackaging=jar



• Run the command to create the package



mvn package

Now we have a war file that we can deploy, I did not test it yet. I do have some more issues to figure out. While creating the war file, all libraries are copied to web-inf/lib, also all dependencies. Therefore I now have spring.jar and all components jars like spring-core, spring-aop, etc as well. So double jars, to much memory, etc.

Lets move on and try to get the maven site up and running.

• First try, just generate the site. This gives you the skeleton of the website, but almost no reports yet. You can have a look at your dependencies, nice.



mvn site

I must add versioning and maybe some other parts as well, but for now it is enough. In the near future I want to do more with the libraries, I do not want double spring jars etc, and I want to keep foolowing the reports. These reports are not working correct at the moment en they must be improved.

Today I upgraded the acegi library to version 1.0.0 RC1. It was a quick process, but you do need to make a few changes. The complete package structure is changed, JdbcDaoImpl class has been moved and some other changes as well. Have a look at the release notes in the downloaded acegi package. There was a nice addentum on the spring forum that you need to change the inclusion of the taglibrary as well.

<%@ taglib uri="http://acegisecurity.org/authz" prefix="authz" %>


Have fun, I will start documening the sample within a few weeks now.