Es bestehen zwei lauffähige, fertige Projekte in Maven, welche beide auch vollwertige Artefakte bilden können.

Zum einen die Webanwendung — nennen wir sie hier mal webportal — mit einem WAR-Artefakt, etwa für einen Tomcat. Ob das Artefakt als Snapshot oder Release gemacht wird, ob es nur generiert oder auch in ein Repository deployt wird, ist hierbei nicht von weiterer Bedeutung.

Zum anderen die normale Clientanwendung — nennen wir sie doch einfach userclient — mit einem JAR-Artefakt. Wichtig ist natürlich, dass hier eine startfähige Main-Klasse vorhanden ist. Dies sollte jedoch der Regelfall sein, daher nur der formale Hinweis.

Zusammengefasst, und der Auftrag an dieses Howto ist also: Wie konfiguriert und erweitert man den Buildzyklus in welchem Projekt an welcher Stelle am geschicktesten, um auf einfachem Wege die JAR-Datei userclient in die Webanwendung webportal als Java Webstart zu integrieren. Dabei ist es hilfreich, wenn man via pom.xml (und natürlich der Macht der Properties) die Versionen spezifizieren kann. Der gesamte Prozess von auswählen, signieren und ausliefern soll dabei automatisch und ohne weiteres Eingreifen des Entwicklers geschehen können. Idealerweise sollte das ganze auch optional sein — dazu gibt es dann mehr unter “Optimierungen und Verbesserungen”.

Die Grundlagen

Ich möchte jetzt nicht viel über die Grundlagen verlieren, nur so viel sei gesagt. Aus Sicht von Maven ist die Konfiguration “nur” ein weiteres Plugin von vielen. Daraus ergibt sich natürlich auch die Möglichkeit, via Properties oder Profilen die Konfiguration sehr dynamisch zu halten. Webstart ist eine Technik, die an sich nichts mit Maven zu tun hat. Man kann auch “händisch” seine Jar-Datei über eine URL verfügbar machen. Man muss dann jedoch alles selber und richtig machen: Versionisierung, Signierung und Deployment. Die Signierung ist gerade dann wichtig, wenn die Applikation erweiterte/volle Rechte benötigt.

Die Möglichkeiten

Es gibt eine Reihe von Maven-Plugins, die einen unterschiedliche Ansätze und Lösungen bieten.

Das Maven Jar Plugin bietet etwa unter anderem die Möglichkeit, die Jar-Dateien zu signieren. Dies wäre jedoch nur die halbe Miete, da weder die Jar-Dateien bekannt noch auslieferbar sind. Auch das Keytool plugin ist nicht vollständig, denn es unterstützt zwar das Keystore gestützte signieren, aber auch nicht mehr. Wohl aber können diese Plugin als Basis für andere dienen.

Weitaus mehr Funktionen kann das Webstart Maven Plugin bieten. Es gibt verschiedene Arten der Erzeugung der Jnlp-Datei und dem damit verbundenen Sammeln, Bestimmen und Signieren der Abhängigkeiten in Form weiterer Jars oder Classfiles. Es ist auch ein hilfreiches Plugin, wenn man aus einem Projekt heraus direkt Jnlp & Ressourcen erzeugen will.

In diesem Howto ist aber vor allem ein Ziel von Relevanz:Â Die Variante mit dem Jnlp-Download-Servlet: das Goal webstart:jnlp-download-servlet.

Dieses Goal erzeugt im Buildprozess ein weiteres Verzeichnis mit den Ressourcen des userclients und der dazugehörenden Jnlps. Ein spezielles Servlet übernimmt die Auslieferungen.

Die Konfiguration im Projekt userclient

Das Projekt muss und sollte nicht “wissen”, dass es über Webstart irgendwo eingebunden wird. Daher sind keine Änderungen nötig. Wohl aber muss bekannt sein, wie die aktuelle bzw. die gewünschte Version ist und ggf. das Maven-Repository der Deploys.

Die Konfiguration im Projekt webportal

Das webportal muss hingegen durchaus von der Existenz des userclients wissen, denn jenes es soll ja in diese Webanwendung integriert werden. Die Konfiguration besteht im Wesentlichen aus drei Schritten: JnlpDownloadServlet-Abhängigkeit einfügen, Servlet in der web.xml registrieren und Build-Plugin in der pom.xml konfigurieren.

JnlpDownloadservlet (pom.xml)

