# Web-Anwendung funktioniert mit Java 1.8, aber nicht mit Java 1.7 (auf Client)



## Bastmeister (23. Apr 2015)

Hallo,

ich bin am Verzweifeln. Bei uns im Unternehmen gibt es eine interne Web-Anwendung (nicht von uns geschrieben), die auf einem Web-Server (Windows 2003) läuft und sich ohne Probleme nutzen lässt. Die Anwendung soll auf einen neueren Server (Windows Server 2008) umziehen und gleichzeitig soll die neuste Version der Web-Anwendung verwendet werden. Auf dem neuen Server ist alles korrekt eingerichtet (Tomcat, Java usw.). Unter dieser Anwendung hängt eine MySQL-Datenbank, die wiederum auf einem Datenbankserver liegt. Die zugelassenen Nutzer dieser Anwendung sind in der Datenbank gespeichert. 
Die Personen, die diese Anwendung geschrieben haben, sind bisher selbst ratlos...

*1.)* Die Situation beim Versuch die neue Version auf dem neuen Server zu nutzen (die alte Version und sämtliche Anbindungen sind dabei natürlich deaktiviert): Jeder Client, auf dem Java 1.8 installiert ist, kann die Anwendung nutzen, d.h. ihnen werden die Daten aus der Datenbank angezeigt und sie bzw. deren Nutzerkennungen werden von der Anwendung korrekt erkannt. Das Problem: Jeder Client, auf dem Java 1.7 installiert ist, kommt zwar auf die GUI der Anwendung, hat aber keinen Zugriff auf die Daten. Die Daten werden nicht angezeigt, sondern nur die Meldung, dass er/sie keine Berechtigung hat. Die Java-Konsole erkennt die jeweilige Unternehmens-Kennung bei Aufruf der Web-Anwendung im Browser, aber die Anwendung selbst erkennt den Nutzer nicht mehr. D.h., der Zugriff auf die Datenbank scheint nicht zu funktionieren von allen Clients mit Java 1.7 aus. Wenn ich über localhost auf dem Web-Server die Anwendung mit einem Broswer aufrufe, habe ich genau das gleiche Problem: Nutze ich auf dem Server Java 1.8 funktioniert alles, nutze ich Java 1.7, nicht bzw. erscheinen keine Daten.
In Partnerunternehmen, die die gleiche Anwendung nutzen, gibt es keinerlei Probleme. Sie haben alle einen eigenständigen Web- und Datenbank-Server für diese Anwendung. 
Nebenbei: Die DNS ist in der jeweiligen Sitelist eingetragen und Java 1.7 für die Anwendung in der Whitelist des Unternehmensnetzwerks.

Hat vielleicht irgend jemand eine Idee?? Könnte es sein, dass die Datenbank etwas an Java 1.7 nicht mag?

Hier mal der Text, den die Java Konsole ausgibt, wenn man die Seite der Anwendung aufruft (egal, ob Firefox oder IE):

```
Java-Plug-in 10.79.2.15
JRE-Version verwenden 1.7.0_79-b15 Java HotSpot(TM) Client VM
Benutzer-Home-Verzeichnis = C:\Users\gmbh-abcd
----------------------------------------------------
c:   Konsolenfenster löschen
f:   Objekte in Finalisierungs-Queue finalisieren
g:   Garbage Collect
h:   Diese Hilfemeldung anzeigen
l:   Class Loader-Liste ausgeben
m:   Speicherauslastung drucken
o:   Logging auslösen
q:   Konsole ausblenden
r:   Policy-Konfiguration neu laden
s:   System- und Deployment-Eigenschaften ausgeben
t:   Threadliste ausgeben
v:   Threadstack ausgeben
x:   Class Loader-Cache leeren
0-5: Traceebene auf <n> setzen
----------------------------------------------------
user.name=gmbh-abcd
NTSystem: gmbh-abcd
Traceebene auf 5 (alle) setzen ... abgeschlossen.basic: Applet initialisiert
basic: Applet wird gestartet
basic: Leistungs-Rollup abgeschlossen
preloader: Delivering: AppletInitEvent[type=CallStart]
preloader: Enqueue: com.sun.javaws.progress.PreloaderDelegate$4@164b39d
preloader: Start progressCheck thread
basic: Applet sichtbar gemacht
basic: Applet gestartet
basic: Clients über Start des Applets benachrichtigt
basic: Applet-Teardown wird gestartet
preloader: Delivering: ApplicationExitEvent
preloader: Enqueue: com.sun.javaws.progress.PreloaderDelegate$4@ac1f75
basic: Applet-Teardown beendet
basic: Fortschritts-Listener entfernt: sun.plugin.util.ProgressMonitorAdapter@4561a6
basic: PluginMain.unregisterApplet: 29 from mananger sun.plugin2.applet.Applet2Manager@10df626
preloader: Stop progressCheck thread queue.size()=0
ui: plugin2manager.parentwindowDispose
```


*2.)* Wenn ich auf dem neuen Server, die gleichen alten (derzeit laufenden) Versionen der Anwendung und des Tomcat usw. einrichte, erscheint (unter Nutzung von Java 1.7 auf dem Client) die GUI, aber es erscheint lediglich "Identifikation..." und das war's. Für diesen Fall hier der Text der Java Konsole:


