Webserver mit JavaScript

[edit SlaterB: abgespalten, Zitat hinzugefügt]

[QUOTE=Marco13]Hab’ gerade ganz motiviert, ach was, mindestens motifünft, vielleicht sogar motisechst, angefangen was mit JavaScript machen zu wollen.
Joa, erstmal diese Datei hier einlesen.
Hm.
Moment.
Webserver?
XMLHttpWhat?
Wollt ihr mich ver…?
Warum tun die Leute dauernd so, als wäre das eine Programmiersprache!? :confused: :rolleyes:[/QUOTE]

Klingt so, als ob du JS clientseitig verwendest. Ich greife bei sowas lieber auf jQuery zurück:

$.get( "ajax/test.html", function( data ) {
  $( ".result" ).html( data );
});

Auf dem Server (Node.js) ist das Laden von Dateien trivial:

fs.readFile('/etc/passwd', function (err, data) {
  if (err) throw err;
  console.log(data);
});

Tipp: Seit Java 8 gibt es die Möglichkeit mit JavaScript in einer Java Umgebung auszuführen (Nashorn). Hier ist ein nettes Beispiel:
[JAVASCRIPT]
(function() {
var JFrame = Java.type(‘javax.swing.JFrame’);
var JButton = Java.type(‘javax.swing.JButton’);

var BorderLayout   = Java.type('java.awt.BorderLayout');
var ActionListener = Java.type('java.awt.event.ActionListener');

var frame = new JFrame('HelloWorldSwing');

frame.setSize(800, 600);
frame.setLayout(new BorderLayout())
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

var button = new JButton('Click me!');
button.addActionListener(function(e) {
    print("Hello World!");
    javax.swing.JOptionPane.showMessageDialog(frame, "Hello World!");
});

frame.add(button, BorderLayout.CENTER);
frame.setVisible(true);

})();
[/JAVASCRIPT]

Das ging mit älteren Versionen auch schon, allerdings mit einer anderen Engine (Rhino), die ab J2SE 6 mitgeliefert wurde.

… fuer mich ist ES6 noch unverstaendlicher als ES5, vielleicht liegt es ja daran :o)

Hier mein Frust Beitrag:
Letzte Woche hat einer von 40 Entwicklern auf seinem Feature Branch nach Aenderungen einen (4 Monate alten) Test, der ohne Code Aenderungen mal funzt und dann wieder nicht, klar dass dieser Entwickler nix sagt sondern einfach so oft seinen Feature Branch baut bis der mal zufaellig gruen ist um dann seine Arbeit zu teilen.
Diese Woche haben alle 40 Entwickler Feature Branches bei denen dieser Test mal geht und dann mal wieder nicht und daher ist der Build mal gruen und dann wieder mal rot … und das ohne Codeaenderungen

:scheiterhaufen:

Nun, es ist ja nicht so, dass bei der Websuche „read file with JavaScript“ keine Ergebnisse erschienen :wink: Aber die Ansätze und Krämpfe und Verrenkungen, die damit zu tun haben, erscheinen schon etwas absurd. Gut, ich will auch nicht, dass jede x-beliebige Webseite jede x-beliebige Datei meines Rechners lesen kann (und finde ja eigentlich ohnehin, dass Scripting eine Art Hausfriedensbruch ist), aber wenn die „Sandbox“ zur „Wüste“ wird, scheint irgendwo was falsch gelaufen zu sein. Mit einem Promise um einen XMLHttpRequest schien’s dann zu gehen, eigentlich auch recht überschaubar, aber die Odyssee, die davor stand, ist entmutigend…

Zum Thema Java in JavaScript (kannte es bisher nur umgekehrt) : Ich rate mal: Das wird auf einem IE8 nicht so ohne weiteres funktionieren, nehme ich an…

@Marco13 Mein Beispielcode funktioniert auf keinem normalen Browser, weil normale Browser Java nicht in ihre Scripting Engine einbetten. Das was ich als Code gezeigt habe funktioniert nur mit dem jjs Interpreter, welcher in jeder JRE 8 vorhanden ist.

