Stacktrace

Sida 1 av 2312345...1020...Sista »

Om man vill använda AutoCloseable i JDK 1.7 och högre ser man ganska snabbt att metoden close kastar Exception:

public interface AutoCloseable {
  void close() throws Exception;
}

Detta gör en inte glad om man vill undvika checked exceptions. En implementation enligt följande:

public class Resource implements AutoCloseable {
  @Override
  public void close() throws Exception {
    //stäng något
  }
}

leder nämligen till att man måste hantera Exception på något sätt i try-blocket:

try(Resource r = new Resource()) {
   //gör något med r
} catch(Exception e) {
  //hantera e som vi inte ville ha från början
}

Nyckelinsikten här är att man kan overrida metoder som slänger checked exceptions med sådana som inte gör detta (se JLS §8.4.8.3). Just detta omnämns även i dokumentationen till AutoCloseable.html#close(). Så vi kan implementera utan att slänga exceptions:

public class Resource implements AutoCloseable {
  @Override
  public void close() {
    //stäng något
  }
}

Detta gör att vi kan ha en try utan checked-exception hantering:

try(Resource r = new Resource()) {
   //gör något med r
}

Mission accomplished.

EDIT:
Tack till Mats Andersson som påpekade att man kunde ta bort throws-deklarationen helt istället för att kasta ett mer specifikt fel (RuntimeException).

Neo4j är en NoSQL-databas eller närmare bestämt en grafdatabas. Det är en javabaserad open source-produkt och utvecklarna bakom Neo4j beskriver den så här:

Embedded, disk-based, fully transactional Java persistence engine that stores data structured in graphs rather than in tables

Detta inlägg beskriver kort några av de features som Neo4j erbjuder och en kortare introduktion till frågespråket Cypher som används för att hitta rätt i grafen.

Läs mer >>

För att minska på fingerslitaget vid inloggning till flera maskiner på olika domäner via SSH kan man nyttja resolv.conf och .ssh/config. Med hjälp av dessa kan man sätta default-användarnamn och även undvika att skriva olika användarnamn för olika domäner.

I det tänkta scenariot har du fått ett login på en subdomän hos företaget example.com. Användarnamnet är ett annat än ditt normala login och du behöver logga in på flera servrar, så många att det blir opraktiskt att lista alla i .ssh/config. Målet med setupen är att istället för att behöva skriva:

ssh exampleuser@exampleserver0.long.subdomain.example.com

och

ssh exampleuser@exampleserver1.long.subdomain.example.com

bara kunna skriva följande:

ssh exampleserver0

och

ssh exampleserver1

För att undvika att behöva skriva hela domännamnen lägger vi till en search-entry i resolv.conf. I Debian genereras resolv.conf av programmet resolvconf, så därför editerar vi istället /etc/resolvconf/resolv.conf.d/base och lägger till raden:

search long.subdomain.example.com

Du kan sedan generera om resolv.conf med kommandot ”resolvconf -u”. Detta gör att du kan ansluta till servrarna utan att ange hela domännamnet, dvs att du kan ansluta med t.ex:

ssh exampeluser@exampleserver0

För att knyta det avvikande användarnamnet till denna subdomän använder vi oss sedan av .ssh/config där vi lägger till raderna:

Host exampleserver*
  User exampleuser

På detta sätt har vi nått vårt mål. Dock väljs användarnamnet ”exampleuser” så fort ett hostname börjar på ”exampleserver”. Varför gjorde vi så? Jo, det visar sig att .ssh/config-entries inte matchas mot fulla domännamn, utan endast mot argumentet som ges till ssh (se ‘canonicalized host name’ i ssh_config).

På grund av denna begränsning måste vi använda mönstermatchning på endast hostnamnet. Om hostnamnen inte skiljer på ett sådant sätt att mönstermatchning lämpar sig är ett ett annat sätt att komma runt detta att matcha mot del-domäner. Genom att till exempel konfigurera resolvconf med:

search subdomain.example.com

kan du konfa ssh med:

Host *.long
  User exampleuser

Observera att denna lösning gör att du får logga in till servrarna med:

ssh exampleserver0.long

och

ssh exampleserver1.long

