# Tomcat - Applications(Context) bekommen



## thE_29 (2. Jun 2009)

Ahoi!

Weiß jemand wie ich beim Tomcat (also wenn der läuft) auf andere Applications, bzw. deren ApplicationsContext zugreifen kann?

Habe 2 Anwendungen die untereinander kommunizieren sollen. Solange die auf getrennten Maschinen sind, funktioniert auch alles Tip Top!
Aber sobald die auf der gleichen Maschine sind bzw. Instanz, kriege ich ne Exception weil er zum Kommunizieren immer den gleichen Port belegt.

Also kann man da irgendwie drauf zugreifen?

mfg


----------



## gex (3. Jun 2009)

Wie greifst du denn aktuell auf den anderen Kontext zu?

Geht auf diese Weise (ist für Tomcat 5 geschrieben, ist aber meines wissens im 6er noch gleich):
Tomcat 5 und crosscontext-Konfiguration | Olaf's Blog

Das Schlagwort (Buzz-Word!) dazu ist Cross-Context, und das muss im Tomcat explizit für den Context erlaubt werden.


----------



## Noctarius (3. Jun 2009)

Sobald man sowas hat sollte man sich überlegen ob man nicht auf eine Enterprise Service Bus Archtiektur umsteigen mag


----------



## gex (3. Jun 2009)

Hehe, jep das isch schon so, hab die Sinnhaftigkeit nicht hinterfragen wollen.

Ob's dann gleich ein ESB sein muss sei mal dahingestellt - JMS dürfte bspw. für Vieles genügen.


----------



## Noctarius (3. Jun 2009)

Nen vollständiger ESB muss es ja nicht sein. Wir arbeiten immer mit einem Apache ServiceMix 4 Kernel. Der hat das absolute Minimum dabei und alles Andere lässt sich relativ easy über nen feature installer direkt in der Konsole nachinstallieren. Das ist imho schneller, einfacher und fehlerunanfälliger als nen Tomcat selbst mit JMS aufzuwerten. Zusätrzlich bekommt man bei ASM 4 direkt OSGi frei Haus mitgeliefert


----------



## gex (3. Jun 2009)

Hab ich noch nie eingesetzt (bzw. können  ), sieht aber auch interessant aus. Ich denke es kommt dann halt darauf an, was man mit nem ESB macht, vielerorts wird dann ein riesiger Monolith hingestellt, und dann stolz verkündet: Wir haben auch einen ESB ;-)

Ich denke es kommt auch auf das vorhandene Know-How an, wenn gewisses Knowledge über JMS vorhanden ist, und die Zeit drängt und kein Bedarf für etwas umfangereicheres besteht, so lohnt es sich dabei zu bleiben.

Ist auf alle Fälle von Fall zu Fall zu entscheiden, wie bei allem, aber Cross Context würde ich auch nicht produktiv einsetzen (der Betrieb hat meist nicht so Freude an solchen Dingen...)


----------



## Noctarius (3. Jun 2009)

Der Apache ServiceMix 4 Kernel hat das Bus Bundle selbst noch garnicht dabei, das muss man erst nachinstallieren  Ich benutz anstatt des Busses immer JMS oder alternativ benutzen wir in der Firma intern nur CXF.


----------



## thE_29 (3. Jun 2009)

Najo, wir nutzen noch XFire (Vorgänger von CXF) und halt Tomcat!

Normalerweise laufen diese 2 WebApps auf 2 verschiedenen Servern, da sie sehr rechenlastig sind. Haben halt extremst viele DB Zugriffe, etc...
Bei uns zB läuft es auf einen 2x4Core mit 8GB RAM und selbst da in 2 VMWares (die halt die Resourcen aufgeteilt haben). 

Aber ein Kunde will natürlich jetzt nur einen Tomcat Server haben und da kam eben dieser Fehler. Ich werde mal den XFire Source durchgucken wie er den den Port zum Lauschen aufmacht und das ggf. anpassen, da selbst mir das mit dem Context nicht so gefällt.
Ansonsten probiere ich mal das und wenn der Kunde dass dann wirklich auf einer Maschine fix haben will, gucke ich mir mal das von dir an.
Hast du da wo ne Doku zum Aufsetzen, konfigurieren und in welcher IDE kann ich da das am besten Testen?


----------



## Noctarius (3. Jun 2009)

Für was?


----------



## thE_29 (3. Jun 2009)

Von dem was du die ganze Zeit sprichst 
"Apache ServiceMix 4"


----------



## Noctarius (3. Jun 2009)

Findest du alles auf der Projektseite. Ansich alles sehr gut erklärt, bei Fragen scheu dich nicht, ich bin noch ein paar Minuten hier


----------



## thE_29 (3. Jun 2009)

So, habe jetzt mal auf CXF und Spring 2.5.5 umgestellt!

Soweit sogut, nur jetzt können die Flex Leute damit nicht mehr arbeiten. In der WSDL vom WebService ist zwar der Service + Methoden genauso noch erklärt wie früher, aber zB Klassen werden nicht mehr "erklärt".

