JBoss 4.2

[Gaststh]

Hallo,

ich mach es kurz, ich habe zwei Fragen:

1) Welchen JPA-Provider für CMP nutzt JBoss in der Version 4.2 als Standard?
(Und woran erkenn ich das, wo steht das?)

2) Ist der einzige Grund, warum man auf einem (Java) Webserver NUR Tomcat anstatt JBoss (inkl. Tomcat!) laufen lässt, auf die Ressourcen zurückzuführen?

Im Prinzip bietet JBoss doch einen VOLLWÄRTIGEN Tomcat inklusive, oder?

Vielen Dank euch Allen.

sth

[Abnaxos]

1) Welchen JPA-Provider für CMP nutzt JBoss in der Version 4.2 als Standard?
(Und woran erkenn ich das, wo steht das?)


Da Hibernate inzwischen ein JBoss-Projekt ist: Hibernate. :)

2) Ist der einzige Grund, warum man auf einem (Java) Webserver NUR Tomcat anstatt JBoss (inkl. Tomcat!) laufen lässt, auf die Ressourcen zurückzuführen?

Im Prinzip bietet JBoss doch einen VOLLWÄRTIGEN Tomcat inklusive, oder?

Schlankheit und Eleganz. Daher IMHO auch nicht Tomcat verwenden, sondern Jetty (http://jetty.mortbay.org/). ;) Der ganze J2EE-Mist ist IMHO ein grauenhafter Bloat, der in 90% der Fälle, wo es eingesetzt wird, die Sache einfach unglaublich kompliziert und träge macht, wo es doch viel einfacher gegangen wäre. Nur in ca. 10% der Fälle macht das alles tatsächlich Sinn und ist eine Hilfe, statt ein Hindernis.

[Gast]

Au backe. Das ist doch mal ne Aussage... :) Im Ernst: wirklich sehr interessant!

Wir entwickeln zur Zeit die Webschicht mittels JSP/Servlets (Struts) für Tomcat und arbeiten im Businessbereich mit JBoss 4.2 zusammen. Soll auf getrennten Rechnern laufen später...

Du sagst, im Produktivsystem sollen wir statt Tomcat nun einfach Jetty verwenden? Das geht, ohne irgendwelche Adaptionen?
Wann wäre deiner Aussage nach unbedingt ein Tomcat notwendig?

[SGT.Hawk]

Gar nicht. Tomcat ist eben nur ein Servlet-Container, mehr nicht. Es eignet sich eben sehr gut als Testumgebung, bzw. als Connector zum Apache.

[Abnaxos]

Wir entwickeln zur Zeit die Webschicht mittels JSP/Servlets (Struts) für Tomcat und arbeiten im Businessbereich mit JBoss 4.2 zusammen. Soll auf getrennten Rechnern laufen später...

Was genau heisst "getrennte Rechner"? Business auf einem und Web auf einem, oder durchgehendes Clustering? Einfaches Remoting ist das, was ich meinte: Geht auch einfacher und leichtgewichtiger. Wenn du durchgehend Clustering betreibst, kommst du langsam in den Bereich der von mir erwähnten 10% der Fälle.

Du sagst, im Produktivsystem sollen wir statt Tomcat nun einfach Jetty verwenden? Das geht, ohne irgendwelche Adaptionen?
Ich finde Jetty besser, er ist leichtgewichtiger (lässt sich problemlos auch aufblasen, wenn man will/muss), fühlt sich allgemein Fixer an und ist recht elegant programmiert.

WebApps müssen meist nicht angepasst werden, es gibt aber Fälle, wo es zu Inkompatibilitäten kommen kann. Es kann sich um eine "komisch" programmierte WebApp handeln und/oder um Bugs im Servlet Container (auf beiden Seiten). Normalerweise gibt es keine Probleme.

Wann wäre deiner Aussage nach unbedingt ein Tomcat notwendig?
Eigentlich nie. Beides sind Servlet-Container und implementieren die Spezifikation.

[Gast]

Naja, bei uns handelt es sich im Prinzip (noch) um "elementares Remoting" - ein seperater Rechner für das Webfrontend und ein weiterer (später eben evtl. mehrere) für die Businessschicht.

Während der Entwicklung haben wir nur JBoss im Einsatz, bringt ja schließlich auch eine Servletengine mit... :)

Wegen dem Hinweis, dass Jetty "eleganter" läuft: werden wir testen. Dann schaut es eben so aus: Jetty für Webfrontend und JBoss für Business-Tier. Mal schauen...

Webserviceanfragen lassen wir übrigens gleich auf JBoss drauf. Sprich externe Clients (Keine HTTP-Surfer) dürfen unsere Webservice-Beans unmittelbar "direkt" auf der Businessschicht nutzen.

Weiterhin binden wir auch verschiedene externe Provider direkt an den JBoss an. Dort werden deren Funktionen per @local Bean direkt genutzt...



Was wir noch nicht wissen: Wenn ich eine Schnittstelle zu einen externen Provider (Datenquelle, Telefonauskunft, Paypal usw) auf JBoss implementiere, so dass ich dort in der gesamten Business-Tier diese Providerfunktionen nutzen kann, wie verhindere ich, dass die Implementierungsklassen mehrfach instanziiert werden? Singleton? Naja, bei einem Ressourcenpooler wie JBoss nicht sooo einfach... Oder sollte man externe Provider "woanders" anbinden?

[Abnaxos]

Erstmal als Warnung: Es ist spät und ich nicht mehr ganz nüchtern. ;) Aber das muss ich jetzt noch loswerden:

Was wir noch nicht wissen: Wenn ich eine Schnittstelle zu einen externen Provider (Datenquelle, Telefonauskunft, Paypal usw) auf JBoss implementiere, so dass ich dort in der gesamten Business-Tier diese Providerfunktionen nutzen kann, wie verhindere ich, dass die Implementierungsklassen mehrfach instanziiert werden? Singleton? Naja, bei einem Ressourcenpooler wie JBoss nicht sooo einfach... Oder sollte man externe Provider "woanders" anbinden?

Du erwähnst Singletons. Wie genau willst du in einer verteilten Umgebung, wo also auf mehreren Rechnern jeweils (mindestens) eine JVM läuft, und wo ein Load-Balancer bestimmt, welche Anfrage an welchen Rechner geht, sowas wie einen Singleton realisieren? Richtig: Geht nicht, unmöglich.

Und hier sind wir genau bei der Komplexität von J2EE:

1. In den wenigsten Fällen wird das, was dir J2EE wirklich bietet, überhaupt benötigt, erstmal wird alles verkompliziert.

2. Wenn du in der Situation bist, dass dir das helfen kann, funktioniert das nicht einfach so "magisch", J2EE kocht auch nur mit Wasser. Das fängt schon damit an, dass du bereits bei einem simplen Servlet-Container darauf achten musst, dass alles, aber auch alles, was du in die Session schmeisst, auch Serializable ist, mit allen Folgen.