Projekt bei seam2 belassen oder auf JEE6 portieren

[kaffee74]

Hallo,

wir (ich+Kollegen) stehen vor der Entscheidung, ein Projekt (komplexe Webanwendung mit Servlets, JSF etc.) bei seam2 zu belassen oder auf JEE6/seam zu portieren. Da gibts diverse Faktoren, die die Entscheidung ziemlich schwierig machen.

Fakten:

- Projekt existiert als "Rohversion" auf Seam2 basierend, aber es ist noch jede Menge Arbeit (mehrere Monate) nowendig, bis es so ist, dass wir es auf die Welt loslassen können

- Kollegen müssten sich in beide Technologien erst noch einarbeiten, Grundkenntnisse vorhanden, aber so richtig Erfahrung noch nicht. Ich bin in seam 2 relativ fit, JEE6 auch eher Neuland.

- Zukunft des Projektes schwer abschätzbar. Konkret siehts wohl so aus, dass es entweder gleich floppt, dann ist es nur eine Frage von Monaten, bis es ganz eingestampft wird, oder aber, wenns gut läuft, sehr langfristig angedacht (10 Jahre oder mehr).

- Zeitrahmen für "erste vorzeigbare Demoversion" relativ knapp, Kunde wartet nur noch einige wenige Monate bis er was zum Spielen bekommt.

Wie soll man sich auf Basis dessen entscheiden?

Für Seam 2 spricht: Technologisch rund und ausgereift, für alles brauchbar was man so braucht, auch noch auf die nächsen Jahre hin betrachtet; das Projekt existiert bereits als seam2 und müsste also nicht extra portiert werden ;-), Seam 2 ist irgendwie einfacher als JEE6/CDI/Weld (finde ich), also, wenn man eine Webanwendung JETZT braucht und der Zeithorizont für die Anwendung "die nächsten paar Jahre" ist, und man es dann irgendwann auf JEE6 (oder 7 oder 8..) portieren kann, ist seam2 wohl die richtige Wahl; ausserdem ist der zusätzliche Aufwand des Portierens auf Jee6 nicht zu vernachlässigen (2 wochen? 1 Monat?). Jee6 ist ausserdem soweit ich weiss noch nicht wirklich rund und ausgereift und bugfrei, trifft vor allem auf rich- und primefaces zu. Einige seam-Komponenten, die in Seam2 so nett sind, fehlen wohl auch noch (hat mir zumindest ein kompetenter Programmiererfreund erzählt.

Für JEE6 spricht: Es ist der aktuelle Standard, Weiterentwicklungen werden auf JEE6 basieren und nicht auf JEE5, JPA 2.0 ist besser als 1.0, wenn der Zeithorizont für die Anwendung langfristig ist, also wohl zu bevorzugen; könnte mir z.B. vorstellen dass es gerade im visuellen Bereich (HTML-Frontend) in einigen Jahren visuelle Anforderungen gibt, die man nur noch mit der aktuellen JEE-Version samt Jsf-taglibs realisieren kann, aber nicht mehr mit seam2/Rich faces, und daher irgendwan eh eine Portierung notwendig wird. Andererseits ist der Aufwand, eine ausgewachsene Anwendung zu portieren, so gross, dass man es vielleicht doch lieber machen sollte, solange das Projekt noch klein ist und in den Kinderschuhen steckt (also jetzt).

Mit Portierung auf Jee6 würde das Projekt, schätze ich, aber erstmal einen Monat später einen Stand erreeichen, den man dem Kunden zeigen kann.

Was meint ihr, auf Basis dieser Infos?

Gruß+Danke

 

[Sym]

Wenn Du Seam 2 technologisch ausgereift und rund findest, dann wird CDI Deine Glocken zum Läuten bringen.

Eine Portierung kostet immer Zeit und Geld. Die Frage ist, wie weit euer Produkt schon ist und wie groß der Aufwand wird. Dazu müsstet ihr euren Code analysieren und schauen, welche Features ihr nutzt, welche durch CDI (und mehr) eine problemlose Ablösung finden und welche nicht.

Natürlich ist Wartung ein nicht zu vernachlässigender Punkt.

Wenn die Chance besteht -> Portieren.

 

[kaffee74]

Ich hab schonmal eine kleine Anwendung mit Jee6 gebaut, ganz neu ist mir das nicht ;-). Aber halt noch nicht wirklich routiniert.

