RSS

Bringing together Docker, Grunt, Maven, EmberJS & MongoDB

Abstract : Will it work? … How can I be sure? … Am I forgetting something? … questions that pile up slowly and ruin our confidence once we cannot clearly answer them. For reasons like these we write tests – to be confident, to be certain, to sleep better. Yet, writing tests is one part of the problem. Getting them executed in an environment close to the production one is another . … and so, more questions pile up : How do we keep a snapshot of our production environment for testing purposes? What if our app needs to run in different environments? Can we keep multiple virtual environment snapshots? How many? Can we have test parallelization? Is the sandboxing guaranteed? and so on, and so on …

In this post, we are going to take a look at orchestrating Maven, Grunt & Docker to provide the basis for setting up integration tests.

Read more @ ingini.org

Advertisement
 
Leave a comment

Posted by on June 17, 2014 in Docker, EmberJS, Grunt, Guice, Java, Jetty, Jongo, MongoDB

 

Tags: , , , , , , , ,

GitHub Pages & Ghost – Just blog it!

A year and a half ago, I migrated my blog from WordPress to GitHub. I was very happy to have a responsive and nicely styled blog thanks to Octopress which I could host for free… Read more @ ingini.org

 
Leave a comment

Posted by on June 3, 2014 in Ghost, GitHub, GitHub Pages, Octopress

 

MongoDB With Jongo – Sleeves Up!

Abstract : In this post you will find a brief introduction to Jongo – a fast, easy-to-use, Java-based querying library for MongoDB. There are plenty of articles discussing MongoDB around the Internet and it’s documentation is quite good. Thus, here you won’t find any introduction to MongoDB nor am I going to convince you to use it or not. In this article I’m going to show you that querying MongoDB from Java can be easy. Don’t be afraid from the size of the post, most of it is simple code and data samples.

Goal : Basic use of Jongo for querying MongoDB.

Acknowledgement : My gratitude goes to the open source community and especially to:

Benoit Guérout creator of Jongo

Yves Amsellem co-creator of Jongo

Xavier Bourguignon for his open-mind and open-heart

Code : You can download the full source of the project from GitHub

Read more @ ingini.org

 
Leave a comment

Posted by on June 3, 2013 in Java, Jongo, MongoDB

 

Tags: , , ,

AKKA ask pattern: For those times when you have to block

Abstract : Since you are here, chances are, you are in one of those situations where you have to come up with a blocking solution using AKKA. Thus I’m going to skip the actor model introduction which is necessary to understand how AKKA actor model implementation works (you can read more about the actor model on the AKKA docs website). In this post you will find out how you can take advantage of AKKA’s ask pattern to do blocking when necessary.

Goal : Develop a “fire-and-await-confirmation” system based on AKKA ask pattern

Acknowledgement : My gratitude goes to the open source community and especially to:

Jonas Bonér (@jboner) for the creation of AKKA

Viktor Klang (@viktorklang) for his attention to the details

Maxime Nowak (@maximenowak) for his eye-opening discussions and “religious” clean-coding

Code : You can download the full source of the project from GitHub

Full post : Read more @ ingini.org

 
Leave a comment

Posted by on April 1, 2013 in Actor Model, AKKA, Java, Spring

 

Tags: , , ,

Chatting Through JActor

Abstract : Nearly 40 years ago Carl Hewitt, Peter Bishop and Richard Steiger introduced the actor model. Since then it has been built in some languages (such as Scala, Erlang, etc.) and has been implemented by several frameworks. One (of not so many) Java actor frameworks is the JActor framework – “a high-throughput Java Actor framework” (as described by its author Bill la Forge). In this post we are going to take a (brief) look at JActor framework by building a simple backbone for chatting (j)actors.

Goal : Build a simple chat application using JActor framework

Acknowledgement: My gratitude goes to the open source community and especially to:

Bill la Forge creator of JActor framework

Code : Project code can be found @ GitHub under Apache License, Version 2.0

