Java Bean Validation (JSR 303) definierar en meta-data-modell och ett API för validering av klasser. Implementationer av denna specifikation gör det möjligt att definiera och utföra validering med hjälp av annotationer eller xml. Exemplet nedan illusterar detta för ett användarnamn:
@NotNull
@Size(min = 5, max = 20)
@Pattern(regexp = "[a-zA-Z0-9\\._-]+")
private String userName;
Bean Validation är inte knutet till något speciellt ramverk eller lager. Det finns däremot bra stöd för Bean Validation i flertalet populära ramverk, såsom Hibernate och JSF 2. Dessutom är det enkelt att utföra validering via API:t:
import javax.validation.ConstraintViolation;
import javax.validation.Validation;
import javax.validation.Validator;
import javax.validation.ValidatorFactory;
...
ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
Validator validator = factory.getValidator();
Set<ConstraintViolation<Customer>> constraintViolations = validator.validate(customer);
För att komma igång med ett Bean Validation (Hibernate Validator 4.x är referensimplementationen) i ett Maven-projekt lägg till följande beroenden i din pom:
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-validator</artifactId>
<version>4.2.0.Final</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-jdk14</artifactId>
<version>1.6.1</version>
</dependency>
Används Hibernate eller JSF 2 räcker det oftast med att lägga till ovanstående beroenden så länge de finns tillgängliga i applikationens class path. Används JSF 2 går det till exempel att aktivera validering för ett inmatningsfält på följande sätt:
<h:inputText value="#{customer.age}">
<f:validateBean/>
</h:inputText>
Bean validation stödjer dessutom validering av grupper som gör det möjligt att validera olika aspekter av ett objekt:
@Min(value=15, groups=AgeCheck.class)
private int age;
- cygni
- 19 september 2011
- Kommentering avstängd
Cygni är ett konsultbolag med ambitionen att vara Stockholms bästa arbetsgivare för skickliga systemutvecklare och systemarkitekter. Bland våra kunder finns Skandia, Aftonbladet, Cinnober, LensWay, Eniro, Metro, Com Hem och många andra företag som är ledande inom sin bransch. Cygni har således ingen branschinriktning, vi är specialister på agil systemutveckling och den kompetensen applicerar vi framgångsrikt i många olika branscher.
Cygni består idag av 40 killar och tjejer i åldrarna 25-57. Vi upplever en mycket stark efterfrågan på våra tjänster och söker därför nu 5 stycken seniora javautvecklare/systemarkitekter som trivs i konsultrollen.
De flesta på Cygni är civilingenjörer men det är inget krav. Däremot vill vi att du älskar systemutveckling och har minst fyra års javaerfarenhet. Du ska helst ha jobbat med agil metodik och moderna ramverk som Spring och Hibernate. Som konsult hos oss arbetar du ofta tillsammans med Cygni-kollegor i utmanande och utvecklande uppdrag hos någon av våra kunder i centrala Stockholm. Ett intresse för exempelvis Scala, Groovy och Ruby är meriterande.
Läs gärna mer om oss på cygni.se eller på vår teknikblogg Stacktrace!
- cygni
- 2 februari 2011
- Kommentering avstängd
Stacktrace är Cygnis teknikblogg där vi skriver allt från korta tips till längre artiklar. Genom att följa Stacktrace kommer du att få en god bild av vad Cygni kan och gör.
Klicka
här för att läsa artiklarna!
- cygni
- 2 februari 2011
- Kommentering avstängd
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.
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. Under 2012 är Cygni ett av BRIS guldföretag.

Följ oss via LinkedIn, Twitter eller Facebook


Detta inlägg ingår i serien Spring från början och kommer att behandla det transaktionsstöd som finns i springmodulen spring-tx.
Transaktioner är ett sätt att hålla ihop en eller flera operationer. Typiskt gäller principen ”allt eller inget” vilket betyder att alla operationer som ingår i en transaktion ska exekveras utan fel för att transaktionen ska gälla. Det vanligaste fallet är databastransaktioner där exempelvis flera skrivningar måste exekveras utan fel innan en så kallad commit genomförs. Ett exempel på detta är det klassiska bankkontoexemplet med överflyttning av pengar från ett konto till ett annat. En överflyttning sker genom att ett uttag först sker från ett konto och sedan insättning på ett annat konto. Bägge operationerna måste lyckas, annars ska transaktionen inte gälla det vill säga att man ”rullar tillbaka” transaktionen via en så kallad rollback.
Spring erbjuder på ett enhetligt sätt stöd för att kunna hantera transaktioner av olika slag som till exempel JTA, JDBC, Hibernate, JPA och JDO. Transaktionsstödet kan användas på två sätt, deklarativt eller programmatiskt. Det deklarativa sättet är det absolut vanligaste och innebär att metadata kring transaktionslogik inte ligger inbäddad i den faktiska javakoden utan enbart finns deklarerad ”utanför” javakoden via metadata. Metadata kan antingen bestå av externa XML-filer eller annotationer och påverkar alltså inte javakoden, den är så att säga non-intrusive.
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 >>
Detta inlägg ingår i serien Spring från början och kommer att behandla Springs stöd för Hibernate. Vi kommer inte att gå närmare in på vad Hibernate är och gör utan koncentrera oss på vad Spring kan hjälpa oss med och hur man kan jobba med HibernateTemplate och andra centrala klasser i modulen spring-orm. ORM står för Object Relational Mapping och modulen spring-orm innehåller dessutom stöd för JPA, TopLink och iBATIS.
Läs mer >>
Detta inlägg ingår i serien Spring från början och kommer att behandla hur man kan jobba med JdbcTemplate och andra centrala klasser i modulen spring-jdbc.
Läs mer >>
Idag startar vi en spännande artikelserie: Spring från början! Vi är några Stacktrace-skribenter som planerar att tillsammans ge en steg-för-steg-introduktion till Spring. Vi kommer att börja från grunden med att beskriva designmönstret Dependency Injection och varför det är relevant för Spring. Sen kommer vi att bygga vidare med olika sätt att sätta ihop och konfigurera Spring-applikationer och fortsätta med att gå in på Springs utmärkta stöd för andra ramverk och tekniker.
Artikelserien vänder sig i första hand till nybörjare och relativt oerfarna Spring-utvecklare, men alltefter som vi går in på djupet i olika teknikområden hoppas och tror vi att det ska finnas intressant information även för de mer erfarna.
Vi kommer att uppdatera den här texten med en aktuell innehållsförteckning varje gång ett nytt avsnitt finns tillgängligt, så sätt gärna ett bokmärke här!
Innehållsförteckning
När man specar en webbapplikation är det sällan som säkerhetsaspekterna tas med explicit. Det kan lätt betraktas som ”Någon Annans Problem”: systemadministratören ska se till att brandväggen är på plats, IT-ledningen bestämmer om lösenordspolicy etc. Men i slutänden är inget av detta relevant om applikationen som körs är full av hål, och då är det svårt att skylla ifrån sig. Man måste istället vara påläst om vilka attacker som ofta förekommer och ta aktiva åtgärder för att stoppa dem.
Jag tänkte att vi skulle ta en titt på de vanligaste hålen i webbapplikationer, och hur man kan göra för att täppa till dem.
Läs mer >>