Rechte bei JAVA-Anwendung?

urian

Mitglied
- Vorneweg: Ein besserer Titel ist mir leider nicht eingefallen. -

Hallo an alle,

zurzeit arbeite ich an einen Kalkulator.

Die zu bearbeitende, vollständige und vor allem funktionsfähige war-Datei hab ich, deployed usw., alles kein Problem.

Aufgerufen wird dieser Kalkulator auch, nur bei dem Script, dass diese Berechnung durchführt (greift auf einen externen Webservice zu), hängts. Wie erwähnt: Der Rechner + Tomcat-Umgebung an sich funktioniert und wird auch aufgerufen, bis genannte externe Rechnung stattfindet, deshalb gehe ich davon aus, dass irgendwas mit meinen Zugriffsrechten nicht stimmt, in dem Fall die eingegebenen Daten nicht "raus" können. Ich muss hier Windows 7 verwenden, sei gesagt. Meine Frage ist: Gibt es gleich bei Windows 7 irgendwas gravierendes zu ändern, oder gibt es sogar in der Tomcat-Umgebung irgendetwas, was ich an Rechten machen könnte?

Vielen Dank im Vorraus.
 
Es gibt viele mögliche Ursachen, warum ein Webserviceaufruf schief gegangen sein könnte. In absteigender Wahrscheinlichkeit kämen z.B. folgende in Frage:
- Du hast eine Fehler beim Aufruf gemacht (richtiger Host?, richtige URL? richtiger Content?)
- Der Webservcie läuft garnicht
- Irgend ne Firewall lässt Dich nicht durch
- Dein Tomcat läuft mit aktiviertem SecurityManager (der ist default mäßig aus)
Eine genaue Auskunft gibt die Exception inkl. StackTrace. Poste die bitte.
 
"- Du hast eine Fehler beim Aufruf gemacht (richtiger Host?, richtige URL? richtiger Content?)"
>> Jeder Pfad dürfte stimmen, alles richtig benannnt bzw. aufgerufen.

"- Der Webservcie läuft garnicht"
>> Der läuft funktionsfähig. Das muss und kann ich garantieren.

"- Irgend ne Firewall lässt Dich nicht durch"
>> Nach Deaktivieren funktioniert es leider immer noch nicht. 🙁

"- Dein Tomcat läuft mit aktiviertem SecurityManager (der ist default mäßig aus)"
>> An den Standardeinstellungen hab ich nichts verändert. Demnach wäre er ja prinzipiell aus. Wenn nicht, wie kann ich den aufrufen bzw. Einstellungen vornehmen?


Zu sagen wäre vielleicht noch, dass die Fehlermeldung eine allgemeine ist.
D.h. wenn der Webservice nicht aufgerufen werden kann, ein Pfad falsch beschrieben wurde etc. kommt immer die gleiche Meldung. Simple if-true-false-Schleife.
 
Zu sagen wäre vielleicht noch, dass die Fehlermeldung eine allgemeine ist.
D.h. wenn der Webservice nicht aufgerufen werden kann, ein Pfad falsch beschrieben wurde etc. kommt immer die gleiche Meldung. Simple if-true-false-Schleife.

Das solltest du dann auf jeden Fall ändern! So macht die Fehlermeldung ja dann genausoviel Sinn wie: Es funktioniert nicht. Und das ist bekannterweise keine Fehlerbeschriebung!
 
Wenn nicht, wie kann ich den aufrufen bzw. Einstellungen vornehmen?
Der SecurityManager ist ein Feature der JVM. Bei den Tomcat startet man ihn mit, wenn man den Tomcat-Startscripten den Kommandozeilenparameter "-security" mitgibt. Mit einem "ps -ef" unter Linux kann man sich die laufenden Prozesse inkl. der Kommandos zu ihrem Start anschauen. Da würde man das sehen. Bei Windows? Keine Ahnung.
D.h. wenn der Webservice nicht aufgerufen werden kann, ein Pfad falsch beschrieben wurde etc. kommt immer die gleiche Meldung. Simple if-true-false-Schleife.
Man will nett sein und den Aufrufer von dem handeln irgendwelcher Exceptions verschonen. Das kann man machen. Aber intern sollte man die Exceptions dann wenigstens loggen. Sie einfach zu verschlucken und ein false zurück geben heißt, die Standardmöglichkeit, bei Java-Applikationen Fehler zu finden, effektiv abzuschalten.
 
Zu meiner Verteidigung: Ich hab diesen Kalkulator nicht programmiert.

Die Fehlermeldung ist wie gesagt wirklich nur:

Formular
-> Wenn Daten ankommen = true >> Weiterleitung
-> Wenn Daten nicht ankommen, warum auch immer = false >> Fehlermeldung

Ziemlich naiv, das weiß ich auch. ; )

Mittlerweile hat es sich geklärt: Der Hoster, auf den es zugreift, hat mir keine Rechte gegeben. Aber Menschen suchen ihre Fehler immer erst bei anderen. Deswegen saß ich auch seit Tagen da und kam nicht weiter. :toll:

Der Trottel, der mir versicherte, dass er ja nicht dran schuld sei und bei ihm die ganze Zeit der Fehler lag, wird sich jetz ein zweites Loch in den Hintern lachen.

Sei's drum, Vielen Dank für alles!
 

Zurück
Oben