Uups, vielleicht sollte ich nächstes mal doch a bissel mehr als die Überschrift des Threads lesen
Von JSP zu JSP kann man wie Titus sagte die URL-Parameter nutzen.
Oder man kann, ist vom Fall abhängig, die Variabel auch Sessionweit verfügbar machen in dem man das Objekt in die Session gelegt wird.
session.setAttribute("variablenNamen",wert);
Üblich ist ein Aufruf von JSP zu JSP eher nicht, da die meisten Web-Anwendungen ein MVC-Framework wie Struts http://jakarta.apache.org/struts/index.html
oder ein selbstgestricktes nutzen, wobei alle Aufruf über ein zentralen Controller(Servlet) bzw den jeweiligen Handlern gehen (auch wenn man von einer JSP auf 'ne andere kommen will).
bis dänn, O'Dog
Hallo!
Ich möchte mich beim Cengiz persönlich bedanken. Einfach toll dass
du dir die Zeit genommen hast um mir die Frage so deutlich und klar
zu erklären.
Vielen Dank
Grüße
Stimmt, war immer gleich.
mmh, vielleicht vermenge ich da gerade c/c++ und java.
Ich werde das nochmal nachlesen. Die Idee ist jedenfalls, das ein 32bit Prozessor intern mit 32bit Registern arbeitet. Die Grenzen sind da also ganz natürlich aus dem Aufbau der Register gegeben. Wenn man nun ein Byte (mit 8 bit) hat, müssten die Grenzen künstlich überwacht werden. -> und das würde dann zu einem geschwindigkeitsverlust führen.
Der Unterschied sollte natürlich nicht besonders hoch sein. Mir ist das nur mal irgendwo hängengeblieben, weil ich früher relativ oft byte anstelle von int verwendet habe... und danach nicht mehr.
hatte es nur auf einem...
und habe mich an den obigen link gehalten..
da steht auch was zum export von einem key:
Soll das signierte Applet auf anderen Arbeitsplätzen laufen, ist es erforderlich, das Zertifikat des Schlüssels, mit dem es signiert wurde, dort zu installieren. Soll es dagegen nur auf dem Arbeitsplatz laufen, auf dem auch der Schlüssel generiert wurde, ist das nicht erforderlich. Bei der Generierung des Schlüssels wurde ja auch ein (selbstsigniertes) Zertifikat erzeugt.
Um das Zertifikat weitergeben zu können, muß es zunächst unter Verwendung der Option -export von keytool aus der lokalen Schlüsseldatenbank exportiert werden:
keytool -export -alias gj22 -file gj22.cert
Es liegt nun in der Datei gj22.cert und kann auf das Zielsystem kopiert werden. Mit der -import-Option von keytool kann es dort in die Schlüsseldatenbank aufgenommen werden:
C:\--->keytool -import -alias gj22 -file gj22.cert
Enter keystore password: gj22ks
Owner: CN=Guido Krueger, O=Computer Books, C=de
Issuer: CN=Guido Krueger, O=Computer Books, C=de
Serial number: 38663e2d
Valid from: Sun Dec 26 17:11:25 GMT+01:00 1999 until: Sat Mar 25 17:11:25 GMT+01
:00 2000
Certificate fingerprints:
MD5: D5:73:AB:06:25:16:7F:36:27:DF:CF:9D:C9:DE:AD:35
SHA1: E0:A4:39:65:60:06:48:61:82:5E:8C:47:8A:2B:04:A4:6D:43:56:05
Trust this certificate? [no]: y
Certificate was added to keystore
Nach dem Aufruf muß zunächst das Paßwort der Schlüsseldatenbank angegeben werden. Dann zeigt das Programm die Eigenschaften des Zertifikats an und erwartet, daß die Informationen bestätigt werden. Anschließend wird das Zertifikat in die Schlüsseldatenbank aufgenommen.
es war wirklich ein erlebnis
trotzdem: ich verstehe nicht, wenn du das applet auf dem server hast und es sozusagen dann localhost mit deiner anwendung korrespondiert, das es dann überhaupt probleme gibt mit zugriff von deinem und anderen rechnern.. (bzw. plötzlich von deinem nicht mehr)
ich wollte vom applet auf eine access datenbank zugreifen, bzw. in ein file schreiben. das ist was anderes.. da greift das applet dann direkt auf die festplatte zu.. das ist nicht erlaubt und muss extra gehändelt werden..
vielleicht ist die fährte doch falsch ? we see
Auf Wunsch wird hier noch einmal ausführlicher auf JAR-Files eingegangen.
Was ist JAR
Jar steht für Java ARchive. Basierend auf dem berühmten ZIP-Dateiformat werden Java Archive zur Zusammenfassung von vielen Dateien in eine Datei genutzt. Die Motivation für die Entwicklung eines solchen Tools liegt in dem Wunsch vieler Entwickler statt mehrerer Klassen und Bildern nur eine Datei über einen HTTP-Request runterladen zu müssen. Dies hat natürlich auch Geschwindigkeitsvorteile beim Laden von Java-Applets. Auch das JAR-Format unterstützt Kompression wodurch die Downloadzeit noch einmal verkürzt wird. Zusätlich dazu können bestimmte Inhalte eines Java-Archivs auch mit einer digitalen Signatur versehen werden um die Originalität zu gewährleisten.
Ausführbare JAR-Dateien
Bei Win32-Systemen registriert das Installationsprogramm der Java 2 Runtime Environment JAR-Dateien mit der JVM, so dass diese über einen Doppelklick auf ein .jar-Archiv automatisch per javaw -jar aufgerufen wird.
Auf Solaris-Systemen ab Version 2.6 ist der Kernel bereits so erweitert worden, dass er über die "magic-number" (0x504B0304) JAR-Dateien erkennt und diese per java -jar aufruft als ob es ein Solaris-Executable wäre. So kann eine Applikation innerhalb eines JAR-Archivs direkt per Kommandozeile bzw. Klick auf ein Icon im CDE-Desktop ausgeführt werden.
Allgemeine Kommandozeile mit Erklärungen
Usage: jar {ctxu}[vfm0M] [jar-file] [manifest-file] [-C dir] files ...
Options:
-c create new archive
-t list table of contents for archive
-x extract named (or all) files from archive
-u update existing archive
-v generate verbose output on standard output
-f specify archive file name
-m include manifest information from specified manifest file
-0 store only; use no ZIP compression
-M Do not create a manifest file for the entries
-C change to the specified directory and include the following file
If any file is a directory then it is processed recursively.
The manifest file name and the archive file name needs to be specified
in the same order the 'm' and 'f' flags are specified.
Example 1: to archive two class files into an archive called classes.jar:
jar cvf classes.jar Foo.class Bar.class
Example 2: use an existing manifest file 'mymanifest' and archive all the
files in the foo/ directory into 'classes.jar':
jar cvfm classes.jar mymanifest -C foo/ .
Vorbedingungen um ein JAR-File per doppelklick starten zu können
Um ein .jar-File per Doppelklick zum starten zu bewegen muss in dem .jar-File eine sogenannte Manifest-Datei eingebettet sein. Ihr Aufbau kann unter Understanding the Manifest nachgelesen werden.
Um ein .jar-Archiv nun ausführbar zu machen muss in diese Manifest-Datei folgender Eintrag vorgenommen werden.
Main-Class: classname
Also zum Beispiel:
Manifest-Version: 1.0
Main-Class: Start
Nicht zu vergessen ist das Verzeichnis, in das die Manifest-Datei plaziert werden muss: META-INF/MANIFEST.MF
Nützliche Links zum Thema JAR-Files:
http://www.mathematik.uni-trier.de/~huebner/tipps.html
http://www.experts-exchange.com/Programming/Programming_Languages/Java/Q_20366374.html
http://java.sun.com/docs/books/tutorial/jar/
[ Dieser Beitrag wurde am 29.01.2003 um 17:58 Uhr von CengizS editiert. ]
Original erstellt von CengizS:
**versuchs mal mit diesem super-kommentierten Code
**
Hi, ich bin tendenziell gegen übertriebenes Kommentieren im Code.
Nur bei Hacks oder undurchsichtigen Codestellen. Von daher passt das schon
Der Code funktioniert das liegt wohl an "fireEditingStopped" den du bei Action-Events von Buttons aufrufst. Wenn du das rausläßt hast du das Verhalten wie oben von mir beschrieben (teilweise nicht eingedrückte Buttons), anscheinend werden Button-Events der UI vom Table manchmal unterdrückt.
Original erstellt von CengizS:
Hope that helps!
Jap
bis dänn, O'Dog
Schöne Lösung. Dass man die Applikation per System.exit(...); verlassen muss ist meiner Meinung nach kein Nachteil
Für die FAQ warte ich noch - vielleicht kommen ja noch weitere Ideen etc.
Ich stelle hier mal - auf Wunsch - eine Liste aller innerhalb des Forums genannten IDEs zur Verfügung.
NetBeans ( http://www.netbeans.org )
eclipse: http://www.eclipse.org/
JBuilder: http://www.borland.com/jbuilder (ist in der Foundation Version kostenlos)
JDeveloper: http://otn.oracle.com/software/products/jdev/index.html
jdee: http://jdee.sunsite.dk/ (Aufsatz für Emacs)
IntelliJ IDEA: http://www.intellij.com/idea/
Falls ein Produkt fehlt bitte eine kleine Notiz an mich
Also doch noch mal ein Beispiel:
[java]public class MySuperToolsClass {
...
public int renderSomething(Object o) throws NullPointerException, ProgrammingException {
if(!(o instanceOf Shape)) {
throw new ProgrammingException("Parameter o must be an instance of de.sahinc.gui.Shape!");
}
...
o.renderYourself(); // <-- hier geschieht NullPointerException
}
...
}[/code]Der Aufruf von
[java]MySuperToolsClass mstc = MySuperToolsClass.getInstance();
mstc.renderSomething(new Shape());[/code]würde einen Compilerfehler verursachen. Er beschwert sich nämlich dass die Exceptions in der throws-Liste der Routine renderSomething nicht abgefangen werden ... an diesem Punkt gibt es 2 Möglichkeiten ... entweder man folgt dem Compiler und macht ein try-catch-Block um den Aufruf von renderSomething:
[java]MySuperToolsClass mstc = MySuperToolsClass.getInstance();
try {
mstc.renderSomething(new Shape());
} catch (NullPointerException npex) {
npex.printStackTrace();
} catch (ProgrammingException pex) {
pex.printStackTrace(); // ... oder irgendeine andere Fehlerbehandlung
}[/code]
oder
man definiert für die Routine, die renderSomething() aufruft ebenfalls eine throw-Liste und sorgt so dafür, dass sie wieder eine Instanz nach oben propagiert wird:
[java]public class RenderEngine {
...
public void renderNow() throws NullPointerException, ProgrammingException {
// hier der Aufruf von renderSomething()
MySuperToolsClass mstc = MySuperToolsClass.getInstance();
mstc.renderSomething(new Shape());
...
}
...
}[/code]
Also mit beiden Lösungen ist der Compiler zufrieden ... wenn es keine obere Instanz gibt bekommt die VM die Exception und dann sieht man den berühmten StackTrace und das Programm hängt oder ist komplett abgebrochen worden...
Hope this helps
[ Dieser Beitrag wurde am 24.04.2002 um 11:35 Uhr von CengizS editiert. ]
Um das ganze ein wenig wissenschaftlich aufzuarbeiten (und damit man diesen Thread auch in die FAQ verschieben kann) hier noch ein paar Worte dazu aus "Netzwerke unter Java":
[...]Bei der Objektserialisierung werden Objekte über einen Stream verschickt. Dabei müssen die Objekte zunächst in einen Datenstrom umgewandelt werden. Darüber muss sich der Java-Programmierer aber meist keine Gedanken machen. Dies übernehmen die beiden oben genannten Klassen.
ObjectOutputStream wandelt ein Objekt in einen Datenstrom um, während ObjectInputStream diesen wieder in ein Objekt umwandelt.
Eine Instanz dieser beiden Klassen kann beliebige Input- und Output-Streams erweitern. Somit kann überall, wo mit Streams gearbeitet wird, die Objektserialisierung eingesetzt werden, was einen vielfältigen Einsatzbereich ermöglicht.
Frage: Lässt sich jedes Objekt serialisieren?
Es ist nicht immer wünschenswert, dass sich jedes Objekt serialisieren lässt. Daher gibt es die Möglichkeit zu bestimmen, welche Klassen serialisierbar sind. Man entscheidet also, ob alle Instanzen einer Klasse serialisierbar sind, und nicht, ob spezielle Instanzen serialisierbar sind.
Soll eine Klasse serialisierbar sein, so muss sie das leere Interface Serializable oder dessen Erweiterung Externalizableimplementieren:
[java]public class MySerializableClass implements Serializable {...}[/code]
Man muss also keine zusätzlichen Methoden schreiben, um eine Klasse serialisierbar zu machen, da das Interface leer ist.
Implementiert man jedoch die Erweiterung Externalizable, so muss man zwei Methoden implementieren, die den Serialisierungsprozess komplett festlegen.
Schützen von Informationen
------------------------------
Nicht alle Informationen eines Objektes können serialisiert werden. Wenn eine Member-Variable der Klasse als static deklariert ist, so muss sie nicht übertragen werden, da sie keine Objektvariable ist, sondern eine Klassenvariable. Es kann aber auch durchaus sinnvoll sein, dass nicht alle Informationen des Objektes übertragen werden. Um dies zu bewerkstelligen werden Member mit dem Schlüsselwort transient markiert. Transiente Membervariablen werden nicht in den Serialisierungsprozess mit einbezogen. Dies kann zum Beispiel sinnvoll sein, wenn ein Objekt ein Passwort enthält und dieses Passwort nicht mitübertragen werden soll. [...]
Hallo,
als Antwort auf die Frage von Besucher im Thread http://www.c-plusplus.net/ubb/cgi-bin/ultimatebb.cgi?ubb=get_topic&f=16&t=000456 möchte ich auf das Thema "Capturing Console Output" zu sprechen kommen und das folgende Beispiel hier einfügen. Für Ideen und Kritik bin ich dankbar [img]images/smiles/icon_smile.gif[/img]
import java.awt.*;
import java.awt.event.*;
import java.io.*;
import javax.swing.*;
/** Klasse, die ausschließlich static-Methoden beinhaltet um Programmausgabe
* zu sichern.
* @author Cengiz Sahin, 2002
* @version 1.0
*/
public class CaptureConsoleOutput {
/** Der Prozess der belegt wird */
private static Process process;
/** Startet das im Parameter args übergebene Programm samt Parameter und
* protokolliert die Ausgabe des Programms.
* ACHTUNG: Manche Programme schreiben ausschließlich auf den Error-Stream
* inStreams[1] - wie beispielsweise javac. Wenn die Ausgabe dieser
* Programme gesichert werden will darf das Array inStreams[] nur
* den Error-Stream beinhalten da sonst das Programm hängt!
* @param args Die Kommandozeile getrennt in einzelne Tokens
* @return Der Text der vom Programm ausgegeben wurde in einem StringBuffer
*/
public static StringBuffer startAndCapture(String[] args) {
try {
// Starte das Programm.
process = Runtime.getRuntime().exec(args);
} catch(IOException e) {
e.printStackTrace();
System.exit(1);
}
// Hole die Streams, die vom Prozess neu erzeugt wurden.
InputStream[] inStreams = new InputStream[] {process.getInputStream(), process.getErrorStream()};
StringBuffer buffer = new StringBuffer();
char[] buff = new char[256];
int count=0;
for (int z=0; z<inStreams.length; z++) {
BufferedReader reader = new BufferedReader(new InputStreamReader(inStreams[z]));
try {
while(-1 != (count = reader.read(buff, 0, buff.length))) {
buffer.append(String.valueOf(buff, 0, count));
}
} catch(IOException e) {
JOptionPane.showMessageDialog(null, "Error reading from BufferedReader: " + e);
System.exit(1);
}
}
process.destroy();
try {
process.waitFor(); // macht unter Win98 Probleme ...
} catch(InterruptedException e) {
e.printStackTrace();
}
return buffer;
}
/** Demo für CaptureConsoleOutput */
public static void main (String args[]) {
String[] prog = new String[] {"ping", "localhost"};
StringBuffer buffer = CaptureConsoleOutput.startAndCapture(prog);
String cmdLine = new String();
for (int i=0; i<prog.length; i++) {
cmdLine += prog[ i ];
}
JFrame frame = new JFrame("Captured output of \""+cmdLine+"\"");
frame.setSize(300, 200);
JTextArea area = new JTextArea(buffer.toString());
JScrollPane sp = new JScrollPane(area);
frame.getContentPane().setLayout(new BorderLayout());
frame.getContentPane().add(sp);
frame.addWindowListener(new WindowAdapter() {
public void windowClosing(WindowEvent evt) {
System.exit(0);
}
});
frame.setVisible(true);
}
}
Wie im Kommentar zu startAndCapture(...) schon steht funktioniert diese Klasse mit den meisten Programmen gut zusammen. Lediglich bei Programmen, die ausschließlich auf den ErrorStream schreiben (dazu zählt auch javac macht es Probleme, da bei diesen Programmen der normale OutputStream inStreams[0] leer bleibt und ergo die while-Schleife hängt - Vielleicht kann ja jemand hierfür eine Lösung finden; ich wollte nicht weiter forschen [img]images/smiles/icon_smile.gif[/img]
In diesem Falle einfach das Array inStreams[] nur mit dem ErrorStream (***process.getErrorStream()***) füllen.
Happy Capturing ...
Ich hab auch mal was Funktionstüchtiges zusammengeschustert. Was mir nur aufgefallen ist, ist dass man den Dialog nicht modal machen darf, denn dann startet der Thread erst nach dem Schließen des Dialogs.
[java]
import javax.swing.;
import java.awt.event.;
public class ProgressBarExample extends JFrame implements ActionListener {
ProgressBarExample() {
super("ProgressBarExample");
setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
JButton btn = new JButton("Drück mich!");
btn.addActionListener(this);
getContentPane().add(btn);
setSize(300, 200);
setVisible(true);
}
public void actionPerformed(ActionEvent e) {
new ProgressDialog(this);
}
public static void main(String[] args) {
new ProgressBarExample();
}
class ProgressDialog extends JDialog implements Runnable {
Thread t;
JProgressBar b;
ProgressDialog(JFrame owner) {
super(owner, false);
b = new JProgressBar(0, 100);
getContentPane().add(b);
setSize(200, 100);
t = new Thread(this);
t.start();
}
public void run() {
setVisible(true);
while(!t.isInterrupted() && b.getValue() < b.getMaximum()) {
try {
Thread.sleep(100);
}
catch(InterruptedException e) {
e.printStackTrace();
}
b.setValue(b.getValue() + 1);
}
setVisible(false);
dispose();
}
}
}[/code]
Man könnte nun noch eventuell abfragen ob, der Thread schon existiert, damit man nicht durch wildes Buttongeklicke mehrere Threads starten kann. Der Balken fängt dann jedoch immer von vorne an zu zählen.
[ Dieser Beitrag wurde am 05.04.2002 um 11:18 Uhr von CengizS editiert. ]
Hier ist noch ein recht interessanter Link der in einem anderen Posting hier im Java-Forum von Gregor gepostet wurde. Leider befürchte ich dass der Link in dem Thread untergeht. Ergo ist er hier noch einmal images/smiles/icon_smile.gif
Coding Conventions (by Sun)
[ Dieser Beitrag wurde am 22.03.2002 um 15:57 Uhr von CengizS editiert. ]
Hier ein Beispiel:
int eingabe;
eingabe = Integer.parseInt(args[0]);
System.out.println(eingabe + "in Hexdezimalcode: " +
Integer.toHexString(eingabe));
Ganz nützlich solche Methoden.
Das gleiche geht auch für Binärzahlen:
Integer.toBinaryString(`Variable`)