2012-08-27 12 views
18

Wenn ich wählen kann, verwende ich JBoss 7 für ein Java EE 6 Projekt mit JSF 2 und CDI.CDI auf Tomcat 7 - macht es Sinn?

Aber manchmal ist die Umgebung für ein Kundenprojekt mehr oder weniger festgelegt - so sind wir in einem Fall auf Tomcat (6 oder 7) beschränkt.

Also las ich ein paar Artikel über die Verwendung von CDI (z. B. WELD) und JSF 2 in Tomcat, die zeigten, dass es im Grunde kein Problem ist, es zu tun.

Noch ist meine Frage - macht es Sinn? Oder ist ein Servlet-Container einfach nicht die richtige Umgebung für eine solche Architektur? Hat jemand Erfahrung mit Tomcat + CDI für etwas mehr als ein Demo-Projekt?

Vielen Dank im Voraus!

+0

Wäre toll, wenn Sie die Frage aktualisieren können, wie Sie endlich entschieden ... –

+1

@jangroth Wie gesagt - meine Entscheidung wäre leicht, aber wenn die endgültige Entscheidung für Tomcat ist, kann ich damit leben und einhundert Gläser in meinem Krieg, solange es keine echten Blockierpunkte gegen Tomcat + CDI gibt. –

Antwort

13

Gute Frage, allen voran :)

Bereitstellen einer Unternehmensanwendung auf ein Servlet Engine ist das Hauptszenario von z.B. Frühling, so ist es sicherlich möglich. Aber Sie werden wissen, dass Spring ein ganzes Ökosystem von APIs und Konfigurationsdateien ist, anstatt ein paar JARs, die Sie einfach auf den Server stellen und mit denen Sie Spaß haben.

Ich spielte ziemlich viel mit Weld & JSF auf Tomcat 7, und es funktionierte ziemlich gut. Aber es gibt einen großen Unterschied zwischen HelloWorldOnTomcat.java und einer echten Anwendung für echte Kunden. Ich bin mir sicher, dass Sie sich dessen bewusst sind.

Ich würde sagen, dass Sie in relativ kurzer Zeit ein anständiges Setup kompilieren können. Weder CDI noch JSF werden problematisch sein. Aber Je nach Ihren konkreten Anforderungen müssen Sie sich dann mit anderen Aspekten befassen, die nicht von einem gebrauchsfertigen Tomcat abgedeckt werden. Sicherheit, Clustering, Failover, Messaging, Asynchronität, um ein paar Bedenken zu nennen (Und Transaktionen, wie in den Kommentaren erwähnt).

Wenn Sie mit solchen Anforderungen (mehr oder weniger) vertraut sind und Ihr bevorstehendes Projekt eher entspannt ist und nicht die nächste Mars-Mission kontrollieren soll, würde ich es sicherlich versuchen.

Wenn Sie andererseits über solche Anforderungen informiert sind, würde ich nach (a) einem Setup auf einem Java EE App-Server oder (b) einem anderen Stack auf einem Tomcat suchen.

+5

Ich werde nur zu der Liste der Funktionen, die nicht von Tomcat + JSF und CDI abgedeckt sind, Transaktionsverwaltung hinzufügen. Wenn Ihre Anwendung nicht schreibgeschützt ist, benötigen Sie wahrscheinlich eine Transaktion und Sie müssen dafür ein externes Framework verwenden (Sie können dafür den Frühling verwenden) oder Sie selbst tun. Da JEE6-Container mindestens so leicht sind wie Tomcat, versuche etwas JEE6 zu schieben (TomEE kann ein guter Startpunkt sein;)) – Kazaag

4

einen Blick auf Apache Tomee Nehmen:

Apache TomEE, ausgesprochen "Tommy", ist ein All-Apache Java EE 6 Web Profil zertifiziert Stapel wo Tomcat Top-Hund. Apache TomEE ist zusammengestellt aus einer Vanille Apache Tomcat Zip-Datei. Wir beginnen mit Tomcat, fügen unsere Gläser hinzu und schließen den Rest zusammen. Das Ergebnis ist Tomcat mit den zusätzlichen Funktionen EE - TomEE.

+1

Ich habe es nie benutzt, aber gehört vom Projekt.Es wäre in der Tat sinnvoll, aber das Problem ist, wie ich in meinem Beitrag sagte, dass manchmal die Umgebung auf einer Kundenseite eingestellt ist, also ist Tomcat 7 installiert und wir können nur eine WAR-Datei bereitstellen. –

+1

In diesem Fall, denke ich, sollten Sie alle Komponenten in die WAR-Datei selbst verpacken. Die Verwendung von Maven sollte viel helfen. Ich weiß nicht mehr, ob Sie irgendeine Konfiguration im Container (Tomcat) für bestimmte Komponenten anpassen müssen. Auf jeden Fall könnte ein Blick auf die Apache TomEE-Website hilfreich sein, da sie eine voll funktionsfähige Integration des JEE-Stacks auf einem Apache Tomcat erreicht haben. –

Verwandte Themen