WSDL to Java using Apache CXF

The good people at Apache CXF have included in the maven plugin version of the library a wsdl2java functionality that can effortlessly produce the Java stubs out of the given WSDL file as part of the build.

For a showcase I have pointed to Betfair’s WSDL to produce the Java stubs.

Here’s the POM xml:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>com.dimitrisli.jaxws</groupId>
	<artifactId>Wsdl2Java</artifactId>
	<version>1.0</version>
	<build>
		<plugins>
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-compiler-plugin</artifactId>
				<version>2.3.2</version>
				<configuration>
					<source>1.6</source>
					<target>1.6</target>
					<encoding>${project.build.sourceEncoding}</encoding>
				</configuration>
			</plugin>
			<plugin>
				<groupId>org.apache.cxf</groupId>
				<artifactId>cxf-codegen-plugin</artifactId>
				<version>${cxf.version}</version>
				<executions>
					<execution>
						<id>generate-sources</id>
						<phase>generate-sources</phase>
						<configuration>
							<sourceRoot>${basedir}/generated/betfair</sourceRoot>
							<wsdlOptions>
								<wsdlOption>
									<wsdl>${basedir}/src/main/resources/my.wsdl</wsdl>
									<extraargs>
										<extraarg>-impl</extraarg>
										<extraarg>-verbose</extraarg>
									</extraargs>
								</wsdlOption>
							</wsdlOptions>
						</configuration>
						<goals>
							<goal>wsdl2java</goal>
						</goals>
					</execution>
				</executions>
			</plugin>
		</plugins>
	</build>
	<dependencies>
		<dependency>
			<groupId>org.apache.cxf</groupId>
			<artifactId>cxf-rt-frontend-jaxws</artifactId>
			<version>${cxf.version}</version>
			<type>jar</type>
			<scope>compile</scope>
		</dependency>
		<dependency>
			<groupId>org.apache.cxf</groupId>
			<artifactId>cxf-rt-transports-http</artifactId>
			<version>${cxf.version}</version>
			<type>jar</type>
			<scope>compile</scope>
		</dependency>
		<dependency>
			<groupId>org.apache.cxf</groupId>
			<artifactId>cxf-rt-transports-http-jetty</artifactId>
			<version>${cxf.version}</version>
			<type>jar</type>
			<scope>compile</scope>
		</dependency>
	</dependencies>
	<properties>
		<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
		<cxf.version>2.5.1</cxf.version>
	</properties>
</project>

By running mvn generate-sources the Java classes are getting produced in the specified directory.

You can view the code in this Github repository.

Spring MVC, Spring Scheduling, Maven example

This is an example showcasing Spring’s scheduling capabilities sitting on top on a Spring MVC Maven project.

First the POM looks like this:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.dimitrisli.springmvc</groupId>
  <artifactId>SpringMVCScheduler</artifactId>
  <packaging>war</packaging>
  <version>1.0</version>
  <build>
  	<finalName>SpringMVCScheduler</finalName>
  	<plugins>
  		<plugin>
  			<groupId>org.apache.maven.plugins</groupId>
  			<artifactId>maven-compiler-plugin</artifactId>
  			<version>2.3.2</version>
  			<configuration>
  				<source>1.6</source>
  				<target>1.6</target>
  				<encoding>${project.build.sourceEncoding}</encoding>
  			</configuration>
  		</plugin>
  	</plugins>
  </build>
  <dependencies>
    <dependency>
      <groupId>log4j</groupId>
      <artifactId>log4j</artifactId>
      <version>1.2.16</version>
      <scope>compile</scope>
    </dependency>
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-webmvc</artifactId>
      <version>3.1.0.RELEASE</version>
      <scope>compile</scope>
    </dependency>
    <dependency>
  		<groupId>javax.servlet</groupId>
  		<artifactId>servlet-api</artifactId>
  		<version>2.5</version>
  		<scope>provided</scope>
  	</dependency>
  	<dependency>
  		<groupId>javax.servlet.jsp</groupId>
  		<artifactId>jsp-api</artifactId>
  		<version>2.2</version>
  		<scope>provided</scope>
  	</dependency>
  </dependencies>
  <properties>
  	<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>
</project>

Notice that the spring-webmvc dependency is enough to bring along all the other Spring jars that are necessary thanks to the dependency hierarchy that Maven is taking care off behind the scenes so gracefully.

The web.xml of the web app looks like this:

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

		spring
		org.springframework.web.servlet.DispatcherServlet
		1

		spring
		/

		log4jConfigLocation
		/WEB-INF/log4j.properties

		org.springframework.web.util.Log4jConfigListener

		contextConfigLocation
		/WEB-INF/application-context.xml

		org.springframework.web.context.ContextLoaderListener

A few things to notice:

  • The sole Servlet we need to define is Spring’s DispatcherServlet that we map to any incoming url pattern
  • Spring’s ContextLoaderListener is defined in the web.xml and is initialising the container similar to the ApplicationContext or the old deprecated XMLFactoryBean (it was giving too much unnecessary power).
  • If we want Log4j to be initialised, up and running when the Spring app is starting up we can define Spring’s helper Log4jConfigListener¬†
  • With the context-param element we can explicitly specify the main config file of the Spring context.

