Poster taggade med ‘java ee’

Sida 1/2:12

När ett test skrivs för en klass som har beroenden till en datakälla, en extern service eller bara en annan klass är mockning ofta väldigt användbart. Ibland kan detta leda till att produktionskod anpassas för att det ska gå att skriva dessa tester. Nedan är exempel på ett test som testar en service som använder en entity manager.

package se.cygni.blog;

import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.verify;

import javax.persistence.EntityManager;

import org.junit.Before;
import org.junit.Test;

public class BlogServiceTest {

    private BlogService service;
    private EntityManager entityManager;

    @Before
    public void setup() {
        entityManager = mock(EntityManager.class);
        service = new BlogService(entityManager);
    }

    @Test
    public void addEntry() {
        Entry entry = new Entry("title", "text");

        service.addEntry(entry);

        verify(entityManager).persist(entry);
    }

}

Testet i exemplet är relativt enkelt och verifierar endast att persist anropas i addEntry och ger oss följande kod för ett Spring-baserat projekt:

package se.cygni.blog;

import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;

import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

@Service
public class BlogService {

    @PersistenceContext
    private EntityManager entityManager;

    public BlogService() {
    }

    protected BlogService(EntityManager entityManager) {
        this.entityManager = entityManager;
    }

    @Transactional
    public void addEntry(Entry entry) {
        entityManager.persist(entry);
    }

}

För att kunna använda en mockad entityManager har vi lagt till en konstruktor som tar en EntityManager som BlogService sedan kan använda. Använder vi dessutom ”field injection” är vi tvugna att lägga till en no-args-konstruktor. Alternativt hade vi kunnat lägga till en setter istället.

    protected void setEntityManager(EntityManager entityManager) {
        this.entityManager = entityManager;
    }

Det är väl antagligen inte så illa att behöva lägga till konstruktorer alternativt setters även om det blir värre när en klass har flera beroenden. Däremot känns det ju lite onödigt när både Spring och Java EE numera stödjer field injection. Det går ju att köra enhetstesterna med till exempel Spring och låta Spring injicera alla beroenden. Detta anses dock inte helt lämpligt för enhetstester utan lämpar sig bättre för integrationstester. Istället kan Mockito ta hand om injicering, genom att köra testerna med MockitoJUnitRunner och använda annotationerna @Mock och @InjectMocks. Mockito fungerar då i princip som en enkel IOC-container och några extra konstruktorer eller setters behövs inte.

package se.cygni.blog;

import static org.mockito.Mockito.verify;

import javax.persistence.EntityManager;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.runners.MockitoJUnitRunner;

@RunWith(MockitoJUnitRunner.class)
public class BlogServiceTest {

    @Mock
    private EntityManager entityManager;

    @InjectMocks
    private BlogService service = new BlogService();

    @Test
    public void addEntry() {
        Entry entry = new Entry("title", "text");

        service.addEntry(entry);

        verify(entityManager).persist(entry);
    }
}

Nyligen läste jag ett intressant blogginlägg där Spring jämfördes med Java EE 6. Författaren drar slutsatsen att det numera är minst lika enkelt att utveckla en applikation för Java EE-plattformen som för Spring. Då Spring, Spring MVC inkluderat, är väldigt populärt blev jag nyfiken på hur detta kan integreras med Java EE för att lättare dra nytta av allt som en Java EE-container kan erbjuda. Det visade sig att detta var förbluffande enkelt, till exempel går det utan ytterligare Spring-konfiguration direkt injicera en Session Bean i en Spring-controller.

@Controller
public class MyController {

    @EJB(mappedName="java:module/MyService")
    private MyService myService;

    @RequestMapping(value = "/", method = RequestMethod.GET)
    public String home(Model model) {
        model.addAttribute("message", myService.getMessage());
        return "home";
    }
}

Nyckeln till att injektionen med @EJB-annotation fungerar, i exemplet ovan, är att mappedName används. Spring utför då en JNDI-lookup på det angivna JNDI-namnet. Eftersom JNDI har standardiserats i Java EE 6 är dessutom namnen portabla mellan applikationsservrar. Stödet för Java EE 6 kommer säkerligen förbättras i framtida versioner av Spring så det finns bra defaults för ejb-lookups med JNDI.

