JavaEE 6 Session mit Adam Bien
(Blog, Twitter, Source code)
- JavaEE 6 und Spring verwenden dieselben Annotation, daher nicht gemeinsam verwenden
- Keine externe Konfiguration notwendig, keine XML-Files
- empfohleme IDE: Netbeans
- empfohlener Applicationserver: Glassfish (mit Netbeans geliefert). JBoss 7 ist auch gut, ältere JBoss-Versionen meiden!
Cargo cult programming:
Sinnloser Ballast. Beispiele:
- DTOs (nur copy-paste, mögliche Fehlerquelle z.B. wenn sich Properties ändern)
- EAR-Packaging (fast immer ist WAR-Packaging ausreichend & erhöht die Produktivität: keine Classloader-Issues, weniger Projekte, weniger zippen...)
- Interfaces, wo es eh nur eine Implementierung gibt (und keine weitere vorgesehen ist - üblicherweise bei allen injected Beans)
- vgl. Patterns aus den J2EE Blueprints
Maven Failsafe Plugin
- Unittests von Integrationstest trennen
- Unittests bei jedem Commit ausführen, Integrationstests erst in der nächsten CI-Stufe
(?)
Some Java EE 6 Features:
- @Singleton: wie stateless Sessionbean (@Stateless) mit Poolsize 1, d.h. quasi synchronized access. Aber: nicht Cluster-fähig
- @Startup: Bean beim Hochfahren instanzieren (gemeinsam mit @DependsOn und @PostConstruct)
- @Observes: kann zur Überwachung von Batch-Jobs verwendet werden ("during"-Parameter)
- Async Servlets (Comet, Long Polling): @WebServlet(asyncSupported=true), HttpServletRequest.startAsync()
- REST-API soll selbstbeschreibend sein (User ruft die erste URI auf & lernt daraus wie die API funktioniert)
- Beispiele für eine gute REST-APIs: HelloCloud, JBoss HornetQ
- Java-Service wird durch Annotations (@Produces... auf Klassenebene; @GET, @Path... auf Methodenebene) direkt exported
- SOAP biete keine Mehrwert, sondern nur Overhead & Komplexität
- die Mehrheit aller neuen APIs verwendet REST; SOAP ist stark rückläufig (vgl. REST vs. SOAP at Amazon)