This application context looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:context="http://www.springframework.org/schema/context"
	xmlns:mvc="http://www.springframework.org/schema/mvc"
	xsi:schemaLocation="http://www.springframework.org/schema/beans
	   		http://www.springframework.org/schema/beans/spring-beans-3.1.xsd
	   		http://www.springframework.org/schema/context
	   		http://www.springframework.org/schema/context/spring-context-3.1.xsd
			http://www.springframework.org/schema/mvc
			http://www.springframework.org/schema/mvc/spring-mvc-3.1.xsd">

	<!-- Scans the classpath under the base-package for annotated components -->
	<context:component-scan base-package="com.dimitrisli.springmvc.controller" />

	<!-- Scheduling config -->
	<import resource="scheduling-context.xml" />

</beans>

whereas the autoloaded spring-servlet.xml based on the DispatcherServlet‘s servlet-name we define in web.xml that defines how the view url resolves:


<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:p="http://www.springframework.org/schema/p"
	xsi:schemaLocation="http://www.springframework.org/schema/beans
	   		http://www.springframework.org/schema/beans/spring-beans-3.1.xsd">

	<!-- Declare a view resolver -->
		<bean
		class="org.springframework.web.servlet.view.InternalResourceViewResolver">
		<property name="prefix">
			<value>/WEB-INF/jsp/</value>
		</property>
		<property name="suffix">
			<value>.jsp</value>
		</property>
	</bean>

</beans>

The scheduler context looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:p="http://www.springframework.org/schema/p"
	xmlns:task="http://www.springframework.org/schema/task"
	xsi:schemaLocation="http://www.springframework.org/schema/beans
	   		http://www.springframework.org/schema/beans/spring-beans-3.1.xsd
	   		http://www.springframework.org/schema/task
			http://www.springframework.org/schema/task/spring-task-3.1.xsd">

	<!-- Spring's scheduling support -->
	<task:scheduled-tasks scheduler="taskScheduler">
		<!-- task:scheduled ref="fixedDelayService" method="performService" fixed-delay="5000"/-->
		<!-- task:scheduled ref="fixedRateService" method="performService" fixed-rate="5000"/-->
    	<task:scheduled ref="cronService" method="performService" cron="*/5 * * * * ?"/>
	</task:scheduled-tasks>

	<!-- The bean that does the actual work -->
	<bean id="fixedDelayService" class="com.dimitrisli.springmvc.scheduling.FixedDelayServiceImpl" />
	<bean id="fixedRateService" class="com.dimitrisli.springmvc.scheduling.FixedRateServiceImpl" />
	<bean id="cronService" class="com.dimitrisli.springmvc.scheduling.CronServiceImpl" />

	<!-- Defines a ThreadPoolTaskScheduler instance with configurable pool size. -->
	<task:scheduler id="taskScheduler" pool-size="1"/>

</beans>

Things to consider here:

  • Spring’s namespaces and namely the task namespace, is allowing us to define the scheduler and its scheduled tasks.
  • Each one of the scheduled tasks is a bean we define specifying the method we would like to execute once the scheduler kick-starts the job
  • We showcase 3 different scheduled tasks Spring provides fixed-delay, fixed-rate and the cron-way.

The code can be found in this Github repository.

Java String Pool

In Java, String literal allocation to variables like:

String oneLiteral = "imaliteral"

is not leading to a new String Object creation in the Heap but rather is using a String Pool following the Flyweight Design Pattern. Following the pattern there is a repository of already used literals that are getting reused/re-allocated to String variables upon request.

Looking at the bytecode footprint of:

String oneLiteral = "imaliteral";
String anotherLiteral = "imaliteral"

we descover that the ldc opcode is used for the same string litteral to be placed in the stack. Therefore at compile time all the same literals are “bytecode-ed” to reference the same String in the String pool. This makes it possible to compare using

During runtime, access to the String pool is only through explicit call of the String#intern() method making sure the following evaluates to true:

("fly"+"weight").intern() == "flyweight"

Scala advanced Type Inference

Scala is a statically typed JVM language which means that the variable types are defined at compile time. This is the case also for Java and C++ although the advanced type inference system in Scala let the language behave and ‘feel’ like a dynamic language although the compiler is still doing all the hard work of figuring out the variable type.

Consider the following examples in Java and Scala that produce identical compile code in the bytecode level.

Java code:

class TestTypeInferenceJava {

        public static void main(String[] args){
                int x=10;
        }
}

which after desassembling:

javap -c TestTypeInferenceJava

produces the following bytecode:

Compiled from "TestTypeInferenceJava.java"
class TestTypeInferenceJava extends java.lang.Object{
TestTypeInferenceJava();
  Code:
   0:	aload_0
   1:	invokespecial	#1; //Method java/lang/Object."<init>":()V
   4:	return

public static void main(java.lang.String[]);
  Code:
   0:	bipush	10
   2:	istore_1
   3:	return

}

Note the bipush opcode that pushes the integer into the stack as well as the istore_1 that stores the integer into the stack as a local variable.

The equivalent Scala code is:

class TestTypeInference {
        def main(args: Array[String]): Unit = {
                var x=10
        }
}

that disassembles into:

public class TestTypeInference extends java.lang.Object implements scala.ScalaObject{
public void main(java.lang.String[]);
  Code:
   0:	bipush	10
   2:	istore_2
   3:	return

public TestTypeInference();
  Code:
   0:	aload_0
   1:	invokespecial	#19; //Method java/lang/Object."<init>":()V
   4:	return

}

Note the type inference of the integer variable (bipush and istore_1) as well as the identically produced bytecode (only discrepancy is the difference in the index of the corresponding local variable).