Pages

Showing posts with label how to. Show all posts
Showing posts with label how to. Show all posts

Sunday, September 14, 2014

HowTo:: Design patterns with Scala or Java: GoF behavioural pattern Chain of Responsibilities

   
Img.1.: Chain Responsibilities pattern concept

   This pattern is really useful it allows the sender (sends the request) to be decoupled from the receivers. Those receivers are organised into a sequence. 
Inside such sequence every member has a opportunity to process the request or not and forward it to the next one.
  In this blog post I want to compare Java vs. Scala implementations of "Chain of Responsibilities pattern" and its possible implementation (Img.1.).

1. Java 
In following Java implementation is important point  abstract class AbstractHandler1 which has access to the successor property. The successor property provides concrete AbstractHandler1 handler implementation (creates the chain of different handlers).
a) AbstractHandler1:
public abstract  class AbstractHandler1 {
    AbstractHandler1 successor;

    public void setSuccessor(AbstractHandler1 successor){
        this.successor = successor;
    }

    abstract public  void handleRequest(ReqTypeEnum request);
}
Now we create ReqTypeEnum object which is thread-safe and its implementation guarantee that initialisation happens only ones and is immutable. In other hand implementation makes the Java code more readable. 
b) ReqTypeEnum
public enum ReqTypeEnum {
    typeOne(0),
    typeTwo(1),
    typeThree(2);

    private int code;

    private static final Map<Integer, ReqTypeEnum> codeToRequestTypeMapping = new HashMap<Integer, ReqTypeEnum>();
    static{
        for(ReqTypeEnum rt: ReqTypeEnum.values()){
            codeToRequestTypeMapping.put(rt.getCode(), rt);
        }
    }

    private ReqTypeEnum(int c){
        code = c;
    }

    public int getCode(){
        return code;
    }

