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 >>
Detta inlägg ingår i serien Spring från början och behandlar några av de delar inom Spring som hanterar mottag och publicering av JMS-meddelanden.
Läs mer >>
Java SE 6.0 (JDK/JRE) Release Candidate är släppt. Läs om nyheterna i Release Notes, och kolla in dokumentationen.
Framtiden – den är här nu..! :-)
Äntligen städar Sun upp i brandingen kring Java! Tvåan i ”J2SE” släpps, och ”Java” lyfts fram mer i dagligt tal. Istället för J2SE och J2EE kommer vi alltså att prata om Java SE och Java EE. Versionsnumret hängs på efter, och det finns till och med en rekommendation att bara säga heltalet om det är en ”punkt-noll”-version. Plötsligt känns det alltså rätt att säga ”Java fem” om den senaste versionen. (Ok, ok, jag droppar ”SE” i dagligt tal… Stäm mig bara…)
Läs mer i Graham Hamilton’s blogg.
Tomcat 5.5.7 är flaggad som stabil. Denna blogga beskriver kort vad som är nytt i Tomcat 5.5 generationen och reflekterar lite kring JSP 2.0 / Servlet 2.4 spridningen… Läs mer >>
Struts-gänget har tydligen skrivit om planerna för Struts framöver. Ett nytt underprojekt, ”Shale”, är öppnat, och befintliga Struts kallas numera ”Struts Classic”.
Kortfattat har jag fattat nyheten såhär:
- Struts (Classic) går nu in i underhålls-läge. Inga stora förändringar är planerade och vidare arbete kommer bara att handla om felrättningar och liknande.
- Som det verkar nu kommer Struts Classic därför aldrig att komma i en ”version 2.0″.
- Shale är ett projekt med en helt ny kodbas, och med Java Server Faces som grund. Det är nog tänkt att det ska lösa samma typ av problem som Struts Classic, men med annat API och annat angreppssätt. (Det är förstås JSF-kopplingen som är den viktigaste aspekten här.)
Naturligtvis framkallar ett sådant här meddelande reaktioner, och i blogvärlden är det som vanligt inga problem att hitta negativa inlägg… (Exempelvis här.) Själv har jag väl ungefär de här tankarna i den här frågan:
- Om Struts var ett kommersiellt projekt skulle det här aldrig hända! Tänk om Microsoft sa att ”Word är nu färdigt, och behöver inga fler funktioner. Vi kommer att fortsätta fixa alla buggar, men ni behöver inte köpa några fler uppgraderingar.” Yeah, right…
- Det här är på något sätt ett fantastiskt tillfälle att bevisa att open source fungerar. Om Struts-projektet missbedömt behovet av en ny version av ”Struts Classic”, så kommer den att skapa sig själv. Struts användarskara är stor nog att underhålla och vidareutveckla produkten själva.
- Själv tycker jag helt krasst att det är rätt beslut. Struts löser redan det problem som det designats för att lösa. Snarare har det flytit ut för mycket på sidorna och försöker lösa närliggande problem också, men det tycker jag är feltänkt. Bättre att lösa ett väldefinierat problem bra än att vara halvbra på lite av varje. Jag skulle inte ha något emot att använda ”Struts Classic” på ett problem där jag vet att det uppfyller kraven — även om det finns ett nyare projekt med ett annat angreppssätt. Och jag är inte orolig för att de projekt där jag redan använt Struts (”Classic”) ska plötsligt bli obsoleta och sluta fungera bara för att någon tycker att Struts är ”färdigt”.
- Det roliga är att om det skulle visa sig att användarna av Struts verkligen skriker efter en ny version med någon nu okänd funktion, så kommer den att komma! Antingen som en open source-fork av Struts, eller (troligare) som ett kommersiellt tillägg. Det är ju just det som är det intressanta med open source: någon kan ta upp facklan om den tappas för tidigt.
Slutligen: med den lilla osäkerhet som finns nu med Struts (i alla fall på kort sikt) så känns det skönt att det finns gott om fullgoda alternativ, när man blir tvungen att välja. Jag tänker i första hand på Webwork och Spring, som är mina favoriter.
Craig McClanahan, pappa till Struts och numera djupt involverad i JSF på Sun beskriver hur du går till väga för att använda Struts tillsammans med JSF i en artikel här
Oracle ligger långt framme vad det gäller JSF bland leverantörer. Här finns en intervju med två av frontfigurerna på Oracle, Ted Farrel och Adam Winer.