Ähja, die Formulierung/Grammatik von “mit JavaScript in einer Java Umgebung” war nicht ganz klar. Ich dachte, es gibt eine “standardisierte” JavaScript-Engine, die sich an eine JVM anklinkt (das ist Nashorn so gesehen dann wohl, aber der ganze Krempel muss/sollte ja auch mit beliebigen Browsern laufen)

[QUOTE=maki]… fuer mich ist ES6 noch unverstaendlicher als ES5, vielleicht liegt es ja daran :o)

Hier mein Frust Beitrag:
Letzte Woche hat einer von 40 Entwicklern auf seinem Feature Branch nach Aenderungen einen (4 Monate alten) Test, der ohne Code Aenderungen mal funzt und dann wieder nicht, klar dass dieser Entwickler nix sagt sondern einfach so oft seinen Feature Branch baut bis der mal zufaellig gruen ist um dann seine Arbeit zu teilen.
Diese Woche haben alle 40 Entwickler Feature Branches bei denen dieser Test mal geht und dann mal wieder nicht und daher ist der Build mal gruen und dann wieder mal rot … und das ohne Codeaenderungen

:scheiterhaufen:[/QUOTE]
Wackeltests sind die Hölle. Ich freue mich immer über so etwas im Trunk.

Da kann ich auch was Beitrage. Vor einiger Zeit tauchte in einem Spring Batch Test ein Fehler auf weil er ein Bean nicht finden konnte.
Das tolle: Es ist da. Alle anderen Tests haben damit keine Probleme. Es ist immer das selbe Bean. Die Tests dauern >2h
Wenn man nur den fehlerhaften Test ausfürt… alles super.
Dann wurde mal die Reihenfolge der Kontextkonfigurationen geändert: Tests funktionieren… ein paar Tage

@Marco13 Korrekterweise ist JavaScript eine standardisierte Sprache bei der es mehrere Implementierung (Engines) gibt, die mit bestimmten Umgebungen (APIs) verdrahtet werden. Die v8 Engine eine Implementierung der Sprache, die sowohl von Chrome, als auch von NodeJS verwendet wird. Trotzdem haben beide Anwendungen unterschiedlich spezialisierte APIs. Chrome verwendet die standardisierten WebAPIs, die nur einen beschränkten Zugriff auf die Netzwerkfunktionalität des Benutzers ermöglich, damit der Nutzer eine bessere Sicherheit genießt. NodeJS dagegen hat im Vergleich eine mächtige API für den Zugriff auf Netzwerkfunktionalität, um vollständige Serveranwendungen erst zu ermöglichen. D.h. Anwendungen, die auf Chrome funktionieren, werden aufgrund unterschiedlich spezialisierter APIs nicht auf NodeJS funktionieren und umgekehrt, obwohl beide mit derselben JavaScript-Engine laufen.

Mit könnte mit einer anderen Engine man einen ähnlichen Vergleich machen, spar’ ich mir aber da ich mein jetziger anschaulicher ist. Hint Firefox (mit Web API) und Gjs (mit GTK+ API) verwenden beide die Spidermonkey Egine.

Ich finde die Kombination aus WebLogic und Spring gerade zum erschießen…
Es ist ja schön dass ich eine Datenquelle außerhalb deer Applikation angeben kann. Es ist auch schön, dass alles richtig injiziert wird und geladen werden kann.
Was weniger schön ist, ist die Tatsache dass es 4 potentielle Dateien für die Properties gibt und KEINE davon die Datenbank angibt, die wirklich benutzt wird.
Damit das ganze noch schöner wird ist auch auf dem WebLogic keine einzige Datenquelle angegeben die benutzt werden würde…

Um das ganze nochmal zusammenzufassen: Wir kennen den Server, wir kennen die Datenbank, wir haben auf beides Zugriff… wir finden/verstehen nur nicht woher die Anwendung auf dem Server die Datenbank kennt

Spring + WebLogic: Das Vergnügen hat ich einmal, Danke aber Nein Danke :smiley:
wenn ich mich recht erinnere, wird die DS komplett von WL gehändelt

wir hatten da so lustige Effekte dass der Timeout einer Connection in WL kürzer eingestellt War als in Spring, mit dem Ergebniss das von Spring noch referenzierte Connections von WL bereits geschlossen waren, tolle StackTraces…