Das Maven-Paket findet sich unter dem Namen com.sun.java.jnlp bzw. jnlp-servlet wieder. Als einfache Abhängigkeit ist es damit im Classpath und beispielsweise in der web.xml verwendbar. Weitere Informationen.

<dependency>
    <groupId>com.sun.java.jnlp</groupId>
    <artifactId>jnlp-servlet</artifactId>
    <version>5.0</version>
</dependency>

web.xml

Zur Basiskonfiguration muss nur das Servlet registriert und mit einem URL-Pattern verknüpft werden. Das klingt trivial, und das ist es auch.

<servlet>
  <servlet-name>JnlpDownloadServlet</servlet-name>
  <servlet-class>jnlp.sample.servlet.JnlpDownloadServlet</servlet-class>
</servlet>
<servlet-mapping>
  <servlet-name>JnlpDownloadServlet</servlet-name>
  <url-pattern>/webstart/*</url-pattern>
</servlet-mapping>

Damit wird die URL domain.tld/context/webstart an das Servlet gemappt. Dadurch kann das Servlet auch auf “virtuelle Dateianfragen” reagieren, etwa nach Jar-Dateien ohne Versions-Qualifkation (obwohl sie als versionierte Artefakte vorliegen).

Die Konfiguration lässt noch einige Dinge erweitern, verändern und tweaken (siehe Absatz Optimierungen und Verbesserungen). Für den Haupteinsatzzweck – das Bereitstellen einer oder mehrerer Jars via Webstart ist das jedoch völlig ausreichend.

Weitere Informationen bei Oracle/Java. Und weitere Informationen bei Codehaus.

pom.xml

Neben der Abhängigkeit des JnlpDownloadServlet muss das eigentlichen Maven Webstart Plugin für seinen Einsatz konfiguriert werden. Das Build-Plugin benötigt zudem noch ein Template (für die Generierung der Jnlp), die wird weiter unten beschrieben.

Zur Grundkonfiguration gehört:

1. Wo liegt das Jnlp-Template?
2. Wie heißt der Ausgabename der Jnlp?
3. Welche Abhängigkeiten gibt es für das Paket — hier wäre das der userclient?

Des Weiteren lässt sich bestimmen, ob etwa weitere (transitive) Abhängigkeiten mitausgeliefert werden sollen (bei Webstart ist das wohl meist sinnvoll), ob die Ressourcen signiert werden sollen und ob alles nochmals komprimiert deployt werden soll. Weitere Informationen.

Prinzipiell ist man weder auf eine Abhängigkeit pro Paket/JNLP beschränkt noch auf eine JNLP pro Plugin-Call geschweige denn des gesamten Projekts. Über das Konfigurationsschlüsselwort commonJarResources können sogar gemeinsam verwendete Abhängigkeiten definiert werden.

Da der userclient erweiterte Rechte benötigt, müssen alle Classfiles und Jars signiert werden. Wahlweise verwendet dafür einen vorhandenen Keystore oder erstellt einen neuen. Für diese Zwecke wird pro Buildvorgang ein neuer Keystore angelegt, damit signiert und danach wieder gelöscht.

Die Execution ist sinnigerweise process-resources mit dem Goal jnlp-download-servlet, denn streng genommen sind es ja nur weitere Ressourcen.

<plugin>
  <groupId>org.codehaus.mojo.webstart</groupId>
  <artifactId>webstart-maven-plugin</artifactId>
  <executions>
    <execution>
      <phase>process-resources</phase>
      <goals>
        <goal>jnlp-download-servlet</goal>
      </goals>
    </execution>
  </executions>
  <configuration>
    <outputDirectoryName>webstart</outputDirectoryName>
    <excludeTransitive>false</excludeTransitive>
    <jnlpFiles>
      <jnlpFile>
        <templateFilename>template.vm</templateFilename>
        <outputFilename>UserClient.jnlp</outputFilename>
        <jarResources>
          <jarResource>
            <groupId>org.example.userclient</groupId>
            <artifactId>example-userclient</artifactId>
            <version>1.0.0</version>
            <mainClass>org.example.userclient.Main</mainClass>
          </jarResource>
        </jarResources>
      </jnlpFile>
    </jnlpFiles>
    <outputJarVersions>true</outputJarVersions>
    <verbose>false</verbose>
  </configuration>
</plugin>

Mit dieser Konfiguration werden die Jar-Dateien inkl. Abhängigkeiten in das Verzeichnis webstart gepackt — remember? wie in der web.xml. Das Template heißt template.vm und ist per default unter src/main/jnlp zu finden. Dies ließe sich mit templateDirectory überrschreiben. Der Name der Jnlp lautet UserClient.jnlp, damit ergibt sich die spätere Web-Url: http://example.org/context/webstart/UserClient.jnlp. Die eigentlichen Ressourcen und Abhängigkeiten werden in jarResources/jarResource definiert. Bei einfachen Projekten wird dies nur eine Ressource sein, theoretisch wären auch mehrere möglich. Die Konfiguration ähnelt der der dependencies.

template.vm

Im Prinzip ist das Template eine unfertige Jnlp. Sie wird durch das Maven Plugin mit den endgültigen Daten befüllt. Da bereits die pom.xml über einige Informationen wie Projektnamen, -beschreibung oder -url verfügt, können so sehr einfach die Daten mit übernommen werden. Man kann jedoch auch die Platzhalter entfernen — es ist eben nur ein Template.

Ein Beispiel könnte so aussehen:

<jnlp spec="$jnlpspec" codebase="$$codebase">
  <information>
    <title>$project.Name</title>
    <vendor>$project.Organization.Name</vendor>
    <homepage href="$project.Url"/>
    <description>$project.Description</description>
    <icon href="../resources/images/logo.png"/>
    <icon href="../resources/images/logo.png" kind="splash"/>
#if($offlineAllowed)
<offline-allowed/>
#end
  </information>
#if($allPermissions)
<security>
<all-permissions/>
</security>
#end
  <resources>
    <j2se version="$j2seVersion"/>
$dependencies
  </resources>
  <application-desc main-class="$mainClass"></application-desc>
</jnlp>

Mehr oder weniger simpel, oder? Eventuell sollte man die Adressen zum Logo anpassen (oder entfernen); gerade die letzte Zeile erzeugt einen netten Splashscreen (Ladebild) während dem Starten und Laden der Anwendung. Das ist immer gerne willkommen.

Wichtig: Im Gegensatz zu dem einen oder anderen Beispiel ist es hierbei wichtig, dass die Variable $$codebase heißt. Nicht etwa ${codebase}. Insgesamt sind in der JNLP — sofern man sie über das Servlet ausliefert — folgende Variablen verfügbar: codebase, name, context und site.

Optimierungen und Verbesserungen

“Einmal signiert, bitte!”

Um all-permissions nutzen zu können, müssen die Jars und Classfiles signiert werden. Das erreicht man, indem man unter dem XML-Knoten configuration einen Knoten sign anlegt, etwa:

<sign>
	<keystore>keystore.ks</keystore>
	<keypass>pass</keypass>
	<storepass>pass</storepass>
	<alias>userclient</alias>
	<validity>36500</validity>
	<dnameCn>UserClient</dnameCn>
	<dnameOu>Software Development</dnameOu>
	<dnameO>The Example Networks</dnameO>
	<dnameL>Cologne</dnameL>
	<dnameSt>NRW</dnameSt>
	<dnameC>DE</dnameC>
	<verify>false</verify>
	<keystoreConfig>
		<delete>true</delete>
		<gen>true</gen>
	</keystoreConfig>
</sign>

Hierbei wird der Keystore lokal erzeugt (keystoreConfig/gen ist true) und nach Gebrauch wieder gelöscht (keystoreConfig/delete ist true). Selbstverständlich kann man hier auch a) noch einen Keystore-Generator (s.o.) nutzen oder einen fest konfigurierten, dauerhaften. Dann sollte man natürlich die Konfiguration entsprechend anpassen.

“Bitte Optional” — alles in ein Profil

Die Profile in der pom.xml sind ein mächtiges Werkzeug, um bestimmte Features zusammenzufassen. So könnte man das gesamte Build-Plugin in ein Profil — etwa mit dem Namen with-webstart — ablegen.

Selbst die Abhängigkeit zum JnlpDownloadServlet kann man dorthin verlagern — wenn man daran denkt, dass in diesem Falle auch die web.xml dynamisch erstellt werden soll.

Macht der Properties

Man kann die Gesamtkonfiguration um einiges komfortabler machen, indem man Properties einführt und deren Standardwerte “oben” in der pom.xml definiert. Gute Kandidaten hierbei wären: userclient.version, keystore.file, keystore.keypass, keystore.storepass und keystore.alias.

Noch mehr in Sachen Jnlp

In der web.xml kann des Weiteren das verhalten des JnpDownloadServlet verändert werden. Ein Überblick über einige Möglichkeiten:  Mimetypen ändern, Dateiendungen ändern, weitere Mappings anlegen, spezielles Debugging.

Leider wurden mit dem Release 2.x auf 3.0 eine Reihe von API-Changes vollzogen. Zugegeben, die waren auch sicher alle sinnvoll, weil Komponenten wie die Authentifizierung weiter geteilt wurden und man somit wesentlich flexibler ist, neue Anforderungen zu ermöglichen (Baukastenprinzip). Aber die Dokumentation ist – gesamtheitlich betrachtet – irgendwie immer noch mies und oft nicht aktualisiert. Oder man findet im Internet einfach nur (alte) Beispiele.

Die http-Direktive

Im Namespace von Spring Security existiert das Tagelement http, mit welchem man kurze, knappe und verständliche Konfigurationen anlegen kann. Der Vorteil liegt klar auf der Hand: Man muss nicht alle Beans, Listener und Provider anlegen, denn das geschieht automatisch. Tja, wären da nicht ein paar Einschränkungen in der Funktionsvielfalt.

Konkretes Beispiel: Remember Me

Just wurde das Minor-Release 3.0.1 veröffentlicht, und nur wenige Tage später zu erfahren, dass Remember Me kaputt sei. Egal, fahren wir erstmal weiter mit 3.0.0.

Laut Dokumentation ist es am einfachsten, wenn man die Direktive remember-me (Security Namespace) innerhalb der http-Direktive (Security Namespace) verwendet. Ohne irgendeine Angabe wird ein stinknormales, Cookie basiertes Tokenverfahren ohne (echten) privaten Schlüssel verwendet. Reicht für den ersten Einsatz erstmal auf, soll ja erstmal funktionieren.

Fehlermöglichkeit 1a: Man loggt sich ein, und es passiert nichts (kein “RememberMe”-Cookie).
Lösung: Wenn man einen eigenen Auth-Filter einsetzt, muss man diesem auch den RememberMe-Service “setten”. Außerdem muss der SecurityChainFilter (web.xml!) auch auf die login-Seite verweisen. Es dürfen auch keine Filter bei der Konfigurierung von intercepted Urls (speziell hier: login, logout) gemacht werden.

Fehlermöglichkeit 1b: Es passiert noch immer nichts?
Lösung: Vielleicht wurde vergessen, einen Parameternamen für den Request zu setzen. Der Standardname ist ein typischer Springname, der natürlich unschön ist. Und den kann man nicht über die RememberMe-Direktive setzen, also muss man eh einen eigenen Service definieren. Bäm. Referenzierung geht dann zwar noch, aber für mehr ist die RememberMe-Direktive dann nicht mehr zu gebrauchen.

Fehlermöglichkeit 2a: Man besucht die Seite ohne Login, aber mit Cookie – und die Loginseite kommt (Log sagt kein gültiger Auth).
Lösung: Man kann der Log trauen, wenn sie zwar beim Einloggen nun einen Token ablegt (kann man zum Beispiel sehr einfach mit diesem Firefox-Addon inkl. Editor(!) verifizieren), dieses aber beim erneuten Besuchen der Seite (bzw. ohne JSPSESSION-Cookie) nicht verwendet bzw. wird nicht erkannt. Schlussendlich half u.a. das Umbenennen der Userservices-Bean in “userService”. Außerdem sollte die Loginseite keinen Filter/Access haben (s.o.) Lieber 2x prüfen!

Fehlermöglichkeit 2b: Es erscheint eine Ausnahme, dass der Key falsch sei.
Lösung: Dazu muss man wissen: Sobald  man eine individualisierte RememberMe-Konfiguration nutzt, wird auch der Key nicht mehr vernünftig auf alle Komponenten (Provider, Filter, Manager) gesetzt. Beim Anlegen wird also der eigene Key verwendet, beim Auslesen der Standardkey. Yes! (s.o.)

Fehlerm̦glichkeit 3: Man besucht die Seite ohne Login, aber mit Cookie Рaber wie in 2 nur die Loginseite.
Lösung: Im Logger/Debugger kann man nun feststellen, dass zwar das Cookie gefunden wurde, das Token gefunden und validiert wurde aber dann keine Rechte existieren – aha? Wahrscheinlich fehlt im Provider noch ein zusätzliches Setting der Komponenten. Am besten von RememberMe Service/Filter/Provider jeweils alle möglichen Properties durchgehen. Jaja, wie gesagt..

Fehlermöglichkeit 4: Das Ausloggen (beispielsweise logout.html) hat nach Aktivierung von Rememberme plötzlich keine Auswirkungen mehr.
Lösung: Zwar wird die Seite gefunden, aber es wird kein “Logout” gemacht. Auch hier sollte man prüfen, ob ein SecurityChainFilter (web.xml) auch für die logout-Seite greift.

Fehlermöglichkeit 5: Das Besuchen der Seite wirft einen Fehler (ggf. “mit weißer Seite”), dass keine neue Session erstellt werden kann.
Lösung: Richtig, nach einem Request ist ja dann auch zu spät. Das Attribut create-session in der Direktive http sollte daher auf “ifRequeried” gestellt sein.

Fazit:

• SecurityChainFilter immer prüfen
• Intercepted Urls prüfen
• RememberMe-Direktive innerhalb der http-Direktive ist quasi abgesehen von der services-ref unbrauchbar.

Anmerkung:

Natürlich kann man sich das Problem mit den SecurityChains vom Hals schaffen, indem man stupide ein /* filtert. Das hat jedoch zur Auswirkung, das Spring Security auch jeden verdammten Request anguckt; bei zusätzlichen (statischen) Inhalten wie Javascript, Stylesheets, Bildern, Flash u.ä. ist das ein Overhead, der unnötig ist.

Während jetzt Apple-Benutzer leichtfertig über dieses Feature lachen können, ist dies für Hauptzielgruppe der Anwendung (also Windowsbenutzer) eine sinnvolle Funktion. Es hat sicherlich wenig Sinn, umständlich einen Komplett-Screenshot anfertigen zu müssen.. viel einfacher kann das Programm das ja selbst machen.
Es gibt eine Reihe von Suchtreffern in Google, die durchaus lesenswert sind.

Die Grundidee ist, dass man sich selbst ein Graphics-Objekt erstellt und dann die JComponent darauf arbeiten lässt. Im Falle von Swing ist dies idR vom Framework vorgegeben (nämlich für den Bildschirm), hier aber wollen wir ja ein eigenes Bild haben. Die Höhe und Breite ist in den meisten Fällen von der Komponente zu erfragen.
BufferedImage bi = new BufferedImage(width, height, BufferedImage.TYPE_INT_ARGB);

Anschließend brauchen wir das zugehörige Graphics-Objekt, denn damit arbeiten die Paint-Methoden. Clue Nummer 1: Man könnte in Versuchung kommen, und einfach getGraphics() zu nehmen – ist ja auch naheliegend. Tatsächlich erstellt das aber auch nur ein Graphics-Objekt, während createGraphics() ein Graphics2D-Objekt erstellt. Und in den meisten Fällen braucht man das auch.
Graphics2D g = bi.createGraphics();

Anschließend muss man sich entscheiden, welche Zeichenroutine man anstoßen will. Es gibt prinzipiell folgende Möglichkeiten: paint(Graphics), paintComponent(Graphics) und paintAll(Graphics). Sofern paintComponent() ausreicht, diese nutzen. Im Falle des JUNG-Graphen mit verschiedenen Subelementen und eigenem Renderer funktioniert jedoch nur paintAll(Graphics) auf allen System zuverlässig. Während paint(Graphics) unter MacOS und Linux noch funktioniert, produziert es unter Windows unschöne Ergebnisse.

Anschließend kann man mit dem statischen Aufruf ImageIO.write(bi, "png", file); das gesamte Bild als — hier PNG — speichern. Achtung: Dies ist eine JavaSE6-Klasse, in den Vorgängern benötigt man dann den Umweg über FileStream & Co.

[1] jung.sourceforge.net
[2] java.sun.com

Joa, es ist wieder Zeit für einen Artikel in der Java/DA-Reihe.

Als erstes und sehr einfach zu testendes Kriterium gilt beim Testen die Code Coverage. Eigentlich sehr simpel, denn es quantifiziert nur die Code-Coverage, also von wie vielen Zeilen Code (Instructions) tatsächlich wie viele (bzw. welche) auch ausgeführt werden. Da man dies natürlich gerne automatisiert machen möchte, sind Tests wie mit jUnit ideal. Aber, auch normale Anwendungen sind mitzutracen und den Codecoverage ist zu ermitteln.

Für Eclipse gibt es dazu ein prima Plugin namens EclEmma. Und auch schnell über die Update-URL im Manager installiert. EclEmma dient dabei als eine Art Wrapper für verschiedene Launchtypen – also beispielsweise als normale Applikation oder einen jUnit-Test bzw eine ganze Suite (Plugins). Das Ergebnis wird nach Beendigung des Programms/Tests innerhalb von Eclipse in einer Baumstruktur dargestellt; sehr schön ist auch die grafische Hervorhebung direkt im Sourcecode. Alternativ kann man sich das Ergebnis auch als HTML exportieren lassen.

Auf Seite der Konfiguration ist es natürlich blöd, dauernd mit diesen URLs zu hantieren. Aber, es gibt für alles eine Lösung: MMan nehme YAML. Sehr hübscher Syntax, fast ohne Overhead und damit viel Platz für das eigentlich Wesentliche: Informationen und Daten. Das Doctine Project, ein PHP Object Relational Mapper, nutzt zur Definition von Datenbankschemata auch eine YAML-Struktur (Beispiel).

Da ich weder Lust auf PHP coden noch das Aufsetzen eines Java-Servers hatte, habe ich eine kleine, feine Java-Anwendung geschrieben. Sie konvertiert ein DB-Schema in YAML in ein Bild (zeigt dieses an) und lässt auf Wunsch dieses Speichern.

Downloads (benötigt Java 1.6):

1. Ausführbare Jar kAml.jar
2. Dmg Imagefile alsAnwendung für Mac OS X

Der Fehler verursacht die aktuell ausgewählte Java-Version (und das ist bei den meisten Leuten der Standard Java 1.5.0). Wenn jedoch die Jar mit Java 1.6 kompiliert wurde, kann der 1.5-Loader damit nichts anfangen bzw. schützt aus naheliegenden Gründen vor der Ausführung. Zwar ist auf Mac OS X System der Version 10.5 auch Java 1.6 installiert, dieses ist jedoch kein Standard.

Es gibt dafür nun drei Möglichkeiten:

1. Der Benutzer startet die JAR nicht mit Doppelklick bzw. dem Kommando “java -jar JarFile.jar” sondern mit der direkten Angabe im Frameworkverzeichnis.. diese Lösung ist inakzeptabel.
2. Der Benutzer stellt seine Default-JVM auf 1.6 um.. das machen die Entwickler eh, aber der Benutzer wird auch damit überfordert sein. Auch keine akzeptable Lösung.
3. Man erstellt eine Mac-Application mit entsprechenden Application-Bootloader und einer Art Manifest, wo eingestellt wird, welche Java-Version verwendet werden muss. Damit findet sich Java 1.6 sogar dann, wenn man als Default 1.4 eingestellt hat. Außerdem hat es den positiven Nebeneffekt, dass die “technische” Jar vor dem Benutzer durch ein Anwendungsymbol kaschiert wird.

MacUtils.makeWindowLeopardStyle(getRootPane());

If I disable (comment out) this line there will no exceptions. What a..

The structure of components: One Mainframe with BorderLayout (Toolbar, Sidebar and MainContent). The MainContent contains eventually the graph, the corresponding satellite component is in the sidebar.

Original post:

I had already posted about it last week. But now it seems that is was not a reasonable solution.

I have a java swing application which uses standard java swing elements and the jung2 graph framework visualizing graphs. The application is developed under java 1.6 and mac os x 10.5.6.

The actual problem is that since yesterday the AWT-Eventthread crashed, for example like this:

Thu May 7 15:04:28 X.localdomain java[2002]Â : CGSResolveShmemReference : reference offset (65232) exceeds bounds (32768) on shmem obj 0x257e
Exception in thread "AWT-EventQueue-0" java.lang.RuntimeException: Non-Java exception raised, not handled! (Original problem: Error (1000) creating CGSWindow)
at apple.awt.CRenderer.doRect(Native Method)
at apple.awt.OSXSurfaceData.doRect(OSXSurfaceData.java:1247)
at apple.awt.CRenderer.fillRect(CRenderer.java:157)
at apple.awt.CRenderer.fillRect(CRenderer.java:145)
at sun.java2d.pipe.ValidatePipe.fillRect(ValidatePipe.java:58)
at sun.java2d.SunGraphics2D.fillRect(SunGraphics2D.java:2501)
at edu.uci.ics.jung.visualization.BasicVisualizationServer.renderGraph(BasicVisualizationServer.java:341)
at edu.uci.ics.jung.visualization.BasicVisualizationServer.paintComponent(BasicVisualizationServer.java:321)
at javax.swing.JComponent.paint(JComponent.java:1027)
at javax.swing.JComponent.paintChildren(JComponent.java:864)
at javax.swing.JComponent.paint(JComponent.java:1036)
at javax.swing.JComponent._paintImmediately(JComponent.java:5096)
at javax.swing.JComponent.paintImmediately(JComponent.java:4880)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:749)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:679)
at javax.swing.RepaintManager.seqPaintDirtyRegions(RepaintManager.java:659)
at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:128)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:300)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:210)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:200)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:195)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:187)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)

This happens in the event thread, so the application is “still” useable. Well, of course, the graph painting is a mess.

After googling, I found some solutions:

1. Execute the file access rights (permissions)-fix via disk utilities & reboot the maschine. Yes, this will fix the problem for some starts, but then.. what a dejavu.
2. Assure that the paint-process is not outside of the awt-thread.. yes it is. See trace. (Link developer.apple.com)
3. Exclude the SWT jar.. well, I do not use this and I have not include it. (Link publicobject.com)
4. Use not the apple ui manager.. well, i replace the manager for the components of jung, i disabled my own selfwritten graph vertex renderer.. no changes. No less exceptions, nothing.

Perhaps this could be an issue by jung, but..

• why only on this mac – but no error/exception on others systems like windows and linux? Also I have a 2 years older macbookpro.. no problem there.
• why, or some time, is there no problem after fixing the file access rights (permissions) and rebooting the machine?

Currently, I have no solution.. the exeptions raises while painting the graph (which uses many paint()/Graphs objects ofc) moving/zooming it. I was able to catch some of the strange exceptions overriding the default visualizerviewer (by jung) and put in a small try-catch-wrapper of the corresponding method (here renderGraph). But other exceptions raised within javax.swing.Component and so on…

And.. how strange: the line

Thu May  7 15:04:28 X.localdomain java[2002] <Warning>: CGSResolveShmemReference : reference offset (65232) exceeds bounds (32768) on shmem obj 0x257e

I’m very appreciate if someone has an idea or solution.

Der genaue Wortlaut der Meldung: exception: java.lang.RuntimeException: Non-Java exception raised, not handled! (Original problem: Error (10000) creating CGSWindow)

Nach ein bisschen Recherche mit dieser Meldung stieß ich dann auf diesen Thread, in welchem auch die Lösung parat steht: Zugriffsrechte reparieren lassen und rebooten. Warum man rebooten muss (man muss es, habe es ausprobiert), entzieht sich meiner Kenntnisse; vielleicht werden manche Ressourcen nur einmal geöffnet?

jUnit bietet (in Eclipse) dafür die Option TestSuite an. Eine TestSuite ist ja auch genau das, was wir brauchen. Leider zeigt der Wizard keine unserer TestCases an.. warum? Nach einigem Recherchieren (viele Suchergebnisse zeigen indirekt noch auf jUNit 3.8) ist die Frage eigentlich simpel gelöst.. wenn man denn weiß, wie

Als erstes müssen alle TestCase-Klassen (d.h. hier die Klasse MyTests, die @Test-Methoden enthält) eine neue Methode erhalten:

public static junit.framework.Test suite() {
return new JUnit4TestAdapter(MyTests.class);
}

Damit erkennt der Wizard für eine TestSuite nun auch jene Klassen.

Falls man es lieber manuell machen möchte (Beispiel): suite.addTest(MyTests.suite());f

Es ist übrigens kein Problem, TestSuites zu verschachteln – dafür einfach das Prozedere “wiederholen” bzw. suite.addTest(MyOtherSuite.suite()) schreiben. Tipp: Es gibt die äußerst hilfreiche Methode suite.setName(string) – damit man sich in der jUnit-Baumansicht nicht verwirrt.

Nachtrag:

Wesentlich eleganter ist natürlich der Annotation-Weg. Die “SuperTestSuite” braucht “nur” so auszusehen:

@RunWith(Suite.class)
@SuiteClasses( { MySuite1.class, MySuite2.class, MySuite3.class })

public class AllTests {
}