Das Projekt ist quasi in den Startlöchern.. aber der Punkt ist wohl.. wenn portieren, dann jetzt. Wenns erstmal gross und fertig ist, dann ist das ja kaum noch mit vertretbarem Aufwand machbar.

 

[FArt]

Wenn ihr erst mal ausgeliefert habt, wird eine Migration auwendiger. Der Kunde zahlt dann auch ungern dafür, denn er bekommt ja für sein Geld nichts, was er nicht schon hätte und ihr habt das Projekt dann noch Jahre in der Wartung.
Nutzt die Migration für eine Konsolidierung um das ganze wartbarer zu machen. Wenn ihr das schon habt, ist die Portierung auch nicht so ein Riesending.

Tipp: Migriert auf einen aktuellen Stand und baut einen Durchstich, mit dem der Kunde bereits arbeiten und was sehen kann. Ihr benötigt frühres Feedback. Wenn ihr ihm in "einigen wenigen Monaten" ein Riesending präsentiert ist die Wahrscheinlichkeit hoch, dass das Projekt floppt.

Die Devise sollte sein: technischer Durchstich, eine oder zwei Grundfunktionalitäten rein und ab mit der ersten Version zum Kunden. Danach in kurzen Abständen Meilensteine präsentieren. Regelmäßig die Architektur / Software durch refaktorieren den Bedürfnissen (Anforderungen des Kunden und der Infrastruktur) anpassen. Automatisierte Tests und Builds und schon gibt es für einen Kunden (der ja ein Projekt in Auftrag gegeben hat) keinen Grund plötlich davon abzukommen, weil ihr flexibel auf alle Wünsche und Probleme reagieren könnt.

Wenn ihr jetzt schon auf ältere Technologie und Infrastruktur setzt, muss man fast froh sein, wenn das Produkt nicht in die Wartung geht. Holt euch ruhig einen Trainer ins Haus, der euch mal in wenigen Tagen alles beibringt und auf spezifische Fragen antworten kann und/oder bei der Migration unterstützt. Das ist gut angelegtes Geld.

 

[JanHH]

Danke für die Antwort. Die Situation mit dem Kunden ist allerdings recht speziell, kann man nicht so in Kurzfassung beschreiben. De fakto ist der Zeitrahmen aber wohl zu eng für die Portierung, einen Monat zusätzlich muss man da sicher einplanen.

Ausserdem kam von einem befreundeten Programmierer die Ansage, nachdem er ein komplexes Projekt auf JEE6 aufgesetzt hat.. "lasst die Finger davon, das ist noch alles so buggy und diverse wichtige Features von seam2 fehlen bisher komplett oder funktionieren nicht. In einem halben Jahr wird das wohl anders aussehen, aber zur Zeit macht ihr euch da keine Freude mit".

Daher wirds jetzt erstmal bei seam2 bleiben.

Hm, hab grad gesehen dass ich den Thread mit meinem Firmen-Account geschrieben hab, nicht wundern wg. dem Namen ;-).

 

[KSG9|sebastian]

...

Ausserdem kam von einem befreundeten Programmierer die Ansage, nachdem er ein komplexes Projekt auf JEE6 aufgesetzt hat.. "lasst die Finger davon, das ist noch alles so buggy und diverse wichtige Features von seam2 fehlen bisher komplett oder funktionieren nicht. In einem halben Jahr wird das wohl anders aussehen, aber zur Zeit macht ihr euch da keine Freude mit".

...

Aha, und welche so wichtigen Features fehlen denn? Und was ist alles so buggy? Ich tu mich mit solchen Aussagen immer schwer, vor allem wenn keine konkreten Infos dahinter stehen.

 

