Supportnet / Forum / Anwendungen(Java,C++...)
Java EAR oder WAR erstellen
Frage
Hallo!
Ich habe das aktuelle J2SE, das aktuelle J2EE und die Java-Servlet-Classfiles (servlet-2_3-fcs-classfiles.zip). Letzteres habe ich in den Classpath eingetragen.
Ich habe ein kleines HelloWorldServlet.java. Das habe ich kompiliert zu HelloWorldServlet.class. Es ist auch kein Problem, daraus ein .jar-File zu erstellen.
Nun möchte ich das auf einem Application Server zum Laufen bringen. Mir steht der IBM WebSphere Application Server (kurz: WAS) zur Verfügung. Zu diesem WAS wird ein "Application Assembly Tool" mitgeliefert. Aber irgendwie komme ich damit nicht klar. Soweit ich bisher herausgefunden habe, brauche ich ein EAR- oder WAR-File. (Die Admin-Konsole sagt, ich könne ein EAR-, WAR-, oder JAR-Modul hochladen und installieren, aber ich kann lediglich Pfade für EAR- oder WAR-Module angeben.) Soweit ich das bisher beurteilen kann, will das Application Assembly Tool bereits ein EAR- oder WAR- oder sonstwas für eine Datei haben, um daraus das Gleiche (?) noch mal zu assemblieren. Da kommt scheinbar nur M Ü L L heraus.
Nun hat das J2EE ein sogenanntes Application Deployment Tool. Damit kann ich eine EAR-Datei erstellen und darin kann ich WAR- und JAR-Dateien einbinden. Ich habe eine EAR-Datei erstellt und die zuvor erstellte JAR-Datei meines Servlets als Lib eingebunden. Wenn ich das mit diesem Deployment Tool prüfen möchte, kommt erst ein Parse-Fehler und dann die Angabe, daß die application zusätzliche Elemente erfordere. Wenn ich es "deployen" lassen möchte, erhalte ich folgende Meldungen in der error.log:
java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.<init>(ZipFile.java:112)
at java.util.jar.JarFile.<init>(JarFile.java:127)
at java.util.jar.JarFile.<init>(JarFile.java:92)
at com.sun.enterprise.deployment.ApplicationArchivist.open(ApplicationArchivist.java:382)
at com.sun.enterprise.tools.deployment.backend.JarInstallerImpl.deployApplication(JarInstallerImpl.java:147)
at org.omg.stub.com.sun.enterprise.tools.deployment.backend._JarInstallerImpl_Tie._invoke(Unknown Source)
at com.sun.corba.ee.internal.corba.ServerDelegate.dispatch(ServerDelegate.java:355)
at com.sun.corba.ee.internal.iiop.ORB.process(ORB.java:255)
at com.sun.corba.ee.internal.iiop.RequestProcessor.process(RequestProcessor.java:84)
at com.sun.corba.ee.internal.orbutil.ThreadPool$PooledThread.run(ThreadPool.java:99)
Was soll mir das sagen Das einzige Zip-File, daß geöffnet werden sollte, ist die Servlet-Bibliothek im Classpath. Ist das aber wirklich damit gemeint??? Was nun?
Danke!
Schnoof
Antwort 1 von semi
Wahrscheinlich fehlt Dir noch der Deployment Descriptor oder die War-Datei ist falsch verpackt.
So soll die Verzeichnisstruktur aussehen:
WEB-INF/web.xml
WEB-INF/classes/...../DeinServlet.class
oder
WEB-INF/lib/...../DeinServlet.jar
Gruß,
Michael
So soll die Verzeichnisstruktur aussehen:
WEB-INF/web.xml
WEB-INF/classes/...../DeinServlet.class
oder
WEB-INF/lib/...../DeinServlet.jar
Gruß,
Michael
Antwort 2 von Schnoof
Ich habe bisher keine WAR-Datei auf irgendeine Weise erstellen können. Diese tollen Assembly oder Deployment Tools sind mir bisher ein kleines (oder eher ziemlich großes) Rätsel.
Ich glaube, ich brauche eine Schritt-für-Schritt-Anleitung. Unter anderem dachte ich nämlich bisher, daß diese web.xml irgendwie automatisch angelegt werden würde. Ich finde keine vernünftige Anleitungen bei IBM, die für Menschen wie mich gemacht sind. Ich versuche mich zum ersten Mal in meinem Leben (aber inzwischen schon seit 6 Wochen) an einem Application Server und an Servlets.
Was ist ein Deployment Descriptor? Dieses Application Assembly Tool kann einen generieren, nur bei mir klappte das bisher überhaupt nicht. In dem Application Deployment Tool konnte ich dazu noch gar nichts finden.
Danke!
Schnoof
Ich glaube, ich brauche eine Schritt-für-Schritt-Anleitung. Unter anderem dachte ich nämlich bisher, daß diese web.xml irgendwie automatisch angelegt werden würde. Ich finde keine vernünftige Anleitungen bei IBM, die für Menschen wie mich gemacht sind. Ich versuche mich zum ersten Mal in meinem Leben (aber inzwischen schon seit 6 Wochen) an einem Application Server und an Servlets.
Was ist ein Deployment Descriptor? Dieses Application Assembly Tool kann einen generieren, nur bei mir klappte das bisher überhaupt nicht. In dem Application Deployment Tool konnte ich dazu noch gar nichts finden.
Danke!
Schnoof
Antwort 3 von semi
Deployment Descriptor ist einer Art Beschreibung der zu installierenden Module.
Mit Websphere von IBM kenne ich mich nicht aus, ich verwende JBoss.
(Fast) jeder AppServer hat neben den Standard-Deployment-Decriptoren (nach J2EE Spezifikation) noch eigene Implementierungen. Klartext: Keiner blickt mehr durch und die App's sind nur mit viel Aufwand auf andere Server portierbar.
Ein Abhilfe schafft hier XDoclet. Man kann damit die DD's automatisch generieren lassen.
Versuche mal folgendes:
1) Erstelle folgende Verzeichnissstruktur
2)Inhalt von web.xml
3) Packe das ganze in eine Datei DeinServlet.WAR und deploye es.
Ich hoffe, es bringt Dich weiter. :)
Gruß,
Michael
Mit Websphere von IBM kenne ich mich nicht aus, ich verwende JBoss.
(Fast) jeder AppServer hat neben den Standard-Deployment-Decriptoren (nach J2EE Spezifikation) noch eigene Implementierungen. Klartext: Keiner blickt mehr durch und die App's sind nur mit viel Aufwand auf andere Server portierbar.
Ein Abhilfe schafft hier XDoclet. Man kann damit die DD's automatisch generieren lassen.
Versuche mal folgendes:
1) Erstelle folgende Verzeichnissstruktur
<WEB-INF>
|--- <classes>
| |-- HelloWorldServlet.class
|--- web.xml2)Inhalt von web.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<distributable/>
<servlet>
<servlet-name>HelloWorld</servlet-name>
<display-name>Hello World Servlet</display-name>
<servlet-class>HelloWorldServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>HelloWorld</servlet-name>
<url-pattern>/hello</url-pattern>
</servlet-mapping>
</web-app>
3) Packe das ganze in eine Datei DeinServlet.WAR und deploye es.
Ich hoffe, es bringt Dich weiter. :)
Gruß,
Michael
Antwort 4 von Schnoof
Wie packe ich es in MeinServlet.WAR???
Antwort 5 von semi
Es sind alles aufgemotzte ZIP-Dateien :)
Ob JAR, WAR, EAR oder ZIP ist egal. Die Erweiterung ist nur, um zu erkennen, was für ein Archiv es ist.
jar -c0Mf Hello.war WEB-INF
Gruß,
Michael
Ob JAR, WAR, EAR oder ZIP ist egal. Die Erweiterung ist nur, um zu erkennen, was für ein Archiv es ist.
jar -c0Mf Hello.war WEB-INF
Gruß,
Michael
Antwort 6 von Schnoof
Danke! :o) Nun bin ich doch um einiges schlauer. :o) Jetzt habe ich mein lang- und heiß-ersehntes WAR-Archiv. ;o)
Wenn ich die WAR-Datei in das Application Assembly Tool von IBM importiere, ist der Button für "Deploymentcode generieren" inaktiv.
Das Application Deployment Tool aus dem J2EE deployed es zu einem Server-JAR-File, das ich meinem WebServer geben soll. Das ist dann also nicht so ganz das, was ich eigentlich haben wollte.
Die Admin-Konsole meines Application Servers will den Pfad des Archivs und zusätzlich folgendes:
Stammkontext: Wird nur für eigenständige Webmodule (*.war) verwendet.
Sie müssen einen Stammkontext angeben, wenn das zu installierende Modul ein WAR-Modul ist.
Was muß ich da eingeben?
Danke!
Schnoof
Wenn ich die WAR-Datei in das Application Assembly Tool von IBM importiere, ist der Button für "Deploymentcode generieren" inaktiv.
Das Application Deployment Tool aus dem J2EE deployed es zu einem Server-JAR-File, das ich meinem WebServer geben soll. Das ist dann also nicht so ganz das, was ich eigentlich haben wollte.
Die Admin-Konsole meines Application Servers will den Pfad des Archivs und zusätzlich folgendes:
Stammkontext: Wird nur für eigenständige Webmodule (*.war) verwendet.
Sie müssen einen Stammkontext angeben, wenn das zu installierende Modul ein WAR-Modul ist.
Was muß ich da eingeben?
Danke!
Schnoof
Antwort 7 von semi
Wie ich schon geschrieben habe, Websphere kenne ich nicht. Dessen Tools auch nicht.
Wie auch immer. Ein Web-Archiv (WAR) muß nicht noch zusätzlich verpackt werden. WAR kann man direkt in den Web-Container schmeißen und es sollte laufen.
Die Frage nach dem Context... hmm.. Schreib dort / rein.
Funktioniert bei Websphere kein Hot-Deployment?
In JBoss brauche ich die zu deployenden Archive in ein spezielles Verzeichnis zu kopieren und das Ding wird automagisch deployed. Entferne ich es aus dem Verzeichnis, dann wird's undeployed.
Überschreibe ich es mit einer neueren Version, dann wird die alte undeployed und die neue deployed. Einfacher geht's nicht.
Wie auch immer. Ein Web-Archiv (WAR) muß nicht noch zusätzlich verpackt werden. WAR kann man direkt in den Web-Container schmeißen und es sollte laufen.
Die Frage nach dem Context... hmm.. Schreib dort / rein.
Funktioniert bei Websphere kein Hot-Deployment?
In JBoss brauche ich die zu deployenden Archive in ein spezielles Verzeichnis zu kopieren und das Ding wird automagisch deployed. Entferne ich es aus dem Verzeichnis, dann wird's undeployed.
Überschreibe ich es mit einer neueren Version, dann wird die alte undeployed und die neue deployed. Einfacher geht's nicht.
Antwort 8 von Schnoof
Noch eine etwas andere Frage. Mein HelloWorldServlet.java sieht wie folgt aus:
Da ist also keine main-Prozedur enthalten. Ich habe mehrere HelloWorld-Servlet-Beispiele immer ohne main gefunden. Brauche ich bei Servlets keine main-Prozedur?
Danke!
Schnoof
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class HelloWorldServlet extends HttpServlet
{
public final static String message = "<html>\n" +
"<head><title>Hallo Mitarbeiter</title></head>\n" +
"<body>\n" +
"<h1>Hallo Mitarbeiter</h1>\n" +
"<h2>der Stadtsparkasse Magdeburg</h2>" +
"</body></html>\n";
public void init()
{
System.out.println("In HelloWorldServlet init");
}
public void destroy()
{
System.out.println("In HelloWorldServlet destroy");
}
public void service(ServletRequest req, ServletResponse res)
throws ServletException, IOException
{
PrintWriter out = res.getWriter();
out.println(message);
}
}Da ist also keine main-Prozedur enthalten. Ich habe mehrere HelloWorld-Servlet-Beispiele immer ohne main gefunden. Brauche ich bei Servlets keine main-Prozedur?
Danke!
Schnoof
Antwort 9 von semi
"main" brauchst Du nur bei normalen Programmen. Ein Servlet arbeitet da ganz anders.
Wenn ein Servlet geladen wird, dann wird die Methode init aufgerufen.
An dieser Stelle könntest Du z.B. eine Datenbankverbindung herstellen oder auf EJB's zugreifen, kurz gesagt. Ressourcen initialisieren.
destroy wird, wie der Name schon sagt, beim Entfernen des Servlets aufgerufen (beim Beenden des Servers, oder beim undeployment). Hier sollte man alles freigeben (datenbankverbindung beenden etc.)
Die service-Methode ist auch ein Callback, dass von der Servlet-Engine mit Anfragen gefüttert wird.
service wird bei GET und bei POST Anforderungen aufgerufen. Es gibt noch alternativ, die Methoden doGet und doPost... Blabla...
Du kannst auf den Seiten von SUN ein Tutorial zu diesem Thema finden.
http://java.sun.com/j2ee/tutorial/1_3-fcs/index.html
Oder versuche es mit Google. Zum Thema Servlets gibt es inzwischen ganze Romane.
Viel Spaß dabei,
Michael
Wenn ein Servlet geladen wird, dann wird die Methode init aufgerufen.
An dieser Stelle könntest Du z.B. eine Datenbankverbindung herstellen oder auf EJB's zugreifen, kurz gesagt. Ressourcen initialisieren.
destroy wird, wie der Name schon sagt, beim Entfernen des Servlets aufgerufen (beim Beenden des Servers, oder beim undeployment). Hier sollte man alles freigeben (datenbankverbindung beenden etc.)
Die service-Methode ist auch ein Callback, dass von der Servlet-Engine mit Anfragen gefüttert wird.
service wird bei GET und bei POST Anforderungen aufgerufen. Es gibt noch alternativ, die Methoden doGet und doPost... Blabla...
Du kannst auf den Seiten von SUN ein Tutorial zu diesem Thema finden.
http://java.sun.com/j2ee/tutorial/1_3-fcs/index.html
Oder versuche es mit Google. Zum Thema Servlets gibt es inzwischen ganze Romane.
Viel Spaß dabei,
Michael
Antwort 10 von Schnoof
Den Stammkontext / hat bereits die DefaultApplication. Nun habe ich dort /hello eingegeben. Dann wurde sie erfolgreich installiert und gestartet. Ich habe aber leider noch nicht herausgefunden, wie ich diese Application mit dem Server aufrufe. Also konnte ich noch nicht testen. Aber trotzdem vielen Dank für Deine Hilfe! Ich bin schon sehr viel weiter als zuvor. Danke!
Bis denne!
Schnoof
Bis denne!
Schnoof
Antwort 11 von semi
Versuche es mal mit
http://localhost:8080/hello
oder
http://localhost:8080/ARCHIVNAME-ohne-.WAR/hello
http://localhost:8080/hello
oder
http://localhost:8080/ARCHIVNAME-ohne-.WAR/hello
Antwort 12 von semi
Antwort 13 von Schnoof
Ich habe probiert (Servlet-Klasse = HelloWorldServlet, WAR = hello.war, Enterprise-Application auf Server = hello_war):
http://localhost:8080/hello
http://localhost:8080/hello_war/hello http://localhost:8080/hello/hello
http://localhost:8080/HelloWorldServlet/hello
http://localhost:8080/hello_war
http://localhost:8080/HelloWorldServlet
Es kamm immer "Die Seite kann nicht angezeigt werden" zurück.
Dann habe ich das ganze auf dem Port 9080 versucht, da die Beispielanwendungen auf diesem Port laufen, und da erhielt ich "Die Seite wurde nicht gefunden".
Ich habe den Stammkontext einmal auf "/hello" und einmal auf "hello" gesetzt. Das Ergebnis blieb das gleiche.
Tausche ich Stammkontext und die Verzeichnis-Variante davor, erhalte ich die gleichen Ergebnisse.
Kann vielleicht mal jemand vorbeischauen und gucken? ;o)
Ich weiß echt nicht mehr weiter!
Danke!
Schnoof
http://localhost:8080/hello
http://localhost:8080/hello_war/hello http://localhost:8080/hello/hello
http://localhost:8080/HelloWorldServlet/hello
http://localhost:8080/hello_war
http://localhost:8080/HelloWorldServlet
Es kamm immer "Die Seite kann nicht angezeigt werden" zurück.
Dann habe ich das ganze auf dem Port 9080 versucht, da die Beispielanwendungen auf diesem Port laufen, und da erhielt ich "Die Seite wurde nicht gefunden".
Ich habe den Stammkontext einmal auf "/hello" und einmal auf "hello" gesetzt. Das Ergebnis blieb das gleiche.
Tausche ich Stammkontext und die Verzeichnis-Variante davor, erhalte ich die gleichen Ergebnisse.
Kann vielleicht mal jemand vorbeischauen und gucken? ;o)
Ich weiß echt nicht mehr weiter!
Danke!
Schnoof
Antwort 14 von Schnoof
Also, Port 9080 liefert immer den HTTP 404 zurück.
Nun habe ich irgendwo in der Hilfe folgendes gefunden. Zum schnellen Deployment soll ich die Servlet-class-Dateien in ein solches Verzeichnis packen: DefaultApplication.ear\DefaultWebApplication.war\WEB-INF\classes
Dann soll ich im Browser http://localhost:9080/servlet/KlassenName aufrufen.
Wenn ich so mein HelloWorldServlet aufrufe, klappt das tatsächlich.
In diesem Verzeichnis befinden sich schon 3 weitere class-Dateien, die ich alle so aufrufen kann. In dem Verzeichnis DefaultWebApplication.war befindet sich auch eine index.html, die die 3 Standard-Servlets aufrufen kann. Nur kriege ich die nicht über meinen Web-Server gestartet.
Ich habe mir noch einmal die mitgelieferten Beispielanwendungen angeschaut. Da wird das Servlet über Stammkontext/servlet/KlassenName aufgerufen. Bei mir funktioniert das leider nicht. :o( Ich hab auch keine Unterschiede in der application.xml und web.xml gefunden. Es ist alles äquivalent.
Ich habe die WAR inzwischen mehrmals neu mit der Admin-Konsole installiert mit verschiedenen Stammkontexten etc. Aber es hat nie funktioniert.
Nun habe ich irgendwo in der Hilfe folgendes gefunden. Zum schnellen Deployment soll ich die Servlet-class-Dateien in ein solches Verzeichnis packen: DefaultApplication.ear\DefaultWebApplication.war\WEB-INF\classes
Dann soll ich im Browser http://localhost:9080/servlet/KlassenName aufrufen.
Wenn ich so mein HelloWorldServlet aufrufe, klappt das tatsächlich.
In diesem Verzeichnis befinden sich schon 3 weitere class-Dateien, die ich alle so aufrufen kann. In dem Verzeichnis DefaultWebApplication.war befindet sich auch eine index.html, die die 3 Standard-Servlets aufrufen kann. Nur kriege ich die nicht über meinen Web-Server gestartet.
Ich habe mir noch einmal die mitgelieferten Beispielanwendungen angeschaut. Da wird das Servlet über Stammkontext/servlet/KlassenName aufgerufen. Bei mir funktioniert das leider nicht. :o( Ich hab auch keine Unterschiede in der application.xml und web.xml gefunden. Es ist alles äquivalent.
Ich habe die WAR inzwischen mehrmals neu mit der Admin-Konsole installiert mit verschiedenen Stammkontexten etc. Aber es hat nie funktioniert.
Antwort 15 von semi
Sorry, von Websphere habe ich keine Ahnung.
Ich verstehe nur nicht, wozu Du immer wieder versuchst das WAR zusätzlich noch in ein EAR zu verpacken. Das brauchst Du nicht, wenn es ein einfaches Servlet ist.
Wenn Du doch ein EAR verwendest, dann muss das Archiv wieder einen Deployment-Descriptor (meta-inf/application.xml) für die einzelnen Module haben. In Deinem Fall also ein einzelnes WAR Archiv.
So sieht die application.xml aus:
Ich habe ein einfaches Beispiel ins Netz gestellt. Guckst Du hier
Du kannst es, wenn Dein Server nicht spinnt, mit http://localhost:9080/Hello aufrufen. (Wenn 9080 Port des Servers ist)
Gruß,
Michael
Ich verstehe nur nicht, wozu Du immer wieder versuchst das WAR zusätzlich noch in ein EAR zu verpacken. Das brauchst Du nicht, wenn es ein einfaches Servlet ist.
Wenn Du doch ein EAR verwendest, dann muss das Archiv wieder einen Deployment-Descriptor (meta-inf/application.xml) für die einzelnen Module haben. In Deinem Fall also ein einzelnes WAR Archiv.
So sieht die application.xml aus:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE application PUBLIC "-//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN"
"http://java.sun.com/dtd/application_1_3.dtd">
<application>
<display-name>Hello World Web App</display-name>
<module>
<web>
<web-uri>hello.war</web-uri>
<context-root>hello</context-root>
</web>
</module>
</application>Ich habe ein einfaches Beispiel ins Netz gestellt. Guckst Du hier
Du kannst es, wenn Dein Server nicht spinnt, mit http://localhost:9080/Hello aufrufen. (Wenn 9080 Port des Servers ist)
Gruß,
Michael
Antwort 16 von Schnoof
Ich versuche gar nichts in eine ear zu packen. Ich weiß auch gar nicht, was in einer ear drin sein muß.
Ich habe lediglich mit der Admin-Konsole die WAR installiert und für die WAR einen Stammkontext angegeben. Alles andere habe ich auf Standard-Einstellungen gelassen. Und diese Admin-Konsole oder der Server oder was auch immer hat eine application.xml erstellt.
Wenn ich wüßte, wozu das alles gut und ob das alles richtig ist, würde ich sicher nicht mit so vielen Fragen dastehen. Die IBM-Hilfe hilft mir nicht weiter. Die hat mir nur genau das gesagt, was ich eh schon gemacht hatte.
Weiß irgendjemand, ob es irgendwo einen Vergleich zwischen den verschiedenen existierenden Application Servern gibt? Vielleicht sollte ich mir sowas mal zu Gemüte führen und einen anderen Server als WebSphere empfehlen.
Danke!
Schnoof
Ich habe lediglich mit der Admin-Konsole die WAR installiert und für die WAR einen Stammkontext angegeben. Alles andere habe ich auf Standard-Einstellungen gelassen. Und diese Admin-Konsole oder der Server oder was auch immer hat eine application.xml erstellt.
Wenn ich wüßte, wozu das alles gut und ob das alles richtig ist, würde ich sicher nicht mit so vielen Fragen dastehen. Die IBM-Hilfe hilft mir nicht weiter. Die hat mir nur genau das gesagt, was ich eh schon gemacht hatte.
Weiß irgendjemand, ob es irgendwo einen Vergleich zwischen den verschiedenen existierenden Application Servern gibt? Vielleicht sollte ich mir sowas mal zu Gemüte führen und einen anderen Server als WebSphere empfehlen.
Danke!
Schnoof
Antwort 17 von semi
Hi,
Wenn Du vor hast, nur Servlets und evtl. JSP zu lernen, dann bist Du mit Apache Tomcat gut bedient. Es ist kein App.-Server sondern "nur" JSP/Servlet-Engine.
Für Servlets/JSP + EJB (SB, MDB und CMP, kein BMP) dann Resin EE. (sehr gute Alternative zu Apache Webserver)
Sonst kann ich nur JBoss mit Tomcat als JSP/Servlet-Engine empfehlen.
Gruß,
Michael
Wenn Du vor hast, nur Servlets und evtl. JSP zu lernen, dann bist Du mit Apache Tomcat gut bedient. Es ist kein App.-Server sondern "nur" JSP/Servlet-Engine.
Für Servlets/JSP + EJB (SB, MDB und CMP, kein BMP) dann Resin EE. (sehr gute Alternative zu Apache Webserver)
Sonst kann ich nur JBoss mit Tomcat als JSP/Servlet-Engine empfehlen.
Gruß,
Michael
Antwort 18 von Schnoof
Ich mache es nicht aus reinem Vergnügen und es wird wohl nicht bei Servlets bleiben.
Letzten Endes sollen verschiedene Anwendungen (u.a. Datenbankanwendungen für sensible Daten) auf einem Anwendungsserver zur Verfügung gestellt werden. Dafür wurde mir der WebSphere Application Server zur Verfügung gestellt. Ich soll mich damit vertraut machen und letzten Endes meinem Chef alles erklären.
Wenn es einen Server gibt, der mindestens genauso gut und leichter zu bedienen ist (bzw. für den es bessere Hilfen und Manuals gibt), kann ich den sicher meinem Chef empfehlen. Da der WebSphere noch nicht gekauft wurde und ich derzeit nur mit einem 6-Wochen-Trial arbeite, wäre das sicher kein Problem.
Daher wäre mir ein etwas ausführlicherer Vergleich verschiedener Server lieber. ;o)
Sollte irgendjemand per Zufall ein ausführliches und Anfänger-freundliches Manual für den WebSphere Application Server finden, würde ich mich total freuen, wenn ich davon erfahren sollte!
Danke!
Schnoof
Letzten Endes sollen verschiedene Anwendungen (u.a. Datenbankanwendungen für sensible Daten) auf einem Anwendungsserver zur Verfügung gestellt werden. Dafür wurde mir der WebSphere Application Server zur Verfügung gestellt. Ich soll mich damit vertraut machen und letzten Endes meinem Chef alles erklären.
Wenn es einen Server gibt, der mindestens genauso gut und leichter zu bedienen ist (bzw. für den es bessere Hilfen und Manuals gibt), kann ich den sicher meinem Chef empfehlen. Da der WebSphere noch nicht gekauft wurde und ich derzeit nur mit einem 6-Wochen-Trial arbeite, wäre das sicher kein Problem.
Daher wäre mir ein etwas ausführlicherer Vergleich verschiedener Server lieber. ;o)
Sollte irgendjemand per Zufall ein ausführliches und Anfänger-freundliches Manual für den WebSphere Application Server finden, würde ich mich total freuen, wenn ich davon erfahren sollte!
Danke!
Schnoof
Antwort 19 von semi
Einen ausführlichen Vergleich aller Application Server auf dem Markt kenne ich nicht. Man müsste zuerst die Kriterien bestimmen, nach denen ein solcher Test durchgeführt werden sollte. Wenn man mit so einem Evaluiierungsbericht fertig wäre, dann wäre er bereits veraltet. Insbesondere die Opensource-Welt (jBoss, jonas) ist dafür zu schnell.
Um wirklich objektiv zu bleiben, müsste man etwas an Erfahrung im Umgang mit den einzelnen Servern mitbringen und das kostet viel Zeit.
Auf der folgenden Seite findest Du einen Technologie-Vergleich "aller" Server.
EJB Marix
Das Forum auf der genannten Seite ist sehr gut. Frage dort nach einen Tutorial für Websphere.
Gruß,
Michael
Um wirklich objektiv zu bleiben, müsste man etwas an Erfahrung im Umgang mit den einzelnen Servern mitbringen und das kostet viel Zeit.
Auf der folgenden Seite findest Du einen Technologie-Vergleich "aller" Server.
EJB Marix
Das Forum auf der genannten Seite ist sehr gut. Frage dort nach einen Tutorial für Websphere.
Gruß,
Michael
Antwort 20 von Schnoof
Michael,
Deine hello-beispiel.ear konnte ich problemlos mit der Admin-Konsole installieren und genau so aufrufen, wie Du sagtest. Funktioniert tadellos.
Aber warum das mit der WAR nicht funktioniert, verstehe ich nicht. Mal schauen, ob ich irgendwie jemanden auftreiben kann, der sich mit dem WAS auskennt.
Danke!
Schnoof
Deine hello-beispiel.ear konnte ich problemlos mit der Admin-Konsole installieren und genau so aufrufen, wie Du sagtest. Funktioniert tadellos.
Aber warum das mit der WAR nicht funktioniert, verstehe ich nicht. Mal schauen, ob ich irgendwie jemanden auftreiben kann, der sich mit dem WAS auskennt.
Danke!
Schnoof
Antwort 21 von Schnoof
Kann mir bitte noch einmal jemand mitteilen, was in ein EAR-Archiv gehört? Nur die META-INF mit application.xml und eine ganz normale WAR-Datei? Oder muß die WAR-Datei anders aussehen?
Danke!
Schnoof
Danke!
Schnoof
Antwort 22 von semi
In ein EAR werden i.d.R. nur WAR's, und EJB-Jar's gepackt.
So ungefähr sieht es aus:
Hol' Dir irgendein Dickes Buch zu J2EE, sowas funktioniert unabhängig vom verwendeten Server.
Ich kann Dir die folgenden Seiten/Bücher empfehlen.
Mastering Enterprise Java Beans
EJB Design Patterns
The J2EE 1.3 Tutorial
The J2EE 1.4 Tutorial
Gruß,
Michael
So ungefähr sieht es aus:
[myapp.ear]
|-- <META-INF>
| |-- application.xml DTD 1.3
|
|-- [mywebapp.war]
| |-- <WEB-INF>
| | |-- web.xml DTD 2.3
| | |
| | |-- <classes>
| | | |-- my/package/MyServlet.class (*1)
| |
| | |-- <lib>
| | |-- myservlet.jar (alterativ zu *1)
| |
| |-- index.jsp
| |-- noch-eins-aber.html
| |-- irgendwas.dat
|
|-- [myejbapp1.jar]
| |-- <META-INF>
| | |-- ejb-jar.xml DTD 2.0
| |
| |-- my/package/MySessionBean.class
| |-- my/package/MySessionHome.class
| |-- my/package/MySessionRemote.class
| |-- my/package/MySessionLocalHome.class
| |-- my/package/MySessionLocal.class
| |-- usw.
|
|-- [myejbapp2.jar]
|-- usw.
Hol' Dir irgendein Dickes Buch zu J2EE, sowas funktioniert unabhängig vom verwendeten Server.
Ich kann Dir die folgenden Seiten/Bücher empfehlen.
Mastering Enterprise Java Beans
EJB Design Patterns
The J2EE 1.3 Tutorial
The J2EE 1.4 Tutorial
Gruß,
Michael
Antwort 23 von Schnoof
Ich hab's geschafft, meine WAR-Datei im Browser aufzurufen. Man muß folgendes angeben:
http://localhost:9080/<Stammkontext>/<Servlet Mapping>
Danke!
Schnoof
http://localhost:9080/<Stammkontext>/<Servlet Mapping>
Danke!
Schnoof