Om man driftar sitt eget Git-repo (och därmed saknar det inbyggda stödet i t.ex. GitHub och BitBucket) är det enkelt att lägga in kopplingar (hooks) så att ett bygge automatiskt startas vid commit. På så sätt kan man undivka att byggservern kontinuerligt måste polla repot efter förändringar. Detta är framför allt till stor nytta om man vill ha en snabbare återkoppling mellan incheckning och automatiska tester m.m.

Nedan visar jag hur man automatiskt kan trigga två olika typer av Jenkins-byggen från Gits post-receive hook. När en git-tag pushas upp triggas ett parametriserat release-bygge och när ett gren-huvud uppdateras triggas ett vanligt dev-bygge.

I det första fallet triggas bygget direkt. I det andra fallet säger vi till Jenkins att det är dags att polla repot för ett visst jobb. Man kan ju naturligtvis tänka sig att även dev-byggen är parametriserade byggen, men detta var vad som behövdes när jag skrev hooken.

Alla som jobbar med serverapplikationer i Java har väl någon gång stött på behovet av en connection pool. Länge var Apache DBCP den dominerande poolen, eventuellt med c3p0 som alternativ. Båda dessa har sina egna mer eller mindre obskyra problem.

För en del år sedan dök det så upp en ny pool, som helt enkelt heter JDBC Connection Pool. Den ingår numera som en modul i Tomcat, är betydligt modernare än sin föregångare och den skall fungera med alla containrar (Tomcat, Jetty, JBoss etc). Den har dessutom en hel uppsjö inställningar, skall fungera bättre på multi-core-maskiner och är enklare i sin interna uppbyggnad än DBCP. Så här ser Maven-beroendet ut just nu:

<dependency>
   <groupId>org.apache.tomcat</groupId>
   <artifactId>tomcat-jdbc</artifactId>
   <version>7.0.26</version>
</dependency>

Ett vanligt problem med databaskopplingar är connections som ”dör” på olika sätt. Routrar och brandväggar konfigureras ibland så att kopplingar bara får ha en viss livslängd, och samma sak gäller databasservrar – och så har vi ju ibland helt vanliga nätverksproblem också. Det traditionella sättet att lösa det på är att använda en så kallad ”validation query”. Det innebär att connection-poolen, t.ex. innan den delar ut en connection från poolen, skickar en testfråga till databasen, t.ex. SELECT 1. Exakt vilken fråga som är lämplig beror på vilken databas det är, och t.ex. MySQL har en speciell fråga avsedd för detta ändamål.

Min erfarenhet är att detta inte alltid funkar något vidare. Beroende på vilket tillstånd TCP-kopplingen har så kan en sådan fråga hänga sig en lång stund, vilket leder till att poolen svälter. Det man normalt vill uppnå är att poolen bara kastar connections som inte svarar snabbt, och skapar nya i stället. JDBC Connection Pool tillsammans med Java 1.6 har en trevlig lösning på det, och nu börjar vi äntligen närma oss min poäng!

Sedan Java 1.6 finns en metod i java.sql.Connection som heter isValid. Denna låter JDBC-drivern självt avgöra om en koppling kommer att fungera, i stället för att använda mystiska validation queries. Metoden tar som parameter en timeout i sekunder som är separat från övriga timeouts. Detta passar som handen i handsken med en inställning i JDBC Connection Pool som heter validatorClassName. Man sätter validatorClassName till namnet på en klass som man själv implementerar, och poolen anropar den för att kontrollera om en connection får användas, innan den ger ut den till klientkoden. Så här ser min variant på validator-klass ut:

public class JDBCValidator implements Validator {
    private static final Logger LOGGER = LoggerFactory.getLogger(JDBCValidator.class);

    @Override
    public boolean validate(Connection connection, int validateAction) {
        LOGGER.trace("validate called for connection {}, validateAction = {}",
                  connection, validateAction);
        try {
            // 10 seconds should do it
            if (connection.isValid(10)) {
                LOGGER.trace("Connection {} is VALID", connection);
                return true;
            }
            LOGGER.warn("Invalid DB connection detected");
            return false;
        } catch (SQLException e) {
            LOGGER.warn("Invalid DB connection detected", e);
            return false;
        }
    }
}

Tack vare loggningen så får man stenkoll på hur databasen och nätet verkar agera, och det funkar dessutom varje gång!

Under några månaders tid har jag stört mig på att Ubuntu återställer tangentbindningar som jag gjort när datorn bootas om. T.ex. så krockar Ubuntus Alt+F7 Move Window med Intellijs IDEAs find. Det verkar vara en bug i 12.10 och 13.04 som introducerade detta.