[JanHH]

z.B. die Spring Security-Komponente (Identity), es gibt kein s:convertEntiy, kein s:convertEnum, diverse Details bei den RichFaces 4 funktionieren (noch) nicht oder fehlen ganz..

 

[Sym]

z.B. die Spring Security-Komponente (Identity), es gibt kein s:convertEntiy, kein s:convertEnum, diverse Details bei den RichFaces 4 funktionieren (noch) nicht oder fehlen ganz..

Wo steht denn, dass Richfaces eingesetzt wird? Ganz davon ab, dass im Januar 4.1 kommen soll, wo kein Feature mehr fehlen soll.

Für convertEnum und convertEntity lässt sich wirklich schnell eine Lösung schreiben. Davon sollte eine Migration wirklich nicht abhängen.

Und was genau hat die Spring Security Komponente hier zu suchen?

Und ganz am Ende: Es gibt auch Seam 3 für fehlende Features.

 

[KSG9|sebastian]

Ach ja, betrifft zwar Spring->JEE 6, aber dürfte ähnlich sein:

From Spring to Java EE 6

 

[JanHH]

hm ja meinte seam security, vertipper

 

[Sym]

hm ja meinte seam security, vertipper

Wozu benötigst Du denn Seam Security?

Wenn Du einen EE-Server mit z.B. JAAS-Authentifizierung nutzt, benötigst Du die Security wohl eher seltener. Alternativ gibt es natürlich das Seam 3 Security Modul, welches alle fehlenden Teile liefert.

Wenn Du nichts wirklich Konkretes gegen CDI und JSF2 hast, würde ich auch nicht davon abraten. Mit JSF 1.2 und Seam 2 holst Du Dir eine Technik ins Haus, deren Support in naher Zukunft endet (und bei einigen Implementation schon geendet ist). Eine Portierung kostet im Nachhinein viel Geld und die Wartbarkeit ist bei der alten Technik ebenfalls nicht zu verachten, da es für die alten Module eben keinen Support mehr gibt.

 

[JanHH]

Aber wenn mein Bekannter, dessen fachliche Kompetenz ich beurteilen kann und dessen Arbeitsweise mir vertraut ist, sagt, Jan, lass die Finger davon, damit macht ihr euch keine Freude, dann vertraue ich dem durchaus ;-).

Ansonsten hast Du natürlich recht, sehe ich auch so. Gibt halt für beides vernünftige Argumente. Allerdings haben sich meine Kollegen nun auch gegen die Portierung entschieden.

 

[FArt]

Aber wenn mein Bekannter, dessen fachliche Kompetenz ich beurteilen kann und dessen Arbeitsweise mir vertraut ist, sagt, Jan, lass die Finger davon, damit macht ihr euch keine Freude, dann vertraue ich dem durchaus ;-).

Wenn du schon kompetenten Rat bekommen hast, warum fragst du dann hier noch? Beschäftigungstherapie?

Anscheinend könnt ihr die Problematik selber nicht einschätzen bzw. bewerten. Holt euch mal einen technischen Berater ins Haus, der eine kurze Analyse vornimmt und auch Aufwände für eine Migration (und vor allem Wartung alter Technologien) einschätzen kann. Das ist bezahlbar und bringt wirklich was.

Die Frage ist in der Regel nicht Migration ja oder nein, sondern wie ist meine Arbeitsweise. Prototypische Umsetzung und Migration eines kleinen Teils und Bewertung der restlichen Aufwände. Abschätzen der Gefahren, kurze Releaszyklen, autmatische Tests (schon vor der Migration!), die sicherstellen, dass ihr nichts umschmeißt. So lange die neue Technologie nur eine "graue Wolke" ist, werdet ihr keine sinnvolle Abwägung hinbekommen. Ein hoher Wartungsaufwand bei alter Technologie, die Erfahrung habt ihr sicher auch schon selber gemacht, oder?

Dein Bekannter trägt schließlich weder das Risiko der Entscheidung noch führt er sie durch ;-)

 

[JanHH]

Das geht bei uns alles weit weniger professionell zu als Du da skizzierst ;-).

Und ich hatte die Frage zuerst hier gestellt, es geht einfach darum, verschiedene Meinugen einzuholen.

 

[KSG9|sebastian]

Na ja, das hat nix mit Arbeitsweise und Kompetenz zu tun sondern in erster Linie mit Kosten (Wartung, Erweiterung, Fehlerbehebung, Support...).

Und zu behaupten das JEE6 so buggy ist zeugt in meinen Augen nicht unbedingt von überragender Fachkompetenz...ist nicht böse gemeint, aber die Aussage ist halt einfach fragwürdig.

 

[JanHH]

Naja meine ersten Gehversuche mit JEE6 führten auch zu der Meinung dass da noch so einiges fehlt. Aber jetzt ist das auch entschieden. Nebenbei hab ich auch Null Lust auf die Portierung ;-). Ist eh fraglich ob das Projekt überhaupt was wird, also erstmal so einfach wie möglich rangehen..

 

[Sym]

Jetzt hast Du mich neugierig gemacht. Was ist denn "einiges" das Dir fehlt bei Deinen ersten Gehversuchen?

 

[FArt]

Jetzt hast Du mich neugierig gemacht. Was ist denn "einiges" das Dir fehlt bei Deinen ersten Gehversuchen?

... das würde mich auch interessieren... außer natürlich der Krempel, der schon für JEE7 und 8 diskutiert wird...

 

[JanHH]

Konkret war das der security-Kram (identity-Komponente), ausserdem hab ich erst die Info bekommen "Validierungen gehen mit Jee6 viel einfacher / bean validation), das Problem war das Validieren von zwei Feldern einer Bean in Abhängigkeit voneinander (also z.B. Passwort muss identisch mit passwort-Sicherheits-zweiteingabe sein, und eine andere Information soll nur vorhanden sein, wenn ein bestimmtes boolean true ist, also z.B. "Hund vorhanden?" ja -> "Wie heisst der Hund"), was dann letzten Endes doch nicht einfacher ging als vorher, aber was dafür noch schwieriger war, war, die Validierungs-Fehlermeldungen bei den Komponenten zu platzieren (und nicht bei der allgemeinen h:facesMessages-Stelle in der HTML-Seite). Die normalen, automatischen entity-Validierungen kamen da, wo sie sein sollten, aber die "per hand gemachten" (wie die mit dem Hund) liessen sich nicht mehr bei den Komponenten platzieren, sondern nur im allgemeinen Teil. Details weiss ich nicht mehr, müsste nachschauen. Liegt aber auch hier an einer fehlenden Komponente (seam-facesMessages, facesMessages.addToControl, oder so ähnlich, glaub ich). Ausserdem natürlich s:convertEntity und s:convertEnum. Konverter per Hand schreiben notwendig, wääh. Ausserdem bei s:selectItems das "NoSelectionLabel", fehlte komplett.

Ausserdem diverse RichFaces-Bugs und ebenfalls fehlende Sachen, die Applikation hat z.B. den Kalender mit einer customized Data Model-Sache benutzt, die komplett FEHLTE, komponente unbrauchbar, eigenen Kalender schreiben notwendig.

Fand alles in allem.. CDI/Weld, tolle Sache, JSF 2.0, viele Fortschritte, aber fehlen von seam2 drumrum immer noch gravierender Mangel, der die Vorteile deutlich überwogen hat. Mag auch an der Sichtweise liegen; ich arbeite halt ziemlich seam-fixiert; wenn man das nicht so tut, hat man da evtl. einen anderen Eindruck/Standpunkt. Ich hatte da halt ein kleines seam2-Projektchen und wollte es auf Jee6 portieren und es war hakelig.

 

[Sym]

Bis auf das convertEntity und convertEnum sind das alles keine Fehler oder fehlende Funktionalität. Ich könnte da überall gesondert darauf eingehen, was an dieser Stelle aber eher unsinnig wäre.

Fest steht: Ihr habt Euch für Seam 2 entschieden, weil Euch das Wissen fehlt, mit CDI und JSF 2 (sogar JSF 1.2) umzugehen und nicht weil es gravierende Mängel enthält. Das ist natürlich vollkommen legitim.

 

[JanHH]

Jo, da magst Du recht haben. Kannst Du trotzdem auf die Punkte gesondert eingehen? Ggf als auch PM, aber passt ja auch hier rein, oder? Man bildet sich ja weiter und ich wollt schon auf JEE6 umsteigen demnächst..

Vor allem die Validierung zweier Felder in Abhängigkeit voneinander (Member B darf/muss nur dann nicht null sein wen A=true) und das Platzieren der Fehlermeldung direkt bei Eingabefeld B interessiert mich.

Gruß+Danke
Jan

 

[Sym]

Bei den Feldern ist das eine normale AJAX und JSF Funktionalität. Du setzt bei B das Required Attribute und prüfst den Wert von A. Da kannst Du entweder so machen, dass Du den Wert der Bean beim Setzen von A schreibst (über AJAX) oder Du gehst über den Context, was jedoch komplizierter und fehleranfälliger ist.

Alternativ haben einige JSF 2 Implementationen einen Graphvalidator, der solche Abhängigkeiten auf einfache Art und Weise prüfen kann.

 

[JanHH]

den graphvalidator kenne ich, es gibt da sowohl von rich faces als auch von seam3 Lösungen für, aber mit keiner davon war es mir möglich, die fehlermeldung auch direkt beim Eingabefeld zu platzieren!

seam2: Eine Zeile code (facesMessages.addToControl), JEE6: Bastel bastel.

s:convertEntity und s:convertEnum dito.

Nee nee Leute, das Jee6/seam3-Paket ist noch nicht rund ;-). Warten wir nochmal ein halbes bis ganzes Jahr ab.

Vielleicht fehlt den Leuten, die sagen dass ich mich irre und nicht die notwendigen Jee6/JSF2-Kenntnisse habe, iherseits der Einblick in seam2, um zu wissen, wie einfach und elegant da vieles geht?

 

[Sym]

Ich glaube kaum, dass mir der Einblick in Seam 2 fehlt, da ich beruflich hauptsächlich damit arbeite.

 

[JanHH]

Ja dann wohl nicht.

 

[Sym]

den graphvalidator kenne ich, es gibt da sowohl von rich faces als auch von seam3 Lösungen für, aber mit keiner davon war es mir möglich, die fehlermeldung auch direkt beim Eingabefeld zu platzieren!

seam2: Eine Zeile code (facesMessages.addToControl), JEE6: Bastel bastel.

Nur falls jemand dafür Lösung sucht: RichFaces Showcase

Man kann in RF dafür das Tag <rich:message .../> verwenden und dort die Id des Graphvalidators angeben. Das hat den Vorteil, dass es frei positionierbar ist.

Schönes Wochenende.

 

[JanHH]

Danke für den Link, durchaus interessat. Konkrete Nachfrage: Bei dem Beispiel wird die Message "Different passwords entered!" keinem bestimmten Steuerelement zugewiesen. Wenn man diese Message nun neben einem der Eingabefelder würde haben wollen, und nicht im allgemeinen messages-Teil.. wie ginge das?

 

[Sym]

Du kannst die <rich:message .../> einfach neben Deinem Eingabefeld positionieren im xhtml.

 

[JanHH]

Ok, dann jetzt folgende Anforderung: Es gibt drei Boolean-Checkboxes, und wenn die markiert sind, soll jeweils ein daneben stehendes Textfeld ausgefüllt werden. Wenn das Textfeld leer gelassen wird, soll eine entsprechende Meldung jeweils neben dem Textfeld stehen.

 

[Sym]

Schreibe die Values Deiner Checkboxen beim Klicken in die Bean und zeiche das Textfeld neu. Setze beim Textfeld das Required-Attribute und prüfe darin den Inhalt der Bean.