Verwendung von Eclipse Projekten im Axis2 Webservice

[TristanX]

Hallo,

ich arbeite mich gerade in die Webservice Entwicklung rein und habe da eine Frage zur Handhabung von Projekten.

Ich möchte in meinem Axis2 Web Service Funktionen eines anderen Projektes benutzen. Zum Kompilieren reicht es ja einfach im Build Path das entsprechende Projekt anzugeben.

Zur Laufzeit findet er dann natürlich die Klassen nicht.

Derzeit generiere ich mir jedes Mal ein jar Archiv, dass dann in das lib Verzeichnis kopiert wird.

Dies erscheint mir jedoch doch recht umständlich.
Wie macht ihr das bzw. gibt es da einen einfacheren besseren Weg durch irgendwelche integrierten Eclipse Funktionen ?

Gruß Christian

 

[Bär]

Hallo!

Ich habe ebenfalls eine Frage, die in die gleiche Kerbe haut:

Ein Projekt soll nun mit fremden Systemen zusammen arbeiten. Die fremden Systeme bieten diverse Webservices an. Somit benötigt meine Seite nur die Clients. Für das Ganze gibt es auch ein Demo System, dass zu Test/Dev Zwecken verwendet wird.

Frage:
Macht es Sinn, die WS Clients in ein anderes Projekt auszulagern und dieses dann im BuildPath des Ur-Projekts zu listen? Oder fange ich mir damit Nachteile ein? Wie macht ihr das?

Viele Grüße!

 

[knoppers]

Das kommt ganz darauf an.
- Was hast du für eine Projekt-Struktur?
- Ist der angeboten Webservice extern (Fremdanbieter wie z.B. Google) oder intern?
- Verwendest du den Client für den Webservice-Zugriff nur in einem Projekt, oder willst du diesen in verschieden Projekten nutzen?
- usw.

 

[Bär]

Hi!

Der WS liegt extern und ich verwende ihn nur in einem Projekt. Zur Struktur: Mehrschichten Model. Ich habe jetzt ein Package de.bim.bam.webservice.client und ein ein Package de.bim.bam.webservice.client.unittest erstellt.

Wegen Unittest muss ich den WS zuerst mit dem DEMO System verbinden. Was sich dann natürlich nicht schön deployen lässt. Daher die Idee entweder auslagern oder die beiden "bösen" Dateien mit den Verbindungsdaten aus dem Deploy Prozess auskoppeln.

Ich möchte erreichen, dass ich nicht versehentlich mal den TEST WS auf das LIVE System deploye.

 

[knoppers]

Hi!

Der WS liegt extern und ich verwende ihn nur in einem Projekt. Zur Struktur: Mehrschichten Model. Ich habe jetzt ein Package de.bim.bam.webservice.client und ein ein Package de.bim.bam.webservice.client.unittest erstellt.

Wegen Unittest muss ich den WS zuerst mit dem DEMO System verbinden. Was sich dann natürlich nicht schön deployen lässt. Daher die Idee entweder auslagern oder die beiden "bösen" Dateien mit den Verbindungsdaten aus dem Deploy Prozess auskoppeln.

Ich möchte erreichen, dass ich nicht versehentlich mal den TEST WS auf das LIVE System deploye.

Dann kannst du dies auch alles in ein Projekt machen.
Empfehlungen:

- Verbindungsdaten in Resource-Dateien auslagern, dann kann man auch Test und Echtumgebung trennen.

- Für Unittests ein extra Projekt erstellen (Android/Ant-Aufbau) oder Projektstruktur an die Standard Maven Struktur anpassen, bzw. nutzen.

Maven Bsp.:
src/main/java = Implementierungen/Java Source-Code
src/main/resources = Resource-Dateien für Echt-System
- connection.properties = Verbindungsdaten für Echtumgebung
src/test/java = Unittests, Mocking, selenium, cubic, usw.
src/test/resources = Resource-Dateien für Tests
- connection.properties = Verbindungsdaten für Testsystem
Wenn du jetzt noch Maven als Werkzeug einsetzt oder deine Konfigurationen in Eclipse richtig anpasst, werden die Tests niemals Richtung Echt-Umgebung gehen.

 

[Bär]

Danke für die Tipps!

 

[DerFeivel]

Erm...



Du musst dich für deine Unit-Tests mit einer anderen Komponente(=Webservice) verbinden?

Das das dann aber bereits ein Intergrationstest ist, ist dir vermutlich nicht bewusst.
Du testest dann nämlich nicht nur, dass sich deine Komponente wie gewünscht verhält
(wenn Webservice Wert A zurückliefert, tue dies...wenn Webservice Wert B zurückliefert, tue das...).
Vielmehr testest du das Zusammenspiel beider Komponenten.

Wenn sich nämlich dein Webservice -aus welchen Gründen auch immer- nicht mehr so wie erwartet verhält, schlagen dann auch die "Unit"-Tests in deiner Client-Implementierung fehl.
Du kannst in deinen Unit-Tests auch den Webservice simulieren, indem du ein Mock-Framework wie Mockito o.ä. benutzt.


Im Übrigen würde ich dir (wie Knoppers auch schon) ebenfalls Maven ans Herz legen. Ist zwar ne kleine Einstiegshürde. Ich persönlich will es aber nicht mehr missen.

 

[Bär]

Ich habe vom Hersteller des fremden Systems eine Demoversion. Diese habe ich auf einem eigenen (entfernten) Rechner installiert. Die Grenzen zwischen Integrationstest und Unittest verschwimmen hierbei ein wenig.

Ohne jetzt eine Diskussion lostreten zu wollen: "Mocken" gefällt mir nicht so gut. Aber Maven werde ich mir mal am Wochenende anschauen.

 

[DerFeivel]

Ich habe vom Hersteller des fremden Systems eine Demoversion. Diese habe ich auf einem eigenen (entfernten) Rechner installiert. Die Grenzen zwischen Integrationstest und Unittest verschwimmen hierbei ein wenig.

Ohne jetzt eine Diskussion lostreten zu wollen: "Mocken" gefällt mir nicht so gut. Aber Maven werde ich mir mal am Wochenende anschauen.

Hmm, nö. Nur weil du dem Kind einen anderen Namen gibst, wird kein anderes Kind draus.
Eindeutig ein Integrationstest.


Warum gefällt dir Mocken denn nicht so gut?