Som temporär lösning på problemet har jag lagt följande i filen $HOME/.gsettings som jag sedan läser in i $HOME/.bashrc (tidigare skrev jag att man kunde lägga inläsningen i .profile istället, men det verkar som att Ubuntu återställer gsettings efter att .profile körts).

# Check what bindings are available
# gsettings list-recursively  |grep key|less

gsettings set org.gnome.desktop.wm.keybindings move-to-workspace-left "['<Shift><Control><Alt>Left']"
gsettings set org.gnome.desktop.wm.keybindings move-to-workspace-right "['<Shift><Control><Alt>Right']"
gsettings set org.gnome.desktop.wm.keybindings move-to-workspace-up "['<Shift><Control><Alt>Up']"
gsettings set org.gnome.desktop.wm.keybindings move-to-workspace-down "['<Shift><Control><Alt>Down']"

gsettings set org.gnome.desktop.wm.keybindings switch-to-workspace-left "['<Control><Super><Alt>Left']"
gsettings set org.gnome.desktop.wm.keybindings switch-to-workspace-right "['<Control><Super><Alt>Right']"
gsettings set org.gnome.desktop.wm.keybindings switch-to-workspace-up "['<Control><Super><Alt>Up']"
gsettings set org.gnome.desktop.wm.keybindings switch-to-workspace-down "['<Control><Super><Alt>Down']"

gsettings set org.gnome.settings-daemon.plugins.media-keys screensaver '<Super>l'
gsettings set org.gnome.desktop.wm.keybindings begin-move "['<Super>F7']"
gsettings set org.gnome.desktop.wm.keybindings begin-resize "['<Super>F8']"
gsettings set org.gnome.desktop.wm.keybindings show-desktop "['<Super>d']"

gsettings set org.gnome.desktop.wm.keybindings toggle-shaded "['disabled']"
if [ -f "$HOME/.gsettings" ]; then
    . "$HOME/.gsettings"
fi

Som nyexad webbprogrammerare var det inte helt lätt att slänga sig in i certifieringsdjungeln. Det var många nya begrepp och ofta förstod jag varken frågorna eller förklaringarna när jag först började läsa. Även om jag hade haft Java som huvudspråk under min utbildningen var jag inte så van vid att prata om språket och jag hade definitivt inte ställts inför frågor om regler på hur saker och ting fungerar beroende på om man gör si eller så. Vissa klasser och metoder hade jag inte stött på tidigare och då blev de kodexempel, som egentligen skulle underlätta, ett hinder mer än ett hjälpmedel. Men skam den som ger sig… nu har jag min Java Programmer-certifiering. Det här är mina tips för hur du lyckas! Läs mer >>

Vagrant är ett verktyg för att på ett smidigt sätt via kommandoraden kunna hantera olika virtuella boxar (Oracle VirtualBox). Vagrant används för att skapa och konfigurera lättviktiga, reproducerbara och portabla utvecklingsmiljöer.

Grundkrav

Sätt igång

Då är vi redo att börja. För att skapa en ny virtuell box med Ubuntu 12.04 LTS kör du bara följande kommandon:

$ vagrant box add precise64 http://files.vagrantup.com/precise64.box
$ mkdir -p testenv
$ cd testenv
$ vagrant init precise64
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.

Kommandot på rad 1 laddar ned en färdig box med Ubuntu 12.04 LTS. Denna box namnges till precise64 och kan sedan återanvändas för flera virtuella maskiner. Nedladdning sker endast en gång. Rad 2 och 3 skapar en katalog där din virtuella maskin sparas. Kommandot på rad 4 skapar en så kallad Vagrantfile som beskriver hur just din box ska konfigureras (bland annat port forwarding). Vagrant själva skriver att:

A Vagrantfile is to Vagrant as a Makefile is to Make

Innehållet i vår nyskapade Vagrantfile ser ut ungefär så här:

Vagrant::Config.run do |config|
  # Setup the box
  config.vm.box = "precise64"
end

Den katalogen som innehåller Vagrantfile mappas (per default) upp som en shared folder så din maskin och den virtuella boxen kan dela filer där på ett smidigt sätt.

För att sedan starta vår virtuella server används följande kommando:

$ vagrant up

Och för att koppla upp dig via SSH mot servern körs detta kommando:

$ vagrant ssh

När du kopplat upp dig via SSH kan du accessa dina delade filer i foldern /vagrant

Om du gör förändringar av din virtuella box som du sedan vill återanvända kan du skapa egna paket (boxar) som du senare kan utgå från. Detta sker enkelt via kommandot:

$ vagrant package

Då skapas en box – package.box – som kan läggas till bland dina befintliga boxar med hjälp av

$ vagrant box add my_box /path/to/package.box

När du känner att du är färdig med din virtuella box kan du använda följande kommando för att stänga ned maskinen (och därmed spara CPU/RAM):

$ vagrant halt

Alternativt, om du bara vill göra en suspend (det går snabbare att starta maskinen senare isf):

$ vagrant suspend

För att starta maskinen efter halt eller suspend är det bara att köra:

$ vagrant up

Om du vill ta bort din virtuella box från disken helt och hållet kör du bara kommandot:

$ vagrant destroy

Vagrant erbjuder också stöd för mer avancerade features såsom provisioning mha Chef eller Puppet. Allt detta finns att läsa på Vagrants hemsida.

Så, superenkel hantering av virtuella boxar med hjälp av Vagrant – rekommenderas varmt!

Lathund:

$ vagrant init Skapar en Vagrantfile
$ vagrant up Startar en virtuell box
$ vagrant halt Stoppar den virtuella boxen
$ vagrant suspend Pausar den virtuella boxen
$ vagrant destroy Stoppar och tar bort den virtuella boxen från disken
$ vagrant package Skapar ett nytt box-paket baserat på en befintlig box
$ vagrant box add my_box /path/to/package.box Lägger till en ny box-typ (my_box) som pekas ut via path eller HTTP
$ vagrant box list Listar tillgängliga boxar för din lokala miljö. En lista över boxar nedladdningsbara boxar finns här.

I den här artikeln ska jag skriva lite om EclEmma, en plugin till Eclipse för testramverket EMMA. Pluginen är inte på något sätt ny, men inte desto mindre användbar. Verktyget är till för att visa dig hur väl dina tester täcker din kod, s. k. test coverage.

Även om man utvecklar enligt TDD (Test Driven Development) så kan det vara bra att få ett kvitto på att ens egen bild av testerna stämmer överens med verkligheten. För den som inte utvecklar testdrivet är EMMA en riktig ”eye-opener” för att, allt som oftast, inse att det behövs fler tester.

Jag fortsätter med ett exempel av Hello World-kaliber. Ladda gärna hem pluginen själv och prova samtidigt, projektets hemsida är www.eclemma.org där du kan välja manuell nerladdning eller använda länken till projektets update-site, samt att det finns tillgängligt i Eclipse Marketplace.

Då kör vi. Testet ser ut såhär:

public class EmmaTest {

 @Test
 public void testGreeter() {
    Greeter greeter = new Greeter();
    Assert.assertEquals("Hello Cygni!", greeter.greet("Cygni"));
 }
}

Och klassen vi ska testa:

public class Greeter {

 public String greet(String name) {
    if(name != null) {
       return "Hello " + name + "!";
    } else {
       return "Who are you?";
    }
 }

 public String greetSimple() {
    return "Hello you!";
 }
}

Att testet inte täcker hela Greeter-klassen har du nog redan insett. Vi låter dock EclEmma sköta analysen.

När EclEmma är installerat dyker ytterligare ett alternativ för att exekvera upp. Sedan tidigare har vi Run as och Debug as, men nu kommer även Coverage as att finnas tillgängligt. Om du kör Java-perspektivet skall också en ikon för detta ha tillkommit (kör du andra perspektiv kan du behöva lägga till ikonen via ”Customize perspective”). Vi kör testet via Coverage as:

Testet körs och vi får upp Coverage-vyn, samt att kodraderna i de klasser där det körts kod kommer att ha fått lite färg. Vi börjar med Coverage-vyn:

Som synes kan vi gå ner på olika nivåer för att tydligare se var det täcker bättre eller sämre. Efter att ha expanderat trädet fullt ut ner på metodnivå ser vi att greetSimple() har 0% täckning och att greet() behöver testas mer för att nå 100%. Metoden greetSimple() tog jag bara med här för att visa på hur användbart det är att kunna se test coverage på metodnivå och på så sätt tydligare identifiera svagheter, men jag låter den vara otestad för det här exemplet.

Om vi öppnar klassen Greeter, så ser ni tydligt vad som är testat och inte:

I greetSimple() är det inte så mycket att tala om, den är röd (no coverage) eftersom vi inte har något test som kör metoden. I greet() är raden med ”Who are you?” röd eftersom vi inte har gjort något anrop där if-satsen utvärderas till false.

Den gröna raden är grön (full coverage) därför att det är den rad som exekverades när metoden returnerade ”Hello Cygni!”, det väntade resultatet av vårt test.

Den gula raden betyder att raden är delvis täckt (partial coverage), en mycket användbar indikator. I det här fallet vet vi att det finns två scenarion för if-satsen. Antingen har argumentet name värdet null, eller så är name skilt från null. I vårt test skickade vi in ”Cygni”, name var alltså skilt från null. EclEmma talar också om för oss hur många fall vi har missat om vi håller muspekaren över diamantikonen bredvid:

Vi skriver ytterligare ett test för att nå 100% test coverage i metoden greet():

@Test
 public void testGreeterNullArg() {
    Greeter greeter = new Greeter();
    Assert.assertEquals("Who are you?", greeter.greet(null));
 }

Resultatet ser nu mycket trevligare ut:

En inställning som är bra att känna till är vilken typ av counter man kör. Hur stor test coverage dina tester har kan variera stort beroende på hur man räknar. I vårt exempel kunde vi se att vi i if-satsen hade två stycken branches. I första testet kördes bara ett anrop där uttrycket i if-satsen var sant (name var skilt från null), vilket innebar att vi täckte en branch av två – branchen där name var null kördes inte. Alltså hade vi i det testet 50% branch coverage på den raden.

Men, om vi istället räknar line coverage, så är siffran 100% eftersom line coverage inte tar hänsyn till vilken typ av kodrad som exekveras, bara att den exekveras. Klicka på den vita nedåtriktade pilen i coverage-vyn för att ändra typ av counter:

Du kan läsa mer om de olika typerna av counters som finns på EclEmma‘s hemsida eller exempelvis Wikipedia.

Två tips innan vi är färdiga:

  1. EMMA och andra liknande verktyg (Cobertura till exempel) finns som plugins till exempelvis Maven och Jenkins, som då genererar en rapport över hur testerna gick i ett bygge. Att ha statistik och rapporter över testresultat och trender i projektet ger en trevlig överblick.
  2. Om du kör ett mörkt tema för Eclipse, vilket inte är särskilt ovanligt, rekommenderar jag att ändra highlight-färgerna för EclEmma, annars är risken stor att du inte ser texten på raderna. Gå till Window -> Preferences -> General -> Editors -> Text Editors -> Annotations och välj mörkare färger för alternativen Full coverage, Partial coverage och No coverage.

Dropwizard är en körmiljö och ett ramverk för att enkelt utveckla små enheter i form av RESTful webtjänster. En stack bestående av bl.a Jetty, Jersey, Jackson, slf4j, JDBI och en föreslagen projektstruktur gör det väldigt lätt att komma igång!

Begrepp

Dropwizard har idenitifierat följande aktörer och entiteter i sin stack:

Configuration

Konfigurationen är till för att hålla miljöspecifika aspekter av tjänsten. Det kan t.ex vara databaskonfiguration eller nödvändiga sökvägar och url:ar. Konfigurationen skrivs i formatet YAML. Genom JSON-annotationer i din klass läser DropWizard automatiskt upp konfigurationen och populerar din konfigurationsklass.

Representation

Detta är de objekt som ska skickas mellan klient och server och är i sin enklaste form vanliga POJOs. Jackson används för serialisering och deserialisering. DropWizard rekommenderar att dessa objekt är immutable.

Resource

Det är resurserna som exponerar REST API:et. Varje resurs och metod har en URI och klassen annoteras med javax.ws.rs.*-typerna för att definiera sökvägar, innehållstyper och metod. DropWizard använder Jersey-implementationen.

Health check

Hälsokontroller är små kodsnuttar som testar att tjänsten är uppe och att allt är som det ska. Status för hälsokontrollerna kan inspekteras via en speciell admin-url. DropWizard skapar automatiskt några hälsokontroller, bl.a en som kontrollerar att databasanslutningen är korrekt (om man har en i sitt projekt).

Service

Servicen ansvarar för att dra igång tjänsten med en konfiguration och med resurserna initialiserade med eventuella beroenden. Detta sker genom en vanlig main-metod(public static void main(String[] args) { ... } ).

I vårt exempelprojekt ser serviceklassen ut så här:

public class MainService extends Service<MainConfiguration> {
    public static void main(String[] args) throws Exception {
        new MainService().run(args);
    }

    @Override
    public void initialize(Bootstrap<MainConfiguration> mainConfigurationBootstrap) {
        mainConfigurationBootstrap.addBundle(new AssetsBundle("/assets/", "/"));
    }

    @Override
    public void run(MainConfiguration config, Environment environment) throws Exception {

        DBI dbi = initDatabaseConnection(config, environment);

        final EventsRepository eventsRepository = dbi.onDemand(EventsRepository.class);
        final ExpensesRepository expensesRepository = dbi.onDemand(ExpensesRepository.class);

        environment.addResource(new EventsResource(eventsRepository));
        environment.addResource(new ExpensesResource(expensesRepository));
    }

    private DBI initDatabaseConnection(MainConfiguration config, Environment environment) throws ClassNotFoundException {

        final DBIFactory factory = new DBIFactory();
        final DBI jdbi = factory.build(environment, config.getDatabaseConfiguration(), "db");

        createTables(jdbi);

        return jdbi;
    }

    private void createTables(DBI dbi) {

        Handle handle = dbi.open();

        handle.execute(EventsRepository.CREATE_TABLE_STATEMENT);

        handle.execute(ExpensesRepository.CREATE_TABLE_STATEMENT);

        handle.close();
    }
}

För dig som är van vid Spring eller något annat DI-ramverk kan det kännas lite konstigt att själv behöva instansiera t.ex resursklasserna (och skjuta in Repository-implementationerna). Eftersom tanken med en DropWizard tjänst är att ansvara för en relativt liten delmängd av ett system så tycker jag inte att detta är särskilt besvärande.

Resurser, dvs REST-tjänsterna, aktiveras genom att lägga till dem till instansen av Environment. Se rad 19-20 ovan.

Komma igång

Checka ut exempelprojektet och bygg:

git clone git://github.com/cygni-stacktrace/dropwizard-sample.git
cd dropwizard-sample
mvn package

Starta tjänsten med kommandot server och filnamnet för konfigurationen:

java -jar target/expenses-1.0-SNAPSHOT.jar server development.yml

Rest-API:et ligger under kontextet /api, en GET-operation för att lista events finns t.ex här: http://localhost:8080/api/event

Admingränssnittet med länk till Health check finns här: http://localhost:8081

Testning

Testning av resurser är en enkel historia med DropWizard. Genom att låta din testklass uttöka ResourceTest kan du lägga till resursen under test så här:

    @Override
    protected void setUpResources() throws Exception {
        eventsRepository = mock(EventsRepository.class);
        addResource(new EventsResource(eventsRepository));
    }

En testmetod:

    @Test
    public void shouldShowOneEvent() throws IOException {
        //given
        Event event = new Event(1, "An event", null);

        given(eventsRepository.findById(event.getId())).willReturn(event);

        //when
        Event result = client().resource("/event/1").get(Event.class);

        //then
        assertThat("event should be returned", result, is(event));
    }

Dropwizard drar igång Jersey och invokerar anropen i testet via en HTTP-klient så hela request/response kedjan går över JSON och HTTP. Detta är bra för då testas även att Jackson kan serialisera och deserialisera dina POJO:s.

Databasstöd

Dropwizard har moduler med stöd för Hibernate och JDBI. I exempelprojektet används JDBI.

Slutsats

Det är väldigt lätt att komma igång med Dropwizard och jag tycker att de valt en vettig stack med hjälpbibliotek. Den föreslagna projektstrukturen och användandet av Maven gör att det fungerar bra i alla stora IDE:er. Att inkludera Health checks direkt från början känns väldigt bra och det är befriande att ha en app som kan köras helt stand-alone (d.v.s den behöver inte deployas i en webcontainer). Jag tycker också att de tänkt till bra kring testningen.

Om man planerar att börja använda Dropwizard i ett större sammanhang behövs dock en strategi för hur tjänster ska kunna versionshanteras samt upptäckas.

Vidare läsning

http://dropwizard.codahale.com

Sida 1 av 2312345...1020...Sista »