i118jix

Eigenlich will ich ja gar nicht klug schwätzen... Zu ArgoUML: Es gibt da oben links im Menü unter Datei->Import die Möglichkeit zum Import von Java Sourcen. Man kann so nette dinge festlegen, wie zum Beispiel Arrays in UML übersetzt werden sollen. Es also schon irgendwie leicht possible Reverse Engeneering zu betreiben. Zum Together PlugIn: Das gibt es in der Tat nur für den WSAD. Nennt sich Together WSE und soll angeblich das Pendant zum Together Control Center sein. Zumindest haben die Jungs von Borland das auf der Broland Enterprise Essentials noch vor 2 Wochen gesagt... What ever. Nichts für ungut.

sorry http://argouml.tigris.org/

Das unabhängige Standard UML-Tool ArgoUML ist in Java geschrieben und steht auf der folgenden URL zum Download zur Verfügung: http://argouml.tigris.org/argouml.tigris.org/ Alternativ gibt es unter andrem die kommerziellen Tools von Borland das Together Control Center ist auch im JBuilder integriert und gibt es auch als Plugin für Eclipse bzw. allen darauf aufbauenden IDE wie zum Beispiel den IBM WSAD. Ferner gibt es noch die Tools von Rational. Die letzt gennaten Tools sind aber nur für teuer Geld legal zu beziehen.

Habe die URL auch gerade gefunden...Danke. Kurz zu 2. Das Applet soll für eine Homepage erstellt werden. Der DAU checkt es aber bestimmt nicht ein Plug In runterzuladen, wenn er nicht dafür schon zu faul ist, daher auch die Mühe mit der Abwärtskompabilität.

Hallo Forum, da der IE von Winzigweich überwiegend nur den Standard des JDKs 1.1 (bin da aber auch nicht zu 100 pro sicher) unterstützt, stellt sich mir ein Kompabilitäts- problem bei der Entwicklung eines Applets. Mein Applet läuft ganz toll mit einem 1.4 Plug In, der Code ist von der Sache her allerdings auch 1.1 komptabil sein. Sobald ich allerdings Code mit dem Compiler von 1.4 kompiliere kann ich mir das Applet nicht ohne 1.4 Plugin im IE anschauen (Dazu ein einfaches Beispiel unten). Ein JDK 1.1 ist nicht mehr von Sun zu beziehen. Sind jemandem dazu Lösungsansätze bekannt? <code> // imports public class SimpleApplet extends Applet { public void paint(Graphics screen) { screen.setColor(Color.red); screen.drawString("...und Gott sprach:", 5, 40); } } </code>

int number = 146565; int anzahlStellen = (new Integer(number)).toString().length();

Ich möchte nur zur Vollständigkeit auf das Interface javax.servelt.http.HttpSessionListener hinweisen. Eine Klasse, die dieses Interface implementiert, besitzt dadurch implizit die Methode public void sessionDestroyed(HttpSessionEvent arg0) { } Sie wird vom Container aufgerufen, wenn eine Session nicht mehr gülitg ist. Dies ist dann der Fall, wenn beispielsweise der session timeout bei 0 ist oder die methode invalidate des HttpSession Objekts aufgerufen wird. Dem Container muß die die Klasse aber auch im Deployment Deskriptor über den Eintrag <listener> <listener-class>MySessionListener</listener-class> </listener> bekanntgemacht werden. Die Notwendigen Schlüsse aus dieser Information überlasse ich dem Leser. Es sei dennoch erwähnt dass das eingangs erwähnte Problem nur teilweise gelöst ist.

Für das Zeichnen eines Image auf einem von java.awt.Component abgeleiteten Objekts ist es in den meisten Fällen unbedingt notwendig zu warten bis das Bild vollständig in den Speicher geladen ist, bevor es gezeichnet wird. Dies wird mit der aktuellen API nicht gewähleiste. Es ist daher nötig die MediaTracker klasse zu benutzen. public java.awt.Image getImage(String file) { Component observer = panel.getComponent(); Image img = panel.getImage(System.getProperty("user.dir",".") + "/de/jenix/www/myClasses/bloodsport/images/img1.jpg"); MediaTracker mt = new MediaTracker(observer); mt.addImage(img, 0); try { mt.waitForAll(); } catch (InterruptedException e) {} return img; }

