RMI

[SGT.Hawk]

Hi, habe ein kleines Problem.
ICh benutze ein Client/Server System. Ein Client hat eine GUI mit SWT, wo er drauf Daten schreiben kann, die werden aber zum Server geschickt und und da von einem XML Datei geschrieben/gelesen. Für XML benutze ich JDOM.Hm, soweit so gut.Lokale Aufrufe zum löschen gehen, aber sobald ich sie entfernt aufrufe, löscht er mir den Knoten nicht mehr:confused:
ICh weiss nicht warum, obwohl der Knoten aus der XMl Liste kommen MUSS, d.h es muss darin enthalten sein, geht es dennoch nicht.Serialisierungsproblem vielleicht?

[Senior Sanchez]

So ganz bin ich jetzt nicht durchgestiegen, aber ums mal kurz zu umreißen, was ich glaube was du meinst:

Du hast ne geparste XML-Struktur auf der Server-Seite, eben Node-Objekte.
Diese Objekte schickste jetzt zum Teil per RMI an den Client, der diese darstellt. Dort willst du dann auch ein Node aus der Struktur löschen, was auch dann auf der Serverseite passieren soll?

Ist das soweit richtig?

[SGT.Hawk]

Ja, richtig.Allerdings ist es noch inefizient. Ich könnte auch einfach die Indces zum Server schicken, der dann seine List löscht, aber das ist erstmal egal.Ich fasse nochmal kurz zusammen.
Client-> macht Anfrage über bestimmte Such kriterien.
Server-> bekommt per RMI Anfrage und durchsuch seine List un gibt eine temporäre ArrayList zurück.
Wenn Client jetzt was löschen will, wird das Element zum Server per RMI geschickt und der sollte dann in seiner richtigen Liste suchen und sie löschen, aber genau dann findet er sie nicht und löscht sie auch nicht, das ist das komische, denn das Element muss es ja geben.

[Senior Sanchez]

SGT.Hawk[/POST]']Ja, richtig.Allerdings ist es noch inefizient. Ich könnte auch einfach die Indces zum Server schicken, der dann seine List löscht, aber das ist erstmal egal.Ich fasse nochmal kurz zusammen.
Client-> macht Anfrage über bestimmte Such kriterien.
Server-> bekommt per RMI Anfrage und durchsuch seine List un gibt eine temporäre ArrayList zurück.
Wenn Client jetzt was löschen will, wird das Element zum Server per RMI geschickt und der sollte dann in seiner richtigen Liste suchen und sie löschen, aber genau dann findet er sie nicht und löscht sie auch nicht, das ist das komische, denn das Element muss es ja geben.

Achso, ich dachte du löscht direkt aufm Client was inner Liste und das soll er dann unter der Annahme es seien dieselben Objekte (also wirklich dieselben!) aufm Server auch dort entsprechend gelöscht haben, aber wie du schon merkst, ist da nen aber und zwar das eben sowohl der Client als auch der Server einen eigenen Adressraum besitzen. Und somit auch jeder seine Objekte hat, es gibt quasi nur Kopien.

Kannst du nen debugger mal benutzen und mal in die Zeilen reinschauen, wo der Server das Objekt in seiner Liste sucht? Schaue dir auch mal die Liste an, ob das Element wirklich da ist.

[SGT.Hawk]

Hm, Remote Debugger geht leider nicht.Die Objekte müssen ja da sein, die kommen doch vom Server auf dem Client.
@edit die Routinen zum löschen kommen von der JDOM API, ergo müssten die gehen,habe mal kurz umgestellt auf lokale Aufrufe, da gehts ja.

[Senior Sanchez]

SGT.Hawk[/POST]']Hm, Remote Debugger geht leider nicht.Die Objekte müssen ja da sein, die kommen doch vom Server auf dem Client.
@edit die Routinen zum löschen kommen von der JDOM API, ergo müssten die gehen,habe mal kurz umgestellt auf lokale Aufrufe, da gehts ja.

Du hast doch gesagt, dass du an den Server das Objekt schickst was er löschen soll, ne?

Dafür muss es ja auch ne Routine geben, weil shared references gibts ja nicht ;) In dieser Methode kannste doch nen Breakpoint setzen und dann reindebuggen, oder nicht?

[SGT.Hawk]

Nein, habe ich versucht, geht unter eclipse und dem Standard Java Debugger nicht.Ich denke mal, so wie ich es gelesen habe. Ich schicke, dem Server ja ein Objekt wieder zurück, der muss allerdings ein neues Objekt von dem Typ erzeugen und den mit "Leben" füllen, Vielleicht sind sie dann nicht mehr identisch?

[Senior Sanchez]

SGT.Hawk[/POST]']Nein, habe ich versucht, geht unter eclipse und dem Standard Java Debugger nicht.Ich denke mal, so wie ich es gelesen habe. Ich schicke, dem Server ja ein Objekt wieder zurück, der muss allerdings ein neues Objekt von dem Typ erzeugen und den mit "Leben" füllen, Vielleicht sind sie dann nicht mehr identisch?

Wenn du über equals vergleichst ist das wurscht. Dann erkennt er auch Kopien als gleich. Per == sollteste natürlich nicht vergleichen, weil damit ja nur die Referenzen verglichen werden und das wird scheitern.


PS: Hmm, dass mit dem debuggen ist komisch aber es könnte stimmen. Das Problem ist ja, dass er das ja im rmid dienst ausführt und da reinzudebuggen, hmm, geht wohl anscheinend nicht so einfach wie ich dachte. Ist schon länger her seitdem ich das letzte mal mit rmi zu tun hatte ;)

[SGT.Hawk]

