Benutzung von com.sun.net.httpserver.HttpServer

Status
Nicht offen für weitere Antworten.
J

JFreak

Bekanntes Mitglied
Hallo,

für ein Projekt würde ich gerne einen kleinen Webserver in das Programm integrieren. Nun war ich schon drauf und dran, das alles selber zu schreiben, bis ich hier auf diese HttpServer-Klasse stieß.

Der Autor hat gesagt.:
die Klassen sind zwar mehr oder weniger privat im Paket com.sun.net.httpserver deklariert, dennoch wollen wir ein Beispiel wagen.
Zum Vergrößern anklicken....

Was kann ich darunter verstehen? Ist es etwa "evil" diese Klassen zu benutzen? Oder kann ich einfach drauflos damit umgehen?

Kurz noch, was das ganze soll: Ich möchte eine Client-Server-Anwendung machen, die auch eine Anbindung per Web haben soll. Da ich Apache/Tomcat nicht zwangsläufig voraussetzen kann, eine JRE allerdings schon, wäre es clever, alles in eine Server-Applikation einzubauen. Dann müsste man auch Plugins für den Server nicht zweimal schreiben (einmal für die "Java-Clients" und einmal für die "Web-Clients"). Hoffe, das ist verständlich ;)

Gruß Lars
 
H

HoaX

Top Contributor
du solltest die finger davon lassen. wenn der anwender z.B. nicht die jre von sun sondern von ibm verwendet gibt es die klasse nicht. oder sun ändert innerhalb der javaversionen die api.

liefer doch einfach den tomcat mit? der is doch net so groß. ist einfacher als den anwender an eine bestimmte jre-version zu binden
 
J

JFreak

Bekanntes Mitglied
Hallo,

die Einwände sind durchaus berechtigt. Es geht nur darum, dass ich auf den Zielsystemen nicht unbedingt was installieren kann/darf. -> Tomcat mitliefern ist wenig elegant. Sind diese Pakete nicht in irgendwelchen JARs drin, die ich zur Sicherheit mitliefern könnte?

Eine zweite Sache noch: Spräche etwas dagegen, den Server von Hand zu schreiben oder ist die Umsetzung des RFCs zu hart?

Gruß Lars
 
H

HoaX

Top Contributor
sag tomcat gehört dazu, deine anwendung darfst/kannst du doch installieren?!
tomcat ist auch nur java - ob die klassen nun in pakete aufgeteilt sind und/oder in jar-dateien gepackt sind spielt überhaupt keine rolle.

wenn du dir zutraust das zu machen kannst dus tun. aber es gibt massig fertige server die du runterladen kannst ...

was ich wohl in naher zukunft auf arbeit einbetten darf ist jetty - aber evtl für dich überdimensioniert
 
M

Murray

Top Contributor
Diese Klassen sind - im Gegensatz zu dem meisten anderen Klassen mit com.sun.*-Package - im Rahmen der API-Dokumentation beschrieben und von Sun daher durchaus zur Verwendung durch irgendwelche Anwendungen vorgesehen; insofern würde ich nicht damit rechnen, dass hier bei Updates stillschweigend API-Änderungen passieren werden.
Es stimmt natürlich, dass man mit der Verwendung dieser Klassen auf jeden Fall Java6 in der Implementierung von Sun braucht; alte JDKs/JREs oder solche anderer Anbieter bleiben außen vor.

Wenn man nur einen HTTP-Server, aber keine Servlet-Engine braucht, ist Tomcat wohl Overkill; in diesem Fall wäre dann wohl Jetty die bessere Wahl (oder LWS oder winstone oder ....).

Selber schreiben geht natürlich auch; wenn du nur eine kleines Web-Interface zur Fernwartung deiner Anwendung brauchst, dann könnte das vielleicht sinnvoll sein. Es besteht allerdings die Gefahr, dass man mit der Zeit Feature um Feature nachrüstet und dann doch irgendwann bei einem ähnlichen Umfang wie bei den fertigen Lösungen zu stehen.
 
J

JFreak

Bekanntes Mitglied
Hallo,

also erstmal danke für die vielen genannten Ideen. Ich glaube mit Tomcat habe ich gehörig etwas durcheinandergebracht, wohl der Tatsache geschuldet, dass ich von Web Services etc. keine Ahnung habe.

Was ich brauche, ist lediglich ein ganz kleiner Webserver, um mir die Programmierarbeit zu ersparen. Da brauch kein PHP dabei zu sein, auch kein JSP oder sonst etwas, die einzigen dynamischen Inhalte in den Webseiten würde ich gerne selber implementieren.

Eine Beispielseite sähe also so aus:
Code: 
<html>

