Poster taggade med ‘j2ee’

Sida 1 av 3123

Har man nån gång suttit och utvecklat webserviceklienter så har man säkerligen suttit och svurit för att man inte lyckas se den råa xml:en som skickas i loggen. Då kan man använda sig av tcpmon eller wsmonitor, men detta kräver att man ändrar host:en på sin endpoint-url. Så jag tänkte tipsa om en jvm parameter man sätta om man använder sig av Glassfish som appserver: com.sun.xml.ws.transport.http.client.HttpTransportPipe.dump, sätter man denna till true så kommer jax-ws logga soap-anropet och soap-svaret till System.out

I Java 7 och också som förhandstitt i senaste Java 6-uppdateringen (14) kommer en ny skräpsamlare, kallad ”garbage first”. Det är en generationell skräpsamlare som klarar av att minska heapen över tiden för att undvika fragmenteringen, vilket i sin tur kan snabba upp kommande skräpsamlingar. Mer information hittar ni hos Sun här – läs det medan ni väntar på er nuvarande skräpsamlare vet ja.

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 >>

Denna artikel ingår i serien Spring från början och kommer behandla det springstöd som finns för OSGi. Denna artikel är inte direkt en ”tutorial” utan ger främst en orientering till OSGi och Spring Dynamic Modules och gör ett försök till att peka på lämpliga användningsområden.

Vad är OSGi och vad är det bra för?

Förkortningen , vilket i vart fall inte hjälper mig att förstå vad OSGi egentligen är.
OSGi står tydligen för Open Service Gateway Initiative, men det har inte hjälpt någon att förstå vad det OSGi egentligen är får något. OSGi-standarden är helt kort en standard för modularisering av javaapplikationer.

OSGi används i allt från inbäddade system, mobiltelefoner till en flerskiktade webbapplikationer. Standarden har funnits i flera år och har tidigare främst används i inbäddade system. Det är först på senare år som OSGi har blivit aktuellt att använda i serverapplikationer. Den kanske mest kända applikationen som bygger på OSGi är den populära utvecklingsmiljön Eclipse, som använder OSGi i sitt plug-in system.

Mer konkret så specificerar standarden tre områden; paketering av moduler, tjänsteregister och modulers livscykler. 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 förklara hur Spring kan konfigureras mha av annotations. Detta är sista delen i denna artikelserie innan vi tar sommaruppehåll men vi ser fram emot fler artiklar till hösten.

Konfiguration av en springapplikation brukar oftast ske mha XML-context som visats i ett antal exempel tidigare i denna serie, bland annat i artikeln om Spring som DI-ramverk. Det finns dock andra möjligheter att konfigurera upp din Spring-applikation. Ett sätt är att använda annotations.

Läs mer >>

Grails är ett webbramverk som är designat för hög produktivitet. Det gör precis som Ruby On Rails och satsar på konventioner framför konfiguration. Detta förenklar och snabbar upp utveckling betydligt. Under motorhuven så använder sig Grails av bland annat Spring, Hibernate, SiteMesh, Ant, Log4j. Grails är baserat på Groovy, som är ett objektorienterat dynamiskt skriptspråk som är baserat på Java platformen.

Läs mer >>

Sida 1 av 3123