Er nutzt zwar Klassen, aber die sind nie wo in einer WSDL definiert. Muss ich da selbst noch was machen oder warum wird das nicht automatisch gemacht?


----------



## Noctarius (3. Jun 2009)

Was meinst du mit Klassen? dein WSDL wird unter einer bestimmten URL zur Verfügung gestellt, genau wie der WebService


----------



## thE_29 (3. Jun 2009)

Naja, mein WSDL steht ja auch unter der URL zur Verfügung.

In der WSDL werden ja die Methodennamen und Klassen schön aufgelistet um diese zurückzubauen. Problem ist nun aber, dass die neue Version mir die Klassen (nenn sie halt Beans) nicht mehr aufgelistet werden.

Also der WebService an sich selbst ist schön in der WSDL erklärt. Also Methoden + Parameter + Rückgabe, etc..
Aber wenn ich zB bei einer Methode eine Klasse ABC erwarte, so war früher ABC am Anfang von der WSDL erklärt/beschrieben worden (also der Aufbau, Datentypen, etc..).
Das fehlt nun komplett. Ich habe nur den WebService und halt die Methoden, aber es werden keine eigenen Klassen mehr "erklärt".


----------



## Noctarius (3. Jun 2009)

Das ist ja auch nicht zwangsläufig der Wunsch eines WebServices. Ein WebService ist in erster Linie Sprachenunabhängig. Sieh es als eine reine RemoteInvoncation Lösung, wie du die Daten auf beiden Seiten speicherst ist deine Sache.

Wenn Ihr das bisher so gemacht habt, dann mag das ganz nett sein aber normal macht man das nicht so


----------



## thE_29 (4. Jun 2009)

Naja, das war bis jetzt auch Sprachenunabghängig!

Jede Klasse kann nachgebaut werden, da jede Klasse früher oder später auf primitive Datentypen aufbaut!

Und laut WSDL Spec geht das auch so. Die Klasse wurde in der WSDL vom WebService am Anfang erklärt. Also deren Aufbau. 

Weil die andere Schnittstelle kann ja mit int, string, float, etc.. umgehen (sonst könntest ja gar keine Methoden mit Paramtern aufrufen).
Und der Teil fehlt eben. Es werden die Klassen die drinnen verwendet werden (nenn sie Beans oder Managed beans) einfach nirgends mehr erklärt. 
Dadurch kann natürlich die Endschnittstelle (bei uns Adobe Flex) natürlich mit der Klasse nix anfangen, weil der das ja nicht kennt...

Achja, das Backend war bis jetzt Java, C++ und Adobe Flex. Also konnten 2 verschiedene Sprachen mit der WSDL was anfangen (und da ja nicht ICH sondern das Framework die WSDL generiert/bereitstellt, haben wir da sicher nicht was eigenes gemacht gehabt).


Kleines Bsp
WebService Methode: Vector<String> listNames(); würde funktionieren
So, jetzt will der aber String + noch was, also mache ich ne Klasse die intern einen String + int hat!
Dann sieht das so aus: Vector<MyClass> listNames();

Mit XFire wurde in der WSDL jetzt MyClass aufgelistet und die Parameter der Klasse (String name, int id) beschrieben.
Dadurch konnten die anderen Endpunkte damit was anfangen. Und genau das fehlt mir jetzt 
Er schreibt zwar in der WSDL Vector<MyClass> listNames() hin, aber dann regt sich Flex auf, dass der NameSpace MyClass nicht wirklich gefunden werden kann


----------



## Noctarius (4. Jun 2009)

Hm kann man bestimmt irgendwo einstellen, haben wir noch nie benutzt, da wir keine eigenen Datentypen benutzen die sich nicht direkt in XML abbilden lassen.
Ansonsten gibt es auch XML Schemata die genau solche Dinge beschreiben.


----------



## thE_29 (4. Jun 2009)

Naja, eine Klasse lässt sich ja auch in XML abbilden. Früher oder später ist alles eine Zahl oder ein Buchstabe (was auch ne Zahl ist).

Die Frage ist halt, wo ich das einstellen kann, dass er mir die Klassennamespaces auch in der WSDL deployed..


----------



## byte (4. Jun 2009)

Ruf mal die WSDL über den Browser auf, z.B. so http://localhost:8888/test/testWebservice?wsdl

Da sollte ein Import drin sein auf die XSD, wo die Klassenstruktur drin steht.

[XML]<wsdl:import location="http://localhost:8888/test/testWebservice?wsdl=TestWebService.wsdl" namespace="...">
    </wsdl:import>[/XML]

In diesem Fall also folgendes in den Browser pasten: http://localhost:8888/test/testWebservice?wsdl=TestWebService.wsdl


----------



## thE_29 (4. Jun 2009)

Ahaaaaa 
Das hat sich dort rein versteckt. Najo, hatten doch schon was relativ altes im Einsatz und anscheinend, haben die Adobe Flex Leute einen eigenen Parser gehabt.
Naja, jetzt habe ich keine Schuld mehr. Werde die Kollegen mal damit beauftragen


----------