En annan spännande detalj med detta exempel är att MyService inte behöver vara ett interface eftersom Java EE 6 inte kräver detta för lokala session beans. Dessutom kan session beans paketeras tillsammans med resten av webbapplikationen i war-arkivet. D.v.s. det behövs ingen ejb-jar och inget EAR-arkiv.

Läs hela artikeln på Java Code Geeks.

Detta inlägg visar hur Dependency Injection (DI) kan användas med hjälp av CDI, Guice och Spring. Depencency Injection beskrivs bland annat i Robert Buréns artikel Spring som DI-ramverk. Exemplet i detta inlägg är kraftigt influerat av en artikel jag läste på DZone.

Spring och Guice är två av de vanligaste ramverken för DI. Dessa ramverk kan användas i standalone-, web- och enterprise-applikationer. CDI är ett standardiserat sätt för DI som kommer med Java EE 6 och kan tills vidare därför endast användas i en enterprise-miljö. Spring erbjuder dock stöd för några av de features som definieras av CDI.

Läs mer >>

Cygni är ett IT-konsultbolag med drygt 40 anställda som grundades 2006. Vi erbjuder expertis inom agil systemutveckling på moderna plattformar. Den genomsnittlige Cygnikonsulten är 35 år, civilingenjör i datateknik och har 12 års professionell erfarenhet av systemutveckling. Men den främsta styrkan sitter varken i erfarenhet eller utbildning. Den sitter i engagemanget att ständigt vilja utvecklas och bli en bättre konsult.

Med en stadig förankring i vår systemutvecklingsexpertis kan Cygni utföra konsultuppdrag i alla branscher i behov av avancerat systemstöd. Cygnis kunder finns idag främst inom finans, media, retail, telekom och spel.

Det som utmärker Cygni är vår selektiva rekryteringsprocess. Vi sätter aldrig kvantitativa tillväxtmål eftersom de skulle kunna komma i konflikt med våra kvalitetsmål. Sedan starten 2006 har Stockholms främsta konsulter inom agil systemutveckling handplockats, bland annat genom branschens tuffaste tekniktester. Det har gett oss en stark företagsgemenskap, obefintlig personalomsättning, nöjda kunder och ett mycket välfungerande internt kompetensutbyte.

Cygnis kontor är centralt beläget på Sturegatan 34 i Stockholm med utsikt över Humlegården. De flesta uppdrag som Cygni utför är på plats hos våra kunder i Stockholmsområdet men kontoret fungerar som en naturlig samlingsplats för konsultmöten, afterwork och andra aktiviteter.

Karta till Cygnis kontor
Cygni
Sturegatan 34
114 36 Stockholm
Tel: 08 459 93 30
E-post: info@cygni.se 

Cygni sponsrar BRIS i deras arbete att stödja utsatta barn. Sedan 2012 är Cygni ett av BRIS guldföretag.

Följ oss via LinkedIn, Twitter eller Facebook

Cygni på LinkedIn


Rena kommandoradsapplikationer i Java kanske inte hör till vanligheterna nu mera, men det finns tillämpningar. Jag håller för tillfället på med ett sådant program. Det är en slags (av prestandaskäl) multitrådad övervakningsapplikation. Varje tråd ligger och pollar en databas efter något att arbeta med i ganska täta (några sekunders) intervall. När tråden hittar något att processa, så pratar den bl.a. JDBC med en stordatorapplikation.

Denna typ av beteende skulle vara ganska svårt att få till inom ramen för en appserver. Att starta trådar är ju inte aktuellt. Att använda Quartz eller ha ett cron-jobb som anropar en EJB via wget eller liknande skulle vara möjligt men verkar lite krystat, speciellt då den pollar så pass ofta.

En vanlig Java-applikation fick det bli, således. Vad bör man tänka på när man skriver en sådan applikation? Den är ju nästan som en slags server, som skall köra kontinuerligt. Den får inte gå ner så lättvindigt och den kommer sannolikt köra på en Linuxburk i ett serverrum någonstans utan något egentligt användargränssnitt. Här kommer således några tips för den standalone-inriktade.
Läs mer >>