Full post : Read more @ ingini.org

 
Leave a comment

Posted by on November 23, 2012 in JActor, Java, Uncategorized

 

Tags: , , , , , , , , , , ,

So long WordPress, hello Octopress

Abstract : Contrary to what you might be expecting, I’m not going to advocate switching to Octopress, but rather give a hand to those of you who would like to migrate from WordPress to Octopress via GitHub Pages hosting. By the way, this is (most probably) my last post on my WordPress blog. I have a new one (http://ingini.org/) hosted freely by GitHub and build with Octopress.

Goal : Migrating from WordPress to Octopress

Acknowledgement: My gratitude goes to the open source community and to the following people:

Rob Hunder – How to install Octopress on Ubuntu

Rob Dodson – Custom Domain With Octopress and Github Pages

Eric – How I built my blog in one day

Viggiosoft – Setting Up a Blog With Octopress

Before we begin, keep in mind that Internet is already full of different tutorials on Octopress and hosting via GitHub. Thus I will keep this post as short as possible and avoid repeating the same stuff which others have explained quite well (look at the links above and the Octopress on-line docs).

Step 1: Look around you

I encourage you to take a look at the posts I have carefully selected for you in the Acknowledgement section. They cover (almost) everything from setting up Octopress to deploying on your GitHub pages account. Don’t forget to check the Octopress documentation as well. In addition to the Acknowledgement section, there are plenty of resource out there, on how to set up a blog with Octopress and Jekyll. I’ve chosen Octopress because of the simple and straightforward way of building my blog. However, if you are interested in other ways to set up your blog, I invite you to check http://jekyllbootstrap.com/ and ruhoh.

Step 2: WordPress XML blog data extraction

Once you’ve done your initial research and installed the Octopress you’re probably wondering how to migrate your WordPress blog. I found a really simple and nice solution based on Exitwp. For this tool to work you need to extract your blog in an XML file. You can do this easily and for free via your WordPress account. Once you’ve logged, go to:

Dashboard -> Tools -> Export -> Export

Now that you have your blog in an XML file, read the short tutorial on https://github.com/thomasf/exitwp carefully because you may have to perform each and single step of it.

Step 3: Enjoy the Octopress

There is just one last thing to know: at the time of writing this post, the (git) master branch of Octopress is at version 1.* but there is also the branch 2.1 which resolves a lot of bugs and adds new features (for me 2.1 resolved some code highlighting problems). So although it’s not necessary you may want to update to the latest version by doing:

git checkout -b 2.1
git pull octopress 2.1
bundle install
rake update
rake generate
 
Leave a comment

Posted by on November 7, 2012 in exitwp, GitHub, GitHub Pages, Jekyll, Octopress, WordPress

 

Tags: , , , ,

Chasing Heisenbugs from an AKKA actor integration test with awaitility

Abstract : Ever had an impression you’re changing what you’re observing by simply observing it? If you so, you may have hit a Heisenbug ([1], [2]). Well, OK, I agree that a more precise definition of “observing” is needed and that we can differentiate between active and passive observing. The thing is one can hardly be a fully passive observer, especially when it comes to testing multi-threaded programs. Assuming you’re really working on the program and not simply looking a video tutorial in which case you will be a fully passive observer (and I would be wondering how the heck you’ve tumbled on my article). In short, when working on (including testing) a program we may introduce Heisenbugs through levels of indirection which are usually hard to spot. In C/C++ such a level of indirection represents uninitialized auto variables which can change every time you run you program. In Java a source of many indirection levels is the platform independence provided by the JVM. In JavaScript a source of Heisenbugs can be processing uncontrolled (browser dependent) events such as the scroll event.

Goal : Chase and fix a Heisenbug within an AKKA actor integration test using Awaitility

Acknowledgement: My gratitude goes to the open source community

An AKKA actor based program : I’ve already given an example of an AKKA actor base program here and you can find the source code here. So to save you and me some time, I’m going to re-use it.

Naïve test case : First we are going to build a test case which is prone to Heisenbugs and then we are going to fix it. I’m going to use JUnit, Spring Test Framework, Mockito, FEST-Assert, and FEST-Reflect to build up the following integration test case (access article’s full source code):

import akka.actor.ActorRef;
import org.honeysoft.akka.Bootstrap;
import org.honeysoft.akka.service.IBusinessService;
import org.junit.Before;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.Mock;
import org.mockito.MockitoAnnotations;
import org.slf4j.Logger;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.annotation.Qualifier;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;

import static org.fest.reflect.core.Reflection.field;
import static org.mockito.Matchers.anyString;
import static org.mockito.Matchers.eq;
import static org.mockito.Mockito.times;
import static org.mockito.Mockito.verify;

@ContextConfiguration(classes = {Bootstrap.class})
@RunWith(SpringJUnit4ClassRunner.class)
public class BusinessActorTest {

    @Autowired
    @Qualifier(Bootstrap.BUSINESS_ACTOR)
    private ActorRef businessActorRef;

    @Autowired
    private IBusinessService businessService;

    @Mock
    private Logger mockBusinessServiceLogger;

    @Before
    public void beforeEach() {
        MockitoAnnotations.initMocks(this);
    }

    @Test
    public void shouldBeValidWhenNoOneIsNull() {
        //GIVEN
        field("logger").ofType(Logger.class).in(businessService).postDecorateWith(mockBusinessServiceLogger);

        //WHEN
        String testString = "test-string";
        businessActorRef.tell(testString);

        //THEN
        verify(mockBusinessServiceLogger, times(1)).info(anyString(), eq(testString));
    }
}

The thing is that this test case is prone to Heisenbugs. More precisely, the verification (at line 50) may pass some times and may fail others. Depending on the speed of execution and thread priority it can happen that the verification comes before the businessService receives the testString for processing. Luckily we have Awaitility at our disposal so the fix is straightforward:

import akka.actor.ActorRef;
import com.jayway.awaitility.Awaitility;
import com.jayway.awaitility.Duration;
import org.fest.assertions.Assertions;
import org.honeysoft.akka.Bootstrap;
import org.honeysoft.akka.service.IBusinessService;
import org.junit.Before;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.MockitoAnnotations;
import org.slf4j.Logger;
import org.slf4j.Marker;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.annotation.Qualifier;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;

import java.util.concurrent.Callable;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.ConcurrentMap;

import static org.fest.reflect.core.Reflection.field;

@ContextConfiguration(classes = {Bootstrap.class})
@RunWith(SpringJUnit4ClassRunner.class)
public class BusinessActorTest {

    @Autowired
    @Qualifier(Bootstrap.BUSINESS_ACTOR)
    private ActorRef businessActorRef;

    @Autowired
    private IBusinessService businessService;

    @Before
    public void beforeEach() {
        MockitoAnnotations.initMocks(this);
    }

    @Test
    public void shouldBeValidWhenNoOneIsNull() throws Exception {
        //GIVEN
        final ConcurrentMap<String, Object> threadSafeMap = new ConcurrentHashMap<String, Object>(1);
        field("logger").ofType(Logger.class).in(businessService).postDecorateWith(new TestLogger(threadSafeMap));

        //WHEN
        String testString = "test-string";
        businessActorRef.tell(testString);

        //THEN
        Awaitility.waitAtMost(Duration.FIVE_SECONDS).until(new Callable<Boolean>() {
            @Override
            public Boolean call() throws Exception {
                return !threadSafeMap.isEmpty();
            }
        });

        Assertions.assertThat(threadSafeMap).hasSize(1);
        Assertions.assertThat(threadSafeMap.values().iterator().next()).isEqualTo(testString);
    }

    private static final class TestLogger implements Logger {

        private final ConcurrentMap<String, Object> map;

        private TestLogger(ConcurrentMap<String, Object> map) {
            this.map = map;
        }

        @Override
        public void info(String format, Object arg) {
            map.put(format, arg);
        }

        //Other overridden methods go here
    }
}

So what happened is that instead of mocking our logger target we’ve created a thread-safe TestLogger to help us. Then we’ve added an awaitility block to either wait for at most 5 secs or until our piggy-bag map is not empty. Well, that was all. Not too painful right?

 

Tags: , , , , , , , , , , , , ,

Surviving Mac OS X bash terminal with Midnight Commander (MC)

Abstract : Midnight Commander (MC) is one of the few tools I’m still using since I’ve been inducted into software engineering more than 10 years ago (for comparison I’ve changed 5 integrated development environments (IDE) ). MC is classified as “a visual file manager” but for me is something much more, it’s an engineering booster. In fact it’s my fist IDE (MCedit supports color highlighting for various programming languages). In short, MC is one of those few things that changes your world. That’s why I’m going to show you how you can painlessly integrate MC with Mac OS X bash terminal.

Goal : Configuring Midnight Commander under Mac OS X bash terminal

Acknowledgement : My gratitude goes to the open source community and especially to:
Miguel de Icaza – creator of Midnight Commander, Gnome, Mono, Gnumeric (and I guess other cool stuff)

Let’s get started!

Installation: I’m a huge fan of homebrew (thanks Max!) and I advise you to install it and work with it. In short, Homebrew is “the missing package manager for OS X”. Installing Homebrew is as easy as running the following command in the terminal prompt:

ruby <(curl -fsSkL raw.github.com/mxcl/homebrew/go)   

Once you have Homebrew, installing MC is exactly three words:

brew install mc

Side note: You may wish to install bash-completion and take advantage of the Tab key on the terminal prompt. If so, do the following:

brew install bash-completion

… and ensure that your .bash_profile has the following content inside:

if [ -f `brew --prefix`/etc/bash_completion ]; then
    . `brew --prefix`/etc/bash_completion
fi

Note that you have to perform:

source .bash_profile 

or re-open your terminal for the changes to take effect.

Mac OS X – fixing the shortcuts mess: No, I have no idea why the Apple guys have created such a big mess with the keyboard shortcuts. And yes, it’s up to you, my dearest reader, to decide if you want to fix it as I suggest. Here is what I’ve done so that I can use my Functional keys (the F keys):

Go to:

System Preferences -> Keyboard -> Keyboard and Shortcuts

… and make sure you have All controls checked

After that go to:

System Preferences -> Keyboard -> Keyboard

… and make sure you have Use all F1, F2 etc. keys as standard function keys checked

Next open a Terminal and go to:

Terminal -> Preferences ... -> Keyboard

… and make sure you have Use option as meta key unchecked.

Now, every F9 will enable MC menu bar and every F10 button press will exit MC (instead of doing a complex fingers split which may not work but which will certainly hurt your hand).

Playing with MC shortcuts: What about the cool MC shortcuts? Before I present you with some of the shortcuts mapping you should be aware that pressing two times the Esc button will close any MC pop-up or search box, and that there are three types of shortcuts:

  1. Pressing (and releasing) Esc and then pressing another key
  2. Pressing and holding Ctrl and then pressing another key
  3. Using the Functional key

Here are some mappings:

----- Esc -----
Quick change directory: Esc + c
Quick change directory history: Esc + c and then Esc + h
Quick change directory previous entry: Esc + c and then Esc + p
Command line history: Esc + h
Command line previous command: Esc + p
View change: Esc + t (each time you do this shortcut a new directory view will appear)
Print current working directory in command line: Esc + a
Switch between background command line and MC: Ctrl + o
Search/Go to directory in active panel: Esc + s / Ctrl + s then start typing directory name
Open same working directory in the inactive panel: Esc + i
Open parent working directory in the inactive panel: Esc + o
Go to top of directory in active pane: Esc + v / Esc + g
Go to bottom of directory in active pane: Esc + j / Ctrl + c
Go to previous directory: Esc + y
Search pop-up: Esc + ?
----- Ctrl -----
Refresh active panel: Ctrl + r
Selecting files and directories: Ctrl + t
Switch active <-> inactive panels: Ctrl + i
Switch active <-> inactive panels content: Ctrl + u
Execute command / Open a directory: Ctrl + j
----- F -----
F1: help
F2: user menu
F3: read file / open directory
F4: edit file
F5: copy file or direcotry
F6: move file or directory
F7: create directory
F8: delete file / directory
F9: open menu bar
F10: exit MC

Keeping working directory after exiting MC: Now, I find this MC feature really cool but of course it’s up to you to decide if you want to enabled it or not. In case you want, make sure you have the following (or similar, depending on the midnight commander version) line in your .bash_profile:

alias mc=". /usr/local/opt/midnight-commander/libexec/mc/mc-wrapper.sh"

Note that you have to perform:

source .bash_profile 

or re-open your terminal for the changes to take effect.

 
14 Comments

Posted by on September 9, 2012 in bash, homebrew, Mac OS X, Midnight Commander

 

Tags: , ,

AKKA actor dependency injection using Spring

Abstract : Dependency Injection (DI) is refine flavour of Inversion of Control (IoC) design pattern. One of the software frameworks out there which provides DI implementation is Spring. AKKA on the other hand is “a toolkit and runtime for building highly concurrent, distributed, and fault tolerant event-driven applications on the JVM“. In this article we are going to concentrate on the actor model implemented by AKKA and more specifically on dependency injection in the UntypedActor class, as well as, injecting AKKA actor in a Spring enabled service.

Goal : Create a software bridge between Spring and an AKKA actor to ensure basic dependency injection

Acknowledgement : My gratitude goes to the open source community

We are going to use the following components to reach our goal: AKKA version 2.0.2, Spring 3.1.1.RELEASE, FEST Reflect 1.4, Logback 1.0.6, CGLIB 2.2, and Maven to glue everything together. All programming will be done in Java and you can find all files on GitHub. Don’t hesitate to fork the project and improve it. Here is the Maven POM file:

<?xml version="1.0" encoding="UTF-8"?>
<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>org.honeysoft.akka</groupId>
    <artifactId>akka-di</artifactId>
    <version>1.0</version>

    <properties>
        <akka.version>2.0.2</akka.version>
        <spring.version>3.1.1.RELEASE</spring.version>
        <fest-reflect.version>1.4</fest-reflect.version>
        <logback.version>1.0.6</logback.version>
    </properties>

    <dependencies>
        <!-- Akka dependencies  -->
        <dependency>
            <groupId>com.typesafe.akka</groupId>
            <artifactId>akka-actor</artifactId>
            <version>${akka.version}</version>
        </dependency>

        <!-- Spring dependencies -->
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-context</artifactId>
            <version>${spring.version}</version>
        </dependency>

        <!-- Tools -->
        <dependency>
            <groupId>org.easytesting</groupId>
            <artifactId>fest-reflect</artifactId>
            <version>${fest-reflect.version}</version>
        </dependency>

        <dependency>
            <groupId>cglib</groupId>
            <artifactId>cglib-nodep</artifactId>
            <version>2.2</version>
        </dependency>

        <!-- Logging -->
        <dependency>
            <groupId>ch.qos.logback</groupId>
            <artifactId>logback-classic</artifactId>
            <version>${logback.version}</version>
        </dependency>

    </dependencies>

    <repositories>
        <repository>
            <id>akka.repository</id>
            <name>Akka Maven Repository</name>
            <url>http://repo.akka.io/releases/</url>
        </repository>
    </repositories>
 </project>

Good. Once you have all what’s needed we can start by building our simple business service which we are going to inject in our actor, here it is:

package org.honeysoft.akka.service;

public interface IBusinessService {

    void doBusiness(Object o);
}

… and it’s implementation:

package org.honeysoft.akka.service.impl;

import org.honeysoft.akka.service.IBusinessService;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.stereotype.Service;

@Service
public class BusinessService implements IBusinessService {
    private final Logger logger = LoggerFactory.getLogger(this.getClass());

    @Override
    public void doBusiness(Object o) {
        logger.info("Doing business with {}", o);
    }
}

As we can seen there is nothing fancy in our simple business service. All that it’s doing is logging an information about doing business with someone. Note, however, that it’s annotated with @Service this allows it to be discovered, created and injected by Spring.

Now, let’s see our actor:

package org.honeysoft.akka.actor;

import akka.actor.UntypedActor;
import org.honeysoft.akka.service.IBusinessService;
import org.springframework.beans.factory.annotation.Autowired;

public class BusinessActor extends UntypedActor {

    @Autowired
    private IBusinessService businessService;

    @Override
    public void onReceive(Object o) throws Exception {
        businessService.doBusiness(o);
    }
}

Once more, nothing special, just injecting our business service using the @Autowired annotation. Now comes the interesting part. We are going to need a custom implementation of akka.actor.Props class:

package org.honeysoft.akka.di;

import akka.actor.Props;
import akka.actor.UntypedActorFactory;
import org.springframework.context.ApplicationContext;

public class DependencyInjectionProps extends Props {
    /**
     * No-args constructor that sets all the default values.
     */
    public DependencyInjectionProps(ApplicationContext applicationContext, Class<?> actorClass) {
        super(new SpringUntypedActorFactory(actorClass, applicationContext));
    }

    /**
     * Java API.
     */
    public DependencyInjectionProps(ApplicationContext applicationContext, UntypedActorFactory factory) {
        super(new SpringUntypedActorFactory(factory, applicationContext));
    }
}

The interesting part here is our SpringUntypedActorFactory which is implemented as follows:

package org.honeysoft.akka.di;

import akka.actor.UntypedActor;
import akka.actor.UntypedActorFactory;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.ApplicationContext;

import java.lang.reflect.Field;

import static org.fest.reflect.util.Accessibles.setAccessible;
import static org.fest.reflect.util.Accessibles.setAccessibleIgnoringExceptions;

public class SpringUntypedActorFactory implements UntypedActorFactory {

    private final DependencyInjectionFactory dependencyInjectionFactory;

    private final ApplicationContext applicationContext;

    public SpringUntypedActorFactory(Class<?> actorClass, ApplicationContext applicationContext) {
        this.dependencyInjectionFactory = new DefaultUntypedActorFactory(actorClass);
        this.applicationContext = applicationContext;
    }

    public SpringUntypedActorFactory(UntypedActorFactory customFactory, ApplicationContext applicationContext) {
        this.dependencyInjectionFactory = new SpecificUntypedActorFactory(customFactory);
        this.applicationContext = applicationContext;
    }

    private interface DependencyInjectionFactory {
        UntypedActor createAndInject();
    }


    private abstract class AbstractUntypedActorFactory implements DependencyInjectionFactory {

        @Override
        public final UntypedActor createAndInject() {
            try {
                UntypedActor untypedActor = create();

                Class<?> aClass = getActorClass();
                for (Field field : aClass.getDeclaredFields()) {

                    if (field.getAnnotation(Autowired.class) != null) {
                        boolean accessible = field.isAccessible();
                        try {
                            setAccessible(field, true);
                            field.set(untypedActor, applicationContext.getBean(field.getType()));
                        } catch (IllegalAccessException e) {
                            throw new IllegalStateException("Unable to create actor instance", e);
                        } finally {
                            setAccessibleIgnoringExceptions(field, accessible);
                        }
                    }
                }
                return untypedActor;

            } catch (InstantiationException e) {
                throw new IllegalStateException("Unable to create actor instance", e);
            } catch (IllegalAccessException e) {
                throw new IllegalStateException("Unable to create actor instance", e);
            }

        }

        protected abstract Class<?> getActorClass();

        protected abstract UntypedActor create() throws InstantiationException, IllegalAccessException;

    }

    private final class SpecificUntypedActorFactory extends AbstractUntypedActorFactory {

        private final UntypedActorFactory specificFactory;
        private volatile Class<?> actorClass;

        private SpecificUntypedActorFactory(UntypedActorFactory specificFactory) {
            this.specificFactory = specificFactory;
        }

        @Override
        protected Class<?> getActorClass() {
            return actorClass;
        }

        @Override
        protected UntypedActor create() throws InstantiationException, IllegalAccessException {
            UntypedActor untypedActor = (UntypedActor) specificFactory.create();
            actorClass = untypedActor.getClass();
            return untypedActor;
        }
    }

    private final class DefaultUntypedActorFactory extends AbstractUntypedActorFactory {
        private final Class<?> actorClass;

        public DefaultUntypedActorFactory(Class<?> actorClass) {
            this.actorClass = actorClass;
        }

        @Override
        protected Class<?> getActorClass() {
            return actorClass;
        }

        @Override
        protected UntypedActor create() throws InstantiationException, IllegalAccessException {
            return (UntypedActor) actorClass.newInstance();
        }
    }

    /**
     * This method must return a different instance upon every call.
     */
    @Override
    public UntypedActor create() {
        return dependencyInjectionFactory.createAndInject();
    }
}

Inside our custom SpringUntypedActorFactory is a Strategy pattern which allows us to inject Spring context available beans in an actor fields annotated with @Autowired.

Well, that’s almost all. Now we need a bootstrap component and we are going to provide one using XML-less Spring configuration:

package org.honeysoft.akka;

import akka.actor.ActorRef;
import akka.actor.ActorSystem;
import org.honeysoft.akka.actor.BusinessActor;
import org.honeysoft.akka.di.DependencyInjectionProps;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.DependsOn;

@Configuration
@ComponentScan({"org.honeysoft.akka.service"})
public class Bootstrap {

    public static final String BUSINESS_ACTOR = "honeysoft-business-actor";
    public static final String ACTOR_SYSTEM = "honeysoft-actor-actorSystem";
    private ActorSystem actorSystem;

    @Autowired
    private ApplicationContext applicationContext;

    @Bean(name = ACTOR_SYSTEM, destroyMethod = "shutdown")
    public ActorSystem actorSystem() {
        actorSystem = ActorSystem.create(ACTOR_SYSTEM);
        return actorSystem;
    }

    @Bean(name = BUSINESS_ACTOR)
    @DependsOn({ACTOR_SYSTEM})
    public ActorRef businessActor() {
        return actorSystem.actorOf(//
                new DependencyInjectionProps(applicationContext, BusinessActor.class), BUSINESS_ACTOR);
    }
}

Oh, you can also inject our BusinessActor in another Spring enabled service (or component in general) like this:


import akka.actor.ActorRef;
import org.honeysoft.akka.Bootstrap;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.annotation.Qualifier;
import org.springframework.stereotype.Service;

@Service
public class MyCoolService {

    @Autowired
    @Qualifier(Bootstrap.BUSINESS_ACTOR)
    private ActorRef businessActor;
    
    public void doSomething() {
       businessActor.tell("message"); 
       // more logic goes here ...
    }
}

That was all folks. Now it’s up to you to leave a comment or contribute on GitHub.

 
8 Comments

Posted by on August 5, 2012 in AKKA, FEST-Reflect, Java, Maven, Spring

 

Tags: , ,

Configuring Jetty with exploded web archives

Abstract : Having a great number of useful features, Jetty is one of the most popular servlet containers around. In this post we are going to prepare our test-bed with Jetty using exploded web archives (WAR) without any integrated development environment (IDE) plugins (such as IntelliJ Jetty integration plug-in or Eclipse Jetty Plugin).

Goal : Prepare a Jetty-enabled test-bed using exploded WAR content

Acknowledgement : My gratitude goes to the open source community and to the following people:

Arthur Kahn for presenting me with this challenge and for his help

Step 1 : Download Jetty and extract the Jetty archive in a convenient for you directory. I’m going to use Jetty version 8.1.4 but hopefully this post will be still valid for other versions.

Step 2 : Let’s say you’ve extracted Jetty in a directory called jetty_home. Make a copy of jetty.xml, called jetty-exploded-web.xml. You can find jetty.xml in jetty_home/etc and you should place jetty-exploded-web.xml there as well.

Step 3 : Make a directory under jetty_home called exploaded-context-deploy. We will put the web application context files of our web projects in this directory.

Step 4 : Add the following few lines to jetty-exploded-web.xml just before the closing tag:

    <!-- =========================================================== -->
    <!-- exloded web archives options                                -->
    <!-- =========================================================== -->
    <Call name="addLifeCycle">
        <Arg>
            <New class="org.eclipse.jetty.deploy.ContextDeployer">
                <Set name="contexts">
                    <Ref id="Contexts"/>
                </Set>
                <Set name="configurationDir">exploaded-context-deploy</Set>
                <Set name="scanInterval">1</Set>
            </New>
        </Arg>
    </Call>

Step 5 : Say we have two web apps: web-app-1 and web-app-2. We are going to put the web context files of these web applications in the jetty_home/exploaded-context-deploy directory. Both context files are quite similar except for the web app names, thus I’ll post the content of web-app-1.xml only:

<?xml version="1.0"  encoding="UTF-8"?>
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "http://www.eclipse.org/jetty/configure.dtd">
<Configure class="org.eclipse.jetty.webapp.WebAppContext">
    <Set name="contextPath">/web-app-1</Set>
    <Set name="resourceBase">/absolute/path/to/web-app-1</Set>
</Configure>

Step 6 : Comment the line etc/jetty.xml in the jetty_home/start.ini file and add the line etc/jetty-exploded-web.xml. Here is an example of start.ini file:

#===========================================================
# Start classpath OPTIONS.
# These control what classes are on the classpath
# for a full listing do
#   java -jar start.jar --list-options
#-----------------------------------------------------------
OPTIONS=Server,jsp,jmx,resources,websocket,ext,plus,annotations,overlay
#-----------------------------------------------------------

#===========================================================
# Configuration files.
# For a full list of available configuration files do
#   java -jar start.jar --help
#-----------------------------------------------------------
etc/jetty-jmx.xml
#etc/jetty.xml
etc/jetty-exploded-web.xml
etc/jetty-annotations.xml
# etc/jetty-ssl.xml
# etc/jetty-requestlog.xml
etc/jetty-deploy.xml
#etc/jetty-overlay.xml
etc/jetty-webapps.xml
etc/jetty-contexts.xml
etc/jetty-testrealm.xml

Step 7 : In order to run Jetty on port 8090 you have to execute the following from jetty_home:

java -Djetty.port=8090 -jar start.jar

Note that if you don’t provide the -Djetty.port=8090, Jetty will run on port 8080 by default.

Hot deploy : Note that Jetty is not going to automatically detect re-compiled Java classes, so one way to tell Jetty to reload a web app is to add a small change to the web app’s context file. For example if you have re-compiled web-app-1 adding a new line to web-app-1.xml web context file and saving it will be enough for telling Jetty to reload the project.

Remote debugging : If you want to attach a debugger (i.e. when using Eclipse, IntelliJ, etc.) to Jetty on port 8008 you have to run Jetty as follows:

java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8008 -jar start.jar

Extra classpaths : You can specify extra class paths for your web application by indicating this in the web context file, as follows:

<Configure class="org.eclipse.jetty.webapp.WebAppContext">
 ...
 <Set name="extraClasspath">/extra/classes,/extra/extra.jar</Set>
 ...
</Configure>
 
Leave a comment

Posted by on July 22, 2012 in Jetty

 

Tags: ,