[J2EE] Welke frameworks gebruiken jullie?

[JKVA]

Ik heb hier al eens vaker naar zitten zoeken, maar wat zijn nu feitelijk de populairste J2EE frameworks? Blijft iedereen bij de standaard combinaties zoals STRUTS/Spring/Hibernate? Of zijn er hier al mensen die met meer exotische combinaties bezig zijn?

Hierbij denk ik aan bijvoorbeeld Tapestry/Hivemind/iBatis ofzo.

Of zijn er nog mensen die vasthouden aan bijvoorbeeld JDO of EJB's?

Zelf vind ik voor de weblaag JavaServer Faces (Apache MyFaces) erg fijn werken, ondanks enkele irritante bugs die ineens op komen dagen over duplicate ID's en zo. Zeker nu er een gast van het JSF team aan het werk is aan Facelets, waar ik nu ondertussen weer een dikke maand mee aan het klussen ben en waarvan ik denk dat het binnenkort maar eens in de JEE standaard mag komen. Misschien niet zo overdreven, maar het is iig een sterke troef naar mijn idee. Zie hiervoor ook: [rml][ J2EE] Facelets, serieus of alweer een hype?[/rml]

Van een collega hoorde ik ook zeer positieve verhalen over iBatis, dus daar ga ik denk ik ook binnenkort eens mee klussen. Tenzij hier al iemand iets roept in de trant van: "NIET DOEN!!!"

Verder ben ik benieuwd voor welke (combinatie van) frameworks jullie hebben gekozen en als het effe kan ook waarom.

[Varienaja]

Momenteel werk ik met:

Tapestry (en dus Hivemind), Spring, Hibernate, Acegi, en sinds kort ben ik ook wat aan het spelen met Quartz, maar dat stelt nog niks voor.

Het gaan gebruiken van Tapestry vond ik niet zo'n probleem. Een collega had de belangrijkste dingen al uitgezocht, dus ik had veel code om de kunst af te kijken. De overgang van Tapestry 3 naar 4 heb ik via een stuk of 10 beta releases gedaan. Dat had wel wat voeten in aarde, maar gelukkig is versie 4 een stuk overzichtelijker dan 3.

Hibernate is een waanzinnig handig product. Het duurt wel even voordat je de meeste zaken in de smiezen hebt. Ik vind het lastig om een bestaand datamodel op een bestaand objecten-model te mappen, maar met een beetje moeite lukt dat wel. Maar als je vanaf het begin van een project direct Hibernate gebruikt werkt 't zeer goed.

Spring is enorm uitgebreid. Je plakt er vanalles mee aan elkaar. Je intercept je een slag in de rondte, en hoe het allemaal blijft werken is me een half raadsel. Ik weet hier duidelijk nog veel te weinig van, ookal zit het al door m'n hele applicatie heen. De documentatie is gelukkig erg goed, en al doende leert men zal ik maar zeggen!

Acegi is het defacto beveiligings-framework. Het kost even moeite om op te starten. Het kostte me een doorlooptijd van een week of 3 om de beveiliging van m'n webapplicatie werkend te krijgen. Gisteren nog bouwde ik Acegi in in een ander bestaande webapplicatie, en dan ben je in een dagje klaar. Acegi is mooi spul, en erg uitgebreid. Beveiliging op URL-niveau, op methodinvocation-niveau (met nog after method incovation filtering mogelijkheden) en beveiliging op recordniveau in je database. Alles kan.

Met Quartz heb ik vorige week even gespeeld. Je kan er vast een heleboel mee, maar nadat ik voor elkaar had dat mijn dagelijkse Job draaide heb ik er niet meer naar gekeken.

[Verwijderd]

ik hou het idd bij standaard combinatie struts, spring en hibernate...

Waarom?

Geen idee eigenlijk, nog nooit problemen mee gehad, en kan er wel redelijk weg mee, waarom veranderen dan?
En eigenlijk niet veel tijd over om andere dingen uit te proberen.

[JKVA]

De positieve verhalen over iBatis zijn hier omgeslagen in iets negatievere. Blijkbaar zit er een zeer onduidelijke foutafhandeling in.

Ook blijkt het niet veel meer te zijn dan een query opslag, hoewel ik dat niet zo erg vind, want ik beschouw queries nog steeds als een zeer krachtig hulpmiddel.

Het lijkt erop dat er dus nog steeds geen echte concurrentie is voor Hibernate, zeker met ondertussen versie 3.

[PhoneTech]

Old school EJB Stateless Session Beans, CMP 2.0 Entity Beans met Container Managed Relationships, JAAS voor de security en Swing voor de clients.

Een paar custom servlets voor de file transfers en dat is het zo een beetje. Binnenkort een forum wat nu met DAO werkt, omhacken naar CMP zodat ik de CMR's kan gebruiken. Dat is wel jammer...Als je eenmaal met CMR werkt, kan je niet meer terug of combinaties maken...