<?script
  deliver Chat.log as xhtml
?>

Der verwendete Server sollte also die Antwort an den Client mir überlassen, wie es auch beim com.sun....-HttpServer der Fall ist. Das brauche ich, da die zu liefernden Webseiten entweder direkt auf der Festplatte, im Heap oder sich in einem virtuellen FS befinden.

Ich hoffe, so etwas funktioniert und es gibt "lightweight"-Frameworks dafür. Ich sehe da grade auf der Jetty-Homepage nicht so ganz durch.

Gruß Lars
 
H

HoaX

Top Contributor
mit jetty ebenso einfach: http://docs.codehaus.org/display/JETTY/Embedding+Jetty

aber wenn du eh kaum funktion brauchst ist vielleicht das ehr das richtige für dich:
http://elonen.iki.fi/code/nanohttpd/

murray hat gesagt.:
im Rahmen der API-Dokumentation beschrieben und von Sun daher durchaus zur Verwendung durch irgendwelche Anwendungen vorgesehen;
Zum Vergrößern anklicken....
verdammt, ich sollte schnell aus allen meinen packages die dokumentation entfernen - weil sonst darf/kann ich die ja nixmehr ändern. nene du!

dennoch - nachgelesen - sun.* steht in der faq darf/soll man nicht verwenden. com.sun.* ist nirgends erwähnt, jedoch auch definitiv nicht standardbestandteil der jre, solang du java 6 von sun benutzt wirds wohl gehn, sonst nicht. --> nimm lieber irgendeinen der genannten server und erspare dir weiter kopfzerbrechen und späteren ärger ;)
 
J

JFreak

Bekanntes Mitglied
Hallo,

danke @ HoaX - NanoHTTPD ist genau das, was ich suchte! Schnell, einfach und klein. Da werd ich mir doch direkt mal eine Subklasse davon ableiten.

Eine Frage noch bezüglich der Lizenz. Das Ganze ist unter einer modifizierten BSD-Lizenz veröffentlicht. Wenn ich den Text richtig verstehe, bin ich nur dazu verpflichtet, den Teil als BSD-lizenziert zu kennzeichnen, aber nicht, meine komplette Arbeit unter BSD-Lizenz zu stellen, oder? Gedacht hatte ich nämlich an die GPL. (edit: Sorry, kleiner Fehler, ich meinte natürlich die GPL und nicht die CC)

Gruß Lars
 
M

Murray

Top Contributor
HoaX hat gesagt.:
murray hat gesagt.:
im Rahmen der API-Dokumentation beschrieben und von Sun daher durchaus zur Verwendung durch irgendwelche Anwendungen vorgesehen;
Zum Vergrößern anklicken....
verdammt, ich sollte schnell aus allen meinen packages die dokumentation entfernen - weil sonst darf/kann ich die ja nixmehr ändern. nene du!
Zum Vergrößern anklicken....

Wie du das handhabst, ist dein natürlich dein Bier - normalerweise kann man aber davon ausgehen, dass die dokumentierten APIs einer Library nicht stillschweigend geändert oder sogar ganz entfernt werden. Natürlich sind Änderungen möglich, aber die sollten dann als solche (z.B. in den Release Notes) explizit dokumentiert sein.

In den Release-Notes zu Java SE 6 wird unter Networking-Features explizit auf diesen Lightweight-HTTP-Server verwiesen - insofern werde ich weiterhin davon ausgehen, dass dieses Feature auch in Zukunft erhalten bleibt.

Trotzdem stimmt es natürlich, dass diese Packages außerhalb des Standards liegen und daher von anderen Anbietern so nicht verfügbar sein werden; ich hoffe, dass Sun das jetzt nicht bei allen Weiterentwicklungen so macht und damit den Schritt zum Open-Source-Java teilweise Makulatur werden lässt - so nach dem Motto: das Kernsystem ist zwar standartisiert und open-source, es werden aber jede Menge non-standard, closed-source Packages untrennbar mitgeliefert, mit deren Nutzung man doch wieder von einem bestimmten Hersteller abhängig wird.
 
H

HoaX

Top Contributor
ich sehe da keine gefahr, da es eben eine jre-spezifische erweiterung ist und daher jeder ernsthafte programmierer das ding nicht verwendet um mit anderen jvms kompatibel zu sein. ich seh das als nette beigabe für basteleien ... aber nicht für ernsthaften einsatz
 
Status
Nicht offen für weitere Antworten.
Ähnliche Java Themen
  Titel Forum Antworten Datum
J HTTP Bild an Client schicken mit com.sun.net.httpserver Netzwerkprogrammierung 5

Ähnliche Java Themen

Aktuelle Jobs

Neue Themen


Oben