```
Java-Plug-in 10.79.2.15
JRE-Version verwenden 1.7.0_79-b15 Java HotSpot(TM) Client VM
Benutzer-Home-Verzeichnis = C:\Users\gmbh-abcd
----------------------------------------------------
c:   Konsolenfenster löschen
f:   Objekte in Finalisierungs-Queue finalisieren
g:   Garbage Collect
h:   Diese Hilfemeldung anzeigen
l:   Class Loader-Liste ausgeben
m:   Speicherauslastung drucken
o:   Logging auslösen
q:   Konsole ausblenden
r:   Policy-Konfiguration neu laden
s:   System- und Deployment-Eigenschaften ausgeben
t:   Threadliste ausgeben
v:   Threadstack ausgeben
x:   Class Loader-Cache leeren
0-5: Traceebene auf <n> setzen
----------------------------------------------------
user.name=gmbh-abcd
NTSystem: gmbh-abcd
java.io.IOException: Server returned HTTP response code: 405 for URL: [URL]https://adresse-die-zum-server-führt/ANWENDUNG/identifikation[/URL]
    at sun.net.[URL="http://www.protocol.http.HttpURLConnection.getInputStream(Unknown"]www.protocol.http.HttpURLConnection.getInputStream(Unknown[/URL] Source)
    at sun.net.[URL="http://www.protocol.https.HttpsURLConnectionImpl.getInputStream(Unknown"]www.protocol.https.HttpsURLConnectionImpl.getInputStream(Unknown[/URL] Source)
    at unterordner.client.Identifikation.init(Identifikation.java:51)
    at com.sun.deploy.uitoolkit.impl.awt.AWTAppletAdapter.init(Unknown Source)
    at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)
Traceebene auf 5 (alle) setzen ... abgeschlossen.preloader: Stop progressCheck thread queue.size()=0
```

Weiß jemand einen konstruktiven Rat? 

Vielen Dank im Voraus!

MFG

P.S. Die Kennungen und Namen des Programms habe ich geändert


----------



## Diabolus (23. Apr 2015)

Hallo,  Ich weiß ja nicht ob ihr schon nachgeschaut habt, aber der server meldet den fehlercode 405, was bedeutet dass eine ungültige HTTP-Methode zur Anfrage verwendet wurde (also z.B.: POST statt GET).Außerdem sagt das Programm ja, dass der Fehler in der Datei Identifikation.java in der Zeile 51 aufgetreten ist. Wenn Ihr das noch nicht gemacht habt (wovon ich mal nicht ausgeht  ), dann würde ich mal nachschauen, was in der Zeile denn genau gemacht wird!   mfgDiabolus


----------



## Bastmeister (23. Apr 2015)

Hi,

vielen Dank erst mal für die Antwort. Ja, das hab ich auch schon irgendwo gelesen, aber ich dachte mir, dass das nicht sein kann, weil am Programm usw. ja nichts verändert wurde und in den anderen Firmen ja auch funktioniert. Jetzt ist mir aber ein Gedanke gekommen: Könnte es sein, dass der neue Server individuell so eingestellt ist, dass er die Methode nicht mag, also nicht bewußt, sondern einfach als Neuerung oder so? Kann man das irgendwo auf dem Server einstellen bzw. von der Abteilung, die den Server bereit gestellt hat, einstellen lassen? Oder sollte man versuchen die Methode in der Identifikation.class zu ändern?
Ich konnte die Identifikation.class nicht öffnen (also nicht mit Eclipse oder so). Ich habe die Datei von einem Programm namens "dirtyJOE" einlesen lassen und da steht in Zeile 51: "utf8 : pathtrace" (oder so ähnlich. utf8 steht sicher da, bei dem nach dem Doppelpunkt nicht ganz. Bin zu Hause und nicht im Büro). Könnte es sein, dass die Datenbank nicht im utf8-Code, sondern in einem anderen "konfiguriert" ist und Java7 das nicht mag??

MFG


----------



## Diabolus (23. Apr 2015)

Hi,
Nutzen die anderen Firmen denn auch Java 7 oder Java 8  auf Ihren Clients ?
Eine Möglichkeit das Problem zu lösen wäre natürlich auf allen Clients Java 8 zu installieren...
mfg


----------



## Bastmeister (24. Apr 2015)

Hallo,

jawohl. Die nutzen seit geraumer Zeit Java 7 und steigen demnächst auf Java 8 um. Manche benutzen aber schon Java 8 zum Testen).
Ja, das war auch mein erster Vorschlag, aber leider dauert es noch etwas bis bei uns auf Java 8 umgestiegen werden kann,
weil mit Java 8 wiederum andere Programme in Mitleidenschaft gezogen werden... Es ist ein Teufelskreis und ich
habe die A****-Karte gezogen und muss mich mit der Problematik befassen, weil das Problem schon sehr mysteriös ist.

mfg


----------



## Bastmeister (24. Apr 2015)

Hab jetzt weiter herumgeforscht und bin immer mehr davon überzeugt, dass es etwas mit der Datenbank zu tun hat. Ich werde hierzu ein neues Thema erstellen


----------