Voor veel mensen zal dit erg schrikken zijn.."Worden hier nog steeds apps mee gemaakt??" hoor ik jullie zeggen...

Ja hoor! En dat gaat prima ook! In combinatie met xDoclet, en slim gebruik maken van de interfaces kan je toch verassend veel hergebruik introduceren in je beans. Veel data objecten zijn het zelfde opgebouwd, maar verschillen door een veldje meer of minder.

Door de local home interfaces ze van het zeflde interface te laten overerven, hoef je maar 1 stuk code te schrijven voor de gezamelijke velden, en per type een apart stukje.

Deze hierarchie is door de gehele applicatie verwerkt, en ik sta ook te springen om naar EJB3.0 over te springen omdat deze het allemaal "native" ondersteund!

Door de boel goed te tunen en de juiste commit option te gebruiken (dit kan zo een 400% schelen) is het toch nog behoorlijk snel en responsive.

[reddog33hummer]

PhoneTech schreef op vrijdag 31 maart 2006 @ 10:19:
Door de boel goed te tunen en de juiste commit option te gebruiken (dit kan zo een 400% schelen) is het toch nog behoorlijk snel en responsive.

Goed gebruik van algoritmen en Asynchronze verwerking bij grote opdrachten scheelt ook veel in dat soort implementaties.

[whoami]

Hmm.... Ik vind dat dti topic eerder in DT&E thuishoort. Het gaat hier nl. meer over 'tools' dan over het aanwenden van die tools in een architectuur.
SE&A -> DT&E.

[Verwijderd]

PhoneTech schreef op vrijdag 31 maart 2006 @ 10:19:
Old school EJB Stateless Session Beans, CMP 2.0 Entity Beans met Container Managed Relationships, JAAS voor de security en Swing voor de clients.

Een paar custom servlets voor de file transfers en dat is het zo een beetje. Binnenkort een forum wat nu met DAO werkt, omhacken naar CMP zodat ik de CMR's kan gebruiken. Dat is wel jammer...Als je eenmaal met CMR werkt, kan je niet meer terug of combinaties maken...

Voor veel mensen zal dit erg schrikken zijn.."Worden hier nog steeds apps mee gemaakt??" hoor ik jullie zeggen...

Ja hoor! En dat gaat prima ook! In combinatie met xDoclet, en slim gebruik maken van de interfaces kan je toch verassend veel hergebruik introduceren in je beans. Veel data objecten zijn het zelfde opgebouwd, maar verschillen door een veldje meer of minder.

Door de local home interfaces ze van het zeflde interface te laten overerven, hoef je maar 1 stuk code te schrijven voor de gezamelijke velden, en per type een apart stukje.

Deze hierarchie is door de gehele applicatie verwerkt, en ik sta ook te springen om naar EJB3.0 over te springen omdat deze het allemaal "native" ondersteund!

Door de boel goed te tunen en de juiste commit option te gebruiken (dit kan zo een 400% schelen) is het toch nog behoorlijk snel en responsive.

Hier hetzelfde, Struts, Stateless session beans, CMP2.0 & EJBgen (voor BEA Weblogic 6.1 nog, dwz JDK 1.3 ).
Dit is een project waar reeds 4 jaar aan gewerkt wordt met gemiddeld 20 personen, dus van spring/hibernate was toen in de verste verte geen sprake. Ook ik heb weinig problemen met EJB's. Hibernate lijkt me wel leuker (iets nieuws lijkt me altijd wel leuker ) maar of het zoveel problemen gaat oplossen weet ik niet. HQL is wel wat uitgebreider dan EJB-QL, dat is wel iets waar je regelmatig op zit te vloeken.

Ik denk dat het wel nog enkele jaartjes zal duren eer ik (professioneel) Hibernate zal gebruiken. Nieuwe projecten gebruiken wel al hibernate en soms zelfs Spring maar er is geen enkel in onze grootteorde die het gebruikt.

[Alarmnummer]

Mijn basis framework is Spring. Ik lijm hier alle applicaties mee in elkaar. Verder bied Spring een abstractie voor veel frameworks (bv in de vorm van exception hierarchieeen). Dit maakt het erg eenvoudig om allerlei technieken door elkaar te gebruiken. Ik gebruik bv Hibernate en JDBC (door elkaar) om met de database te communiceren, maar door de geunificeerde exception hierarchie maakt het in de rest van de applicatie niet meer uit welke concrete implementatie je gebruikt.

Verder gebruik ik tegenwoordig Spring-MVC als webframework (erg fijn als je applicatie moet kunnen schalen omdat het minder van sessies afhankelijk is dan veel andere frameworks). Maar in sommige gevallen heb ik toch liever iets anders zoals Wicket/Tapestry.