EJB 3.0 är den nu gällande versionen av Java Enterprise Beans(EJB) arkitekturen som ingår i Java EE 5. Syftet med EJB 3.0 är att förbättra arkitekturen för EJB och minska komplexiteten för utvecklaren av EJB applikationer. Detta innebär tex följande förbättringar:

  • Annoteringar, det finns ett gäng med annoteringar som man kan använda sig utav för att förenkla arbetet. Dessa annoteringar minskar antalet klasser och interface som man måste skapa och man behöver inte skapa någon deployment descriptor (om man inte vill).
  • Defaulta värden, man skall slippa specifiera en massa vanliga förväntade beteenden och krav från EJB-containern.
  • Inkapsling av beroenden och JNDI åtkomst via annoteringar och dependency injection (DI)
    Businessinterfacet för en sessionsböna kan vara ett vanligt Java-interface, det behöver inte vara av typen EJBObject, EJBLocalObject eller javax.rmi.Remote
  • Home-interfacet behövs inte längre för sessionsbönor.
  • Minskning av krav av användning av checked exceptions
  • En interceptor funktionalitet finns för sessions- och message-driven-bönor.
  • Entitetsbönor har fått en helt egen specifikation, Java Persistence API (JPA), är numera vanliga POJO’s.

Det finns ett par olika typer av EJB:er, sessionsbönor och message-driven-bönor. Sessionsbönorna kommer i två olika smaker, Stateless och Stateful. Entitetsbönorna har ju som sagt ersatts med JPA entiteter. Jag tänkte gå igenom dessa med små korta exempel. Läs mer >>

JRuby — Java-implementationen av programspråket Ruby — verkar ha uppnått en oerhört viktig milstolpe: den senaste betaversionen, JRuby 1.1beta1, är nu lika snabb eller snabbare än standardimplementationen av Ruby. Ok, det är visserligen bara en beta-version men det lovar mycket gott inför nästa release, och JRuby-tåget har ångat på i stabilt hög fart den senaste tiden så det skulle förvåna mig om inte den riktiga 1.1-releasen släpps om inte allt för länge.

Vad innebär då detta för oss som huvudsakligen befinner oss i Java-världen?

Om JRuby fortsätter förbättra sin prestanda (vilket jag känner mig övertygad om att de kommer att göra, med tanke på vilka framsteg de gjort det senaste året) så kommer snart JRuby i praktiken bli den dominerande plattformen att utveckla och produktionssätta Ruby-applikationer på. Det innebär att hela Ruby-communityn, och framför allt kanske hela Ruby on Rails-communityn kommer att flytta in och bli sambo med oss i Java-huset. Jag förväntar mig mycket bra saker från den korspollineringen:

  • Verktygen kommer att bli bättre, både för Java- och Ruby-utvecklare. Ruby behöver ännu mer mogna IDE-funktioner (vilket i och för sig redan är på god väg att utvecklas i såväl Eclipse, NetBeans och IntelliJ). Java, å sin sida, kanske kan komma att dra nytta av grejer som Capistrano och Rake.
  • Det kommer att vara ett okontroversiellt alternativ även för Java-utvecklare att välja Ruby on Rails som webbplattform, så länge som applikationen passar för det.
  • Rails-applikationer kan, förpackade i war-filer, deployas och administreras sida vid sida med Java EE-applikationer utan konstigheter.
  • Det kommer att bli naturligt för Java-applikationer att använda Ruby som skriptspråk eller DSL:er för avancerade användare.

Coola grejer hela vägen!

Under många år har debatten pågått om hur Java Modules ska realiseras. På ena sidan står OSGi-anhängarna (JSR 291) med IBM i spetsen och på andra sidan står Sun (JSR 277 och JSR 294). Nu har debatten tagit ny fart i och med att Java EE 6 är på gång (JSR 316).

Kolla in nedanstående länkar för lite information om vad statusen är på dessa JSR:er och hur 277:an egentligen hänger ihop med 291:an.

ICA är Sveriges ledande detaljhandelsföretag och är också branschledande när det gäller att stödja verksamheten med ett modernt och effektivt IT-stöd.

Cygnis expertkonsulter inom Java EE, integration och systemarkitektur deltar i arbetet att designa och utveckla ett flertal verksamhetskritiska system på ICA.

Sida 1/2:12