    public static ReqTypeEnum getRequestType(int code) {
        return codeToRequestTypeMapping.get(code);
    }

}
   After having request handler skeleton (AbstractHandler1defined  and request type (ReqTypeEnum) we can make step forward and create couple of concrete hanlder implementations (example 3):
***************************
public class ConHandler1 extends AbstractHandler1 {
    private static final Logger logger = LoggerFactory.getLogger(ConHandler1.class);
    @Override
    public void handleRequest(ReqTypeEnum request) {
        if(request == ReqTypeEnum.typeOne){
            logger.debug("Concrete Handler 1 = " + request);
        } else {
            logger.debug("Concrete Handler 1 -> Doesn't handle request= " + request);
            if(successor != null){
                successor.handleRequest(request);
            }
        }
    }
}
***************************
public class ConHandler2 extends AbstractHandler1 {

    private static final Logger logger = LoggerFactory.getLogger(ConHandler2.class);

    @Override
    public void handleRequest(ReqTypeEnum request) {
        if(request == ReqTypeEnum.typeTwo){
            logger.debug("Concrete Handler 2 = " + request);
        } else {
            logger.debug("Concrete Handler 2 -> Doesn't handle request= " + request);
            if(successor != null){
                successor.handleRequest(request);
            }
        }
    }
}
***************************
public class ConHandler3 extends AbstractHandler1 {

    private static final Logger logger = LoggerFactory.getLogger(ConHandler3.class);

    @Override
    public void handleRequest(ReqTypeEnum request) {
        if(request == ReqTypeEnum.typeThree){
            logger.debug("Concrete Handler 3 = " + request);
        } else {
            logger.debug("Concrete Handler 3 -> Doesn't handle request= " + request);
            if(successor != null){
                successor.handleRequest(request);
            }
        }
    }
}
and prepare demo setup:
private static AbstractHandler1 setDemoUp(){
   ConHandler1 conHandler1 = new ConHandler1();
   ConHandler2 conHandler2 = new ConHandler2();
   ConHandler3 conHandler3 = new ConHandler3();

   conHandler1.setSuccessor(conHandler2);
   conHandler2.setSuccessor(conHandler3);

   return conHandler1;
}
  Java implementation is ready to launch  
public static void main(String... args){
   ...
   AbstractHandler1 responsibilityChain = setDemoUp();

   responsibilityChain.handleRequest(ReqTypeEnum.typeOne);
   responsibilityChain.handleRequest(ReqTypeEnum.typeTwo);
   responsibilityChain.handleRequest(ReqTypeEnum.typeThree);
   ...
}
  The demo output shows the chain of request handling:
ChainDemo1 - ***Start Chain of Responsibility Demo***
ConHandler1 - Concrete Handler 1 = typeOne
ConHandler1 - Concrete Handler 1 -> Doesn't handle request= typeTwo
ConHandler2 - Concrete Handler 2 = typeTwo
ConHandler1 - Concrete Handler 1 -> Doesn't handle request= typeThree
ConHandler2 - Concrete Handler 2 -> Doesn't handle request= typeThree
ConHandler3 - Concrete Handler 3 = typeThree


2.Scala
  As Java is up, let's move to the Scala possible implementation. This implementation should allow runtime configuration of registered handlers in the chain. Each handler is implemented as Scala object:
object ConHandler1 extends ChainHandler[String]{
  private val name: String = "Concrete Handler One"
  private val logger = LoggerFactory.getLogger(getClass)
  def accept(obj: String) = obj equals name
  def handle(obj: String) = logger.debug("SERVUS " + name)
}
***************************
object ConHandler2 extends ChainHandler[String]{
  private val name: String = "Concrete Handler Two"
  private val logger = LoggerFactory.getLogger(getClass)
  def accept(obj: String) = obj equals name
  def handle(obj: String) = logger.debug("HALLO " + name)
} 
  The ChainHandler is implemented as the generic trait and indicates that every concrete handler implementation, inside the chain, is able to decide whether is able to handle the request.
trait ChainHandler[T] {
  def accept(obj: T): Boolean
  def handle(obj: T): Unit
}
Each request is passed as the parameter which concrete handler uses for processing.
  The process of the requests chain is controlled by ChainManager Scala class. ChainManager groups all assigned concrete handlers and put them into the ListBuffer (chain). 
case class ChainManager[T](n: String) {
  private val logger = LoggerFactory.getLogger(getClass)
  val name: String = n
  private val chain = new ListBuffer[ChainHandler[T]]
  def add(h: ChainHandler[T]) = {
    chain += h
    ChainManager.this
  }
  def apply(obj: T) = {
    val handler = Option(chain.filter(n => n accept obj) head)
    handler match {
      case Some(chainElement) => chainElement handle obj
      case None => logger.error("no handler")
    }
  }
}
As the add() handler methods returns references to the ChainManager itself. It allows linking add() method to simplify the construction.  
controller.add(ConHandler1).add(ConHandler2)
Now we have all elements to run the sample program: 
object ChainOfRespManagerTest {
  private val logger = LoggerFactory.getLogger(getClass)
  def main(args: Array[String]): Unit = {
    val controller = ChainManager[String]("Manager Approach")
    logger.debug("---Chain of Responsibility: "+ controller.name +"---")
    controller.add(ConHandler1).add(ConHandler2)
    controller apply "Concrete Handler One"
    controller apply "Concrete Handler Two"
  }
}
and observe the out put of it:
ChainOfRespManagerTest$ - ---Chain of Responsibility: Manager Approach---
ConHandler1$ - SERVUS Concrete Handler One
ConHandler2$ - HALLO Concrete Handler Two
  

  Conclusion: Although java is cool language such implementation shows necessity to write not only little more code to achieve the similar result but also the solution is not, in some parts, generics enough. 
   The Scala solution illustrates how the invocation of the chain behaviour can be made to look like the part of the language product.   
Enjoy ! 

Sunday, September 7, 2014

HowTo:: Design patterns with Scala: GoF Structural Pattern Adapter and power of Trait

  
Img.1.:: Parts of Adapter patterns

   In this example I want to show power of trait usage in 2 different ways of Adapter Structural pattern implementations. There are couple of reasons why could be worth to think about the Adapter pattern. Basically the intent is to convert interface of the one type into the interface that client expects to use.
Pattern can be divided into the following parts (Img.1.):
1. Client - is an object that requires functionality provided by Adaptee but it's exposed by Adapter
2. Adapter - is an object that converts the interface expected by the client into the interface provided by Adaptee 
3. Adaptee - is an object that provides the implementation and the interface invoked by the Adapter

in both Adapter examples we do use same Client implementation: 
class Client(service: Service) {
  def doWork = {
    service.invoke
  }
}
and Service trait which defines method process:
trait Service {
  def process(): Unit
}
  Already from the Main Scala Object AdapterTest.scala is noticeable the 1st warm up of the Scala trait power which will be fully exposed by AdaptorTrait latter.
object AdapterTest {

  private val logger = LoggerFactory.getLogger(getClass)

  def main(args: Array[String]) ={
    logger.debug("Test Adapter pattern")
    val adaptor = new AdaptorOne
    val clientWithoutTrait = new Client(adaptor)
    clientWithoutTrait.doWork()

    val adaptorTraitOne = new AdapteeOne with AdaptorTrait
    val adaptorTraitTwo = new AdapteeTwo with AdaptorTrait
    val clientWithTrait1 = new Client(adaptorTraitOne)
    clientWithTrait1.doWork()

    val clientWithTrait2 = new Client(adaptorTraitTwo)
    clientWithTrait2.doWork()
  }

}

1. Object based implementation without trait we do use classical scala class definition of the AdapteeOne that provides implementation to the action() that Client wants.
class AdapteeOne extends Adaptee{
  private val logger = LoggerFactory.getLogger(getClass)
  def action() = { logger.debug("Adaptee One Action One")}
}
  The Adapee trait is used to make code standardised and also to point out limits of the presented Object implementation .
trait Adaptee {
  def action()
}
  Currently has been implemented 1st part of the blog post -> Adapter in the classical object way.

2. trait based approach is inspired by having two, almost same, objects (example: CAR1, CAR2) and both has different implementation of the action() function (example: both cars can ride). We again use AdapteeOne (previously implemented) and we create AdapteeTwo scala class.
class AdapteeTwo extends Adaptee{
  private val logger = LoggerFactory.getLogger(getClass)
  def action() = { logger.debug("Adaptee Two Action")}
}
   Both classes extend Adaptee trait which method is served to the AdaptorTrait that extend the Service (also previously defined)
trait AdaptorTrait extends Service{
  self: Adaptee =>
  def process() = action()
}
   Now we are ready also with 2nd Adapter pattern example usage. Trait usage (AdaptorTrait) allows to be mixed into a type either directly at the type declaration time or an object creation time.  This simply allows latter object behaviour extension. 
Traits go ahead! implementation with them is much easier, readable and extendable  + testable, less code

Saturday, September 6, 2014

HowTo:: Threading: Producer Consumer with thread-safe PriorityBlockingQueue as buffer with custom ordering


Img.1.:: Producer Consumer Problem examples (powered by IntelliJ Idea 13.x)

  In the previous blog post I've blogged about commonly issue in multi-threading Producer-Consumer problem with shared not synchronised buffer. Buffer also showed how to employ some conditions to control the access to it. (link)
  This ConsumerProducer example is more sophisticated. In this example is used MathPriorityTransferQueue which extends PriorityBlockingQueue and implements TransferQueue to employ better control over the exchange process itself. 

// methods to @Override from interface TransferQueue< e >
boolean tryTransfer(E e){...
boolean tryTransfer(E e, long timeout, TimeUnit unit){...
void transfer(E e) throws InterruptedException {...
boolean hasWaitingConsumer(){...
int getWaitingConsumerCount(){..

// methods to @Override from class PriorityBlockingQueue
public E take() throws InterruptedException{...
public E peek(){...
  The Distribution Systems, Parallel computing, machine learning or artificial intelligence are always excited, this is only small introduction to some small part that is worthy to know to make them possible,  so let's  start slowly with the example. 

   The heart of the example is the implementation of MathPriorityTransferQueue which is the buffer used by MathProducers and MathConsumers. The buffer allows them to work together. The basic idea of the example is that each PRODUCER generates NUMBER_PRODUCER_EVENTs that number  of consumers (NUMBER_CONSUMER) process. The total number of MathEvents that CONSUMERs needs to consume is then number of producers multiplied by the number of MathEvents they generates. 
Each MathEvent has assigned the random priority. The Priority is the key how the event are sorted inside MathPriorityTransferQueue.
The main class MathPrioProdConMain takes responsibility about the process of Producers creation and number of consumers. Important is to point out that Consumers will work only if something is available to consume inside the queue (simply when data are available). 
public class MathPrioProdConMain {
    ...
    private static final int NUMBER_CONSUMER = 2;
    private static final int NUMBER_PRODUCERS= 10;
    private static final int NUMBER_PRODUCER_EVENTS= 1000;

    public static void main(String... args){
        MathPriorityTransferQueue< MathEvent > buffer = new MathPriorityTransferQueue<>();
        ...
        Thread[] producerThread = new Thread[ NUMBER_PRODUCERS ];
        for(int i=0; i < NUMBER_PRODUCERS; i++){
            producerThread[i] = new Thread(new MathProducer(NUMBER_PRODUCER_EVENTS, buffer));
            producerThread[i].start();
        }
        ...
        Thread[] consumerThread = new Thread[ NUMBER_CONSUMER ];
        for(int i=0; i < NUMBER_CONSUMER; i++){
            consumerThread[i] = new Thread(new MathConsumer(buffer));
            consumerThread[i].start();
        }
        ...
    }
}
  To test the ordering abilities of the shared data-structure the main method sends unexpected MathEvents into the buffer with defined priority. On the output shows that the ordering is implemented correctly.
...
MathEvent event = new MathEvent(" Transfer Math SuperEvent ", 22);
buffer.transfer( event );
...
  At the end we wait until all consumer processes are done (all threads simply die). 

...
for(int i=0; i < NUMBER_CONSUMER ; i++)
                consumerThread[ i ].join();
...>
  We may keep in mind that the whole multi-threading process  works like state machine with its locking, un-locking, notifying and operations synchronisation which helps to understand why the rest of the code works.  


  Before we move into the code of MathPriorityTransferQueue we take a brief look what individual MathProducer is doing: 
public class MathProducer implements Runnable{
    ...
    public MathProducer(int maxMathEvents, MathPriorityTransferQueue< MathEvent > buffer){
        this.maxMathEvents = maxMathEvents;
        this.buffer = buffer;
    }
    ...
    @Override
    public void run() {
        for(int i=0; i< maxMathEvents; i++){
            Random random=new Random();
            int priority= random.nextInt(100);
            MathEvent event = new MathEvent("MathProducer-" + Thread.currentThread().getName(), priority);
            buffer.put(event);
        }
    }

}
 MathProducer responsibility is to generate some MathEvents and give them random priority. 

   The same action we do with consumer. The individual MathConsumer  consumes all new MathEvent that are available to him in the queue (queue is responsible for MathEvents prioritising). 
public class MathConsumer implements Runnable {
    ...
    public MathConsumer(MathPriorityTransferQueue< MathEvent > buffer) {
        this.buffer = buffer;
    }
    ...
    @Override
    public void run() {
        while(buffer.peek() != null){
            try{
                MathEvent event = buffer.take();
                logger.debug("MathConsumer-" + Thread.currentThread().getName() +
                        " : " + event.getThread() + " priority: " + event.getPriority());
            } catch (InterruptedException e){
                e.printStackTrace();
            }
        }
    }
}
  Now all parts participating on the example are defined and we can move to the implementation of the example heart MathPriorityTransferQueue . Here is worthy to point out atomic counter implementation to avoid possible race-condition and that the counter shouldn't be implemented by using volatile. Volatile quarantines only happens-before (write-read) but not atomicity at all. 
public class MathPriorityTransferQueue<E> extends PriorityBlockingQueue<E> implements TransferQueue<E> {
    ...
    private AtomicInteger counter;
    private LinkedBlockingQueue<E> transferList;
    private ReentrantLock lock;
    ...
    public MathPriorityTransferQueue(){
        counter = new AtomicInteger(0);
        lock = new ReentrantLock();
        transferList = new LinkedBlockingQueue<>();
    }
...
  The counter is used to control important operations that are provided by our DataStructure
1. take() operation to get an MathEvent from the data structure (increment counter) and when operation is finished than decrement the counter.
...
@Override
public E take() throws InterruptedException {
   lock.lock();
   counter.incrementAndGet();
   E result = transferList.poll();

   if(result == null){
     lock.unlock();
     result = super.take();
     lock.lock();
   } else {
      synchronized (result){
        result.notifyAll();
      }
   }
   counter.decrementAndGet();
   lock.unlock();
   return result;
}
...
2. peek() operation to retrieve but don't remove head of the queue if the queue is empty then returns null. Here we need to take care also about the transferList that represents Blocking queue to store accidentally transfered MathEvents
@Override
public E peek() {
   lock.lock();
   E eventMain = super.peek();
   E eventTrans = transferList.peek();
   E result = eventMain != null ? eventMain : eventTrans;
   lock.unlock();
   return result;
}
3. tryTransfer(E e) which tries to transfer MathEvent to the consumer if any is waiting for.
...
@Override
public void transfer(E event) throws InterruptedException{
   lock.lock();
   if(counter.get() != 0){
      put(event);
      lock.unlock();
   } else {
      transferList.add(event);
      lock.unlock();
      synchronized (event){
         event.wait();
      }
   }
}
...
4. tryTransfer(E event, long timeout, TimeUnit unit) throws InterruptedException method tries to provide MathEvent to the Consumer who is waiting maximum time. If not successful then transferList for someTimeout or thread is interrupted. 
...
@Override
public boolean tryTransfer(E event, long timeout, TimeUnit unit) throws InterruptedException {
   lock.lock();
   if(counter.get() != 0){
      put(event);
      lock.unlock();
      return true;
   } else {
       transferList.add(event);
       long someTimeout = TimeUnit.MILLISECONDS.convert(timeout, unit);
       lock.unlock();
       event.wait(someTimeout);
       lock.lock();
       if(transferList.contains(event)){
           transferList.remove(event);
           lock.unlock();
           return false;
       }else{
           lock.unlock();
           return true;
       }
    }
}
...
5. transfer(E e) throws InterruptedException method transfer successfully when Consumer is waiting for MathEvent if not it it put MathEvent into the transferList and waits until MathEvent is taken out. 
...
@Override
public void transfer(E event) throws InterruptedException{
   lock.lock();
   if(counter.get() != 0){
       put(event);
       lock.unlock();
   } else {
       transferList.add(event);
       lock.unlock();
       synchronized (event){
          event.wait();
       }
   }
}
...
  
and some more as you can find in the example source code but they are not critically important to make this example work (hasWaitingConsumergetWaitingConsumerCount). 
   As DataStructure is implemented we need to implement very important MathEvent method compareTo(MathEvent event) as MathEvent implements Comparable<MathEvent> interface.  
 In the example definition data structure orders elements based on their priority.  
public class MathEvent implements Comparable<MathEvent>{
    ...
    @Override
    public int compareTo(MathEvent event) {
        if (this.priority > event.getPriority()) {
            return -1;
        } else if (this.priority < event.getPriority()) {
            return 1;
        } else {
            return 0;
        }
    }
    ...
}
   Having all those steps done we can run successfully MathPrioProdConMain class. and we get following result (of course based on our setup of CONSUMERS and PRODUCERS with MathEvents )
...
MathConsumer-Thread-6 : MathProducer-Thread-4 priority: 71
MathConsumer-Thread-6 : MathProducer-Thread-2 priority: 71
MathPrioProdConMain: Buffer waiting consumers = 0
MathConsumer-Thread-6 : MathProducer-Thread-0 priority: 71
MathConsumer-Thread-6 : Transfer Math Calculation Event  priority: 1
MathConsumer-Thread-6 : MathProducer-Thread-0 priority: 70
MathConsumer-Thread-6 : MathProducer-Thread-0 priority: 70
...

   More comments can be found inside the source code that is available over my github account (example source code)
Enjoy Multi-threading !

Wednesday, August 20, 2014

HowTo:: Spring 4 Scala MVC without Web.XML - Tiles3 : static resources and front-end templating

Img.1.:: project structure - Tiles3 with localised messages and simple template 
This blogpost is fully focused on simple spring 4 scala project Tiles configuration and how to give access to the localised messages (see. Img.1.). 
In the WebConfig scala class is also configured:
1.  messageSource @Bean :
@Bean(name = Array("messageSource"))
def getMessageSource: MessageSource = {
  val msgSrc:ReloadableResourceBundleMessageSource = new ReloadableResourceBundleMessageSource()
  msgSrc.setBasename("classpath:/messages/message")
  msgSrc
}
Such bean give us access to the messages place in the "resource" project folder.
2.  default displayed locale by the "localeResolver" bean:
@Bean(name = Array("localeResolver"))
def getLocaleResolver: LocaleResolver = {
  val cookieLocaleResolver: CookieLocaleResolver = new CookieLocaleResolver()
  cookieLocaleResolver.setDefaultLocale(new Locale("en"))
  cookieLocaleResolver
}
3. access to the static project resources as is mentioned in to one of previous posts 

Let's start on the front-end dev. with the default tiles.xml file in the ../pages directory

  
 
 
  
  
 
 
  
  
    
    
  

  The example project has two page to display based on "standardLayout" which consists from header and footer
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"%>
<%@ taglib prefix="fmt" uri="http://java.sun.com/jsp/jstl/fmt"%>
<%@ taglib prefix="tiles" uri="http://tiles.apache.org/tags-tiles"%>


  
     <fmt:message>
 <tiles:insertAttribute name="title" />
     </fmt:message>
     <link rel="stylesheet" href="<c:url value="/app/css/style.css" />" >
  


Take a look into github example project
After having also *.jsp pages defined we can run our Tomcat7 container
container:start
and open the web browser and call the applicaiton: 
1. http://localhost:9090/?lang=de
2. http://localhost:9090/test/web?lang=de
3. http://localhost:9090/test/web?lang=en
4. http://localhost:9090/test/web

Enjoy Tiles 3 and take a look on my github example project to get more information around

Friday, August 8, 2014

HowTo:: Scala Spring 4 MVC without Web.XML configuration with static resources handling

This blog post is fully focused on Scala language and how to use it for Spring 4 based application development. I'll  modify application I've used over previous blog post series ("Spring4Netty without Web.XML configuration on Java 8.."). 

  Although Spring Framework is so popular in the Java land, there is no reason why not to use Scala language for the EE application development. 
In case when the Applicaiton front-end uses popular AngularJS Framework I personally find Scala usage much "easier" (ps: still lot of work :) and comfortable to understand back-end and front-end functionality as javascript uses callbacks. 

for building new Spring4 Scala application we use following tools: 
of course Jetty server can be change to the Tomcat one. 
  Whole sample application has been developed in IntelliJ IDEA 13.x IDE. 
After we have created the SBT project under IntelliJ we need to import some plugins.
Img.1.:: SBT Project Structure - plugins.sbt
  To import them we change sbt plugins setup by modifying appropriate file (Img.1.) in the following manner. 
addSbtPlugin("com.earldouglas" % "xsbt-web-plugin" % "1.0.0-M4")

addSbtPlugin("com.github.mpeltonen" % "sbt-idea" % "1.6.0")
  We have now added two plugins  xsbt-web-plugin and sbt-idea.  The xsbt-web-plugin is used for building web enterprise application. Both of them are extensions to SBT building tool.

  Next step is to add necessary libraries dependences into the build.sbt file. As we want to link also static resources, for the front-end development, the number of needed libraries will be bigger. 
  The build.sbt file will look after our modification like following example.
name := "miko-spring-scala"

version := "1.0"

scalaVersion := "2.10.3"

libraryDependencies ++= Seq(
  "org.springframework" % "spring-webmvc" % "4.0.6.RELEASE",
  "org.springframework" % "spring-context" % "4.0.6.RELEASE",
  "org.springframework" % "spring-context-support" % "4.0.6.RELEASE",
  "javax.servlet" % "javax.servlet-api" % "3.0.1" % "provided",
  "javax.servlet" % "jstl" % "1.2" % "compile",
  "org.eclipse.jetty" % "jetty-webapp" % "9.1.0.v20131115" % "container, compile",
  "org.eclipse.jetty" % "jetty-jsp" % "9.1.0.v20131115" % "container"
)

jetty(port = 9090)
here is visible which kind of servlet engine provider will be used (in case of Tomcat change jetty() to tomcat()). 

  When the SBT application is ready we will use commands to start/stop it.
... SBT console ...
container:start

container:stop
...
  All libraries and plugins are ready and we can start building Spring4 Scala Application without using Web.XML and with linked static resources for the next front-end development. Web.xml file will look almost empty in contracts to XML configuration.
...
Miko Scala Spring 4 - Example without Web.xml 
...
  The application package structure is very similar to the previous ones. I want to keep consistency and get possibility to have the reference to the Java implementation (Img.2.) in case of possible comparison.
Img.2.:: Example Spring4 Scala application packages structure

Now I simply turn the Java into the Scala in several steps

1. Scala WebConfig will look like following

..
@Configuration
@ComponentScan(basePackages = Array("miko.scala.helloexample"))
@EnableWebMvc
class WebConfig extends WebMvcConfigurerAdapter{

  override def addResourceHandlers(registry: ResourceHandlerRegistry) = {
    registry.addResourceHandler("/app/**").addResourceLocations("/app/").setCachePeriod(31550522)
  }

  override def configureDefaultServletHandling(configurer: DefaultServletHandlerConfigurer) = {
    configurer.enable()
  }

  @Bean
  def viewResolver = {
    val viewResolver = new InternalResourceViewResolver
    viewResolver.setViewClass(classOf[JstlView])
    viewResolver.setPrefix("/WEB-INF/pages/")
    viewResolver.setSuffix(".jsp")
    viewResolver
  }
}
2. Scala WebInitializer which help us setup ServletContext at the starup 
class WebInitializer extends WebApplicationInitializer{

  override def onStartup(servletContext: ServletContext) = {
    val ctx = new AnnotationConfigWebApplicationContext
    ctx.register(classOf[WebConfig])

    ctx.setConfigLocation("META-INF/spring/app-spring-scala.xml")

    val servlet: Dynamic = servletContext.addServlet("dispatcher", new DispatcherServlet(ctx))
    servlet.addMapping("/")
    servlet.setLoadOnStartup(1)
  }
}
3. Scala HelloExampleController class annotated by @Contoller annotation. The Annotation takes care about HttpServletRequest and Responses. This example controller also shows how Services are @Autowired when Scala language is used. 
@Controller
@RequestMapping(Array("/"))
class HelloExampleController @Autowired() (exampleService: ExampleService, exampleImportService: ExampleImportService){

  @RequestMapping(method =  Array(RequestMethod.GET))
  def hello( model: Model) = {
    model.addAttribute("message", "Here is Scala with ServiceName = " + exampleService.serviceName)
    model.addAttribute("importMessage", "Here is Scala with ServiceImportName = " + exampleImportService.name)
    "hello"
  }
}
4. Scala Example...Services used by HelloExampleController are done over quite powerful Traits implementation. Traits are very similar to Java Interfaces but they allows partial implementation which makes them much more powerful (out of blogpost scope ;).  
trait ExampleImportService {
  def name: String
}
-----
class ExampleImportServiceImpl extends ExampleImportService{
  override def name: String = "Imported service over XML"
}

after all those steps we've ready Scala Spring 4 application to test. We've also source code to compare with previous Java8 implementation. Scala does the great work because thinking in functions and callbacks intentions makes whole development more strait forward. 
Enjoy sample application ! (GitHub miko-spring-scala)