Spring geeft me ook de mogelijkheid om AOP toe te passen. Ik gebruik het voor transactie management, security, maar soms ook om nieuwe processen op een bestaand proces aan te sluiten. En verder kunnen we ook erg eenvoudig custom made AOP-aspecten toepassen (zoals locking-retry aspect in het geval van een locking failure). In tegenstelling tot EJB waar je dus niet de mogelijkheid hebt om zelf aspecten te maken. Deze krachtige mogelijkheden maken het voor beginnende programmeurs wel een stuk lastiger om Spring goed te kunnen toepassen (aangezien er 10.000 wegen zijn naar rome). Vooral met de nieuwe features van Spring 2 (domain specifieke syntax, bean scoping etc, dependency injection in domain objects) zullen er denk ik erg veel vragen gaan komen.

Dit zijn eigelijk wel de main-api`s die ik gebruik. De rest van de meuk die komt is afhankelijk van de situatie. Verder zetten we tegenwoordig alle nieuwe projecten op in Java 5 en we upgraden ook bestaande projecten naar Java 5 als we daar mee aan de slag moeten.

[edit]
Verder bevalt de Spring community mij vrij goed. Erg veel slimme mensen die niet klakkeloos alles aannemen, die niet in grote logge omgevingen vast willen zitten maar controle willen over hetgeen ze maken. Kwaliteit afdwingen door goed testbare applicaties op te zetten. Gewoon mensen met liefde voor hun vak en die lichte maar extreem krachtige oplossingen willen "put the developer back in the drivers seat".

[ Voor 63% gewijzigd door Alarmnummer op 31-03-2006 11:50 ]

[dip]

Als beginnende J2EE-er (2 maanden ) ben ik begonnen met JavaServer Faces. Waarom? ik denk dat dit een zeer krachtig framework is en STRUTS met de jaren opzij zal schuiven. Bestaande technieken zullen altijd blijven bestaan door van zowel de ontwikkelaar als de opdrachtgever.

Binnenkort zal ik me bezig gaan houden met Spring. Ik zie het tot nutoe wel wat voordelen, maar het breng ook veel overhead met zich mee heb ik het idee. Correct me if im wrong..

edit:
whoami, waarom dit topic in DT&E ? Dit heeft toch echt wel te maken met Software Engineering & Architecture

[ Voor 12% gewijzigd door dip op 04-04-2006 11:46 ]

[Antediluvian]

Ik gebruik ook Spring en Hibernate. Als webframework momenteel SpringMVC maar ik ben nu aan het migreren naar Spring Web Flow. SWF is geen vervanger van van een MVC maar eerder een abstraction laag die het oa mogelijk maakt een stateless protocol (bv http) te behandelen alsof het statefull is.
Verder gebruik ik Acegi Security, Lucene (voor search), (opensymphony)Sitemesh, xDocklet, ...

Niet echt een framework maar echt zeer handig is Maven2 als build tool.

In de toekomst wil ik echter eens aan de slag met Orbeon PresentationServer dat gehost wordt bij ObjectWeb. Het is een model2X framwork en lijkt mij wel intressant.

Model 2 defines how the Model-View-Controller (MVC) pattern can be applied to Web applications. Model 2X builds on top of Model 2 and replaces the JSP layer with XML and XSLT.

Orbeon PresentationServer is an open source platform that uses standard XForms to make your form-based web applications more user-friendly and simpler to create.

Unlike other web application frameworks based on Java objects or scripting languages, OPS is based on XML documents and XForms. This leads to an architecture perfectly suited for the tasks of capturing, processing, and presenting XML data, and does not require writing any Java or scripting code at all to implement a dynamic presentation layer for your web application.

OPS is built around a user-friendly Ajax-based XForms engine, which brings standard W3C XForms to mainstream browsers, and the XPL engine, a mature, high-performance XML pipeline engine for processing XML data.

[JKVA]

Beschouw je Maven2 ook als serieus beter dan Maven "1"?

[Antediluvian]

Maven 2 heeft een aantal voordelen tegenover Maven 1 (bv transitive dependencies) maar het moet allemaal nog wat op gang komen. Maven staat of valt met de kwaliteit van z'n repository. Bij maven 2 is dit nog meer zo dan bij maven 1.

Momenteel zijn veel OS projecten aan het overschakelen naar maven2 maar eenmaal de public repository in orde is zal het een plezier zijn om ermee te werken (no more dependency hell). Nu is het nog wat prutsen en zoeken om de dependencies in orde te krijgen maar de kwaliteit van de repository (en dan specifiek de pom files) wordt dagelijks beter.

[JKVA]

Ik hoorde idd pas ook dat Maven2 vrij krachtig is. Het is ook in onze nieuwe ontwikkelstraat opgenomen. Verder weet ik nog weinig van Maven2 af, maar daar ga ik binnenkort dan maar eens mee stoeien.
Altijd leuk.