Nene, bin ja kein Java Anfänger:wink:.Kommt ja auch nicht vor im Code, ist ja der Code vom XML-API.Na ja,kommt mir doch spanisch vor, da ich dachte Java könnte das richtig serialisieren und deserialisieren oder liegt an der JDOM API.

[Senior Sanchez]

Das ist auch echt spanisch.

Wennde mal Zeit hast (und ich Lust :D), kannste dann mal deinen Code online stellen und bitte die JDOM-Api dazu (nicht dass es an ner speziellen version liegt). Dann schaue ich mal rein, dann findet man vllt leichter Fehler.

[SGT.Hawk]

public List getXMLDoc(){
return xmlDoc.getRootElement().getChildren();
}
public void deleteXMLEntry(Element del) {
System.out.println(xmlDoc.getRootElement().removeContent(del));
}

Das ist der Code, der remote ausgeführt wird.xmlDoc ist die geparste Baumstruktur.Mehr wird nicht gemacht.JDOM ist zu gross,um es hier zu posten.www.jdom.org (http://www.jdom.org) hat die packages.
PS: Werde es mal mit XOM versuchen.

[Senior Sanchez]

Hmm, da weiß ich auch nicht wirklich genau, zumal ich jetzt hier keine Sourcen habe.

Es könnte jetzt natürlich wirklich ne Sache mitm serialisieren sein.
Ein Feld ist dann eben transient und wird nicht übertragen. Das könnte dann auch zur Folge haben das beim zurückübertragen vom Client zum Server ja ein etwas anderes Objekt vorliegt und somit der equals-Vergleich fehlschlägt.

Wo liegt eigentlich der Unterschied zwischen removeContent und removeChild?

[SGT.Hawk]

So, ungefähr denke ich das auch, aber die PArent schnittstelle ist Serialitable, deswegen komisch.....
RemoveContent= Kettet einen Kindsknoten aus
RemoveChild= genau das gleiche, nur immer das erste Knoten, was für mich nicht in Frage kommt, da ein gesuchter Knoten nicht immer am Anfang stehen muss.

[Senior Sanchez]

SGT.Hawk[/POST]']So, ungefähr denke ich das auch, aber die PArent schnittstelle ist Serialitable, deswegen komisch.....
RemoveContent= Kettet einen Kindsknoten aus
RemoveChild= genau das gleiche, nur immer das erste Knoten, was für mich nicht in Frage kommt, da ein gesuchter Knoten nicht immer am Anfang stehen muss.

Serilizable ist bloß ein Marker-Interface mit dem der Programmierer der Klasse garantiert, dass es sich serialisieren lässt. Trotzdem können Objekte oder Variablen simpler Datentypen von der Serialisierung ausgeschlossen werden, nämlich mit transient. Kommt so ein Ausschluss zustande, und ist diese Variable für einen Vergleich notwendig, so ergeben sich nach dem anschließenden Zurücksenden ja Differenzen (auf Serverseite ist die Variable mit einem bestimmten Wert belegt, aber was zurückkommt vom Client hat diesen Wert nicht obwohl das gleiche Objekt gemeint ist).

Server- und Clientseite sind ja listentechnisch synchron, richtig? Wäre es dann vllt möglich mal testweise über den Index zu arbeiten und diesen removeContent zu übergeben? So kannste feststellen obs wirklich daran liegt oder obs an etwas anderem liegt.

[SGT.Hawk]

Ja, das werde ich auch machen, so dass nur noch ints zum Server geschickt werden, das wird gehen.

[Xmas]

Vielleicht prüft Parent#removeContent(Content) auf Objektidentität?

[SGT.Hawk]

Ja!
Ich habe nochmal nachgesehen im SourceCode vom JDOM.Das stimmt.
equals ist blöderweise nicht überschrieben!!!!!
Somit kann der Vergleich dann, auch in verschiedenen Adressräumen nicht gleich sein und die Listenoperationen von Collections basieren alle auf equals.
@edit:
Super,equals auch noch final deklariert......

[Senior Sanchez]

SGT.Hawk[/POST]']Ja!
Ich habe nochmal nachgesehen im SourceCode vom JDOM.Das stimmt.
equals ist blöderweise nicht überschrieben!!!!!
Somit kann der Vergleich dann, auch in verschiedenen Adressräumen nicht gleich sein und die Listenoperationen von Collections basieren alle auf equals.
@edit:
Super,equals auch noch final deklariert......

Das sowas in der Bibliothek ansich steckt, hätte ich nicht gedacht!
Sieht da jemand von euch nen Sinn dahinter?

Also ich nicht so wirklich.

[SGT.Hawk]

Habe die Lösung mit dem Index umgesetzt, klappt natürlich:).
Dass equals nicht überschrieben sit, leuchtet mir ein, denn wie will man ein einen XML sinnvoll vergleichen, dass ist ja komplett von der DTD/Struktur abhängig, ob siw wirklich gleich sind.Dass aber equals final ist und damit Subclassing sinnlos ist, leuchtet mir nicht ein, vorallem, wenn man wie JDOM extra betont, wie leicht doch das navigieren wird, WEIL man Collections einsetzt:crazy2:
@edit:Noch eine Frage:Habe mir theoretisch überlegt, dass eine List mit den Indices keine so gute Idee ist, denn der Cleint könnte falsche Indices schicken, wenn schon konnkurrent auf den Server von einem anderen Client die XML modifiziert wurde.Dann stimmen natürlich die Indices vom Client nicht mehr.ICh hatte eine Idee, so ähnlich wie equlas, was wenn man einen hashcode für die jeweilige Strings machen würde, um Vergleiche anzustellen?

[SGT.Hawk]

Na?