Nein. Sofern du dein Programm mit der IDE startest werden deine Mounts(gibt es dieses Wort?) automatisch in den Classpath für die Ausführung deines Programms geschrieben. Außerhalb deiner IDE mußt du sie in den Classpath eintragen oder zumindest im aktuellen Verzeichnis zur Verfügung stellen. Bedenke außerdem, das du Jars komplett in den CLASSPATH einträgst. also SET CLASSPATH = C:\MyLibs\MySpecialLib.jar;

Sofern du Sun One Studio 4 CE könntest du das Problem damit lösen, in dem du den Filter für das Jar File auf <all classes> änderst. (Properties->File Filter) Irgendeine Nase dachte sich bei Sun es wäre vorteilhaft die Voreinstellung legilich auf Java Dateien zu setzen. Solltest du nicht Sun One Studio 4 CE könnte es dennoch daran liegen das dein IDE(sofern du eine verwendest) einen fiesen File Filter gestzt hat.

Programm oder Befehle können durchaus aus der JVM gestartet und überwacht werden. Sie laufen dann als Proccess-Klasse als eigener Thread. Die E/A können über Input bzw. OutputStreams gelesen bzw. manipuliert werden. // Tomcat beenden Process pro = Runtime.getRuntime().exec("D:\\PROGRAMME\\NEWTOMCAT\\BIN\\shutdown.bat"); /* Abfangen der Ausgabe BufferedReader in = new BufferedReader(new InputStreamReader(pro.getInputStream())); String line = null; while ((line = in.readLine())!=null) System.out.print(line); in.close(); */ try{ pro.waitFor(); // System.out.println("Stoppvorgang von Tomcat beendet."); } catch (Exception e ){ throw new InternalError("Konnte nicht auf das Ende von Tomcat warten."); }

Ja Stefan, ich meine JNDI und nicht JDBC. JNDI ist ein Service über den du Ressourcen unter einem LookUp für den ganzen Container zur Verfügung stellen kannst. Ähnlich wie man Objekt beispielsweise im Application Scope hinterlegen kann, ist es mit JNDI möglich Objekte für alle Appliaktionen eines Application Servers zur Verfügung zu stellen. (Wobei man sicherleich streiten kann, ob der Tomcat ein richtiger Application Server ist ) Wie eingangs beschrieben nutze ich JNDI, um die Datenbank unabhängig von der Webappliaktion zu halten, da noch nicht geklärt ist, welches Datenbanksystem letzlich für die Site genutzt werden soll. Zu Jaraz Habe mit hsqldb.jar file bereits ins common/lib bzw. ins lib Verzeichnis meiner Applicaktion kopiert. Ich habe auch schon probiert die Klassen entpackt in die classes Verzeichnisse zu legen. Da ich aber im Scriptlet bereits über den DriverManager die Treiberklasse gefunden habe, verstehen ich nicht warum Tomcat sie nicht laden kann. ich verwende "org.hslqdb.jdbcDriver". Diese wird zum Beispiel auch in der Doku von Tomcat benutzt.

Hallo Forum, für die Erstellung einer Homepage benutze ich einen Tomcat 4.1.X. Da ich die Site als WAR-file später auf einem anderen Server deployen möchte, ist es notwendig eine Verbindung zur Datenbank über JNDI zu realisieren. Dummerweise wirft der Tomcat immer einer Exception beim Versuch die Connection zu besorgen. Er teilt mit, dass die Treiberklasse 'null' sei. Tomcat ruft dabei seine eigene .forname() Methode auf. In einem Scriplet innerhalb einer JSP gelang es mir jedoch konventionell über den DriverManager eine Connection aufzubauen. Die Klasse müsste daher eigentlich bekannt sein. Ich verwende HSQLDB und gebe für den LookUp als Treiberklasse org.hsqlb.jbcDriver an. Hat jemand eine ähnliche Erfahrung gemacht? Könnte es daran liege dass ich den standalone Mode und nicht den Servermode der Datenbank benitze. Gruß JN1

Bin ich jetzt immer noch IT-Newbie? :confused: