everflux » Java

Confluence 4 mit JDK 7

everflux — Sun, 23 Oct 2011 21:41:09 +0000

Atlassian ist mit Confluence der Marktführer was Enterprise-Wiki-Software angeht. Bisher wird jedoch lediglich Java 6 offiziell supported, was schade ist, denn mit Java 7 hat die JVM eine Menge Updates bekommen und benötigt erheblich weniger Speicher im Betrieb und Last und auch im Bereitschaftszustand.
Mit dem offiziellen Release von Confluence 4 und Java 7 ist es nunmehr auch an der Zeit beides zu vereinigen. Leider lief das ganze nicht so ganz problemlos, nach dem Umstellen des JDK gab es eine Menge Fehlermeldungen im Confluence Logfile und auch die Darstellung war offensichtlich defekt.
Die Loesung sah schliesslich so aus:

Zum einen der OSGi Laufzeitumgebung von Confluence mitteilen, welche Klassen ueber den Tomcat Classloader geladen werden sollen -Datlassian.org.osgi.framework.bootdelegation=META-INF.services,com.yourkit,com.yourkit.*,com.jprofiler,com.jprofiler.*,org.apache.xerces,org.apache.xerces.*,org.apache.xalan,org.apache.xalan.*,sun.*,com.sun.jndi.,com.icl.saxon,com.icl.saxon.*,javax.servlet,javax.servlet.*,com.sun.xml.bind.*
Zum anderen einmal im Confluence Homeverzeichnis den OSGi Cache leeren cd $confluence-home/plugins-osgi-cache rm -r *

Beim nächsten Start funktioniert Confluence sogar mit dem aktuellen Tomcat 7 – verbraucht weniger RAM und ist subjektiv auch noch schneller.

Artikel von: everflux.de

Confluence 4 mit JDK 7

Ähnliche Beiträge:

Ubuntu Oneiric: Netbeans Master-Passwort / Keyring Integration

everflux — Fri, 14 Oct 2011 08:40:31 +0000

Schon in frühen Beta Versionen von Ubuntu 11.04 / Oneiric hat Netbeans mich ständig nach einem “Master Password” gefragt, mit dem gespeicherte Passwörter von Netbeans gegen unbefugten Zugriff verschlüsselt werden.

Das ist nervig, denn bisher ging es auch ohne – dabei nutzt Netbeans die von modernen Betriebssystemen bereitgestellte native Infrastruktur um Passwörter zu speichern. (z.B. Keychain auf dem Mac, Gnome-Keyring o.ä.) Normalerweise funktioniert das auch – aber seit Gnome 3 hat sich da offenbar etwas geändert.

Debuggen kann man die Netbeans Keyring Integration indem man folgende Option in der etc/netbeans.conf zu den netbeans_default_options ergaenzt:
-J-Dorg.netbeans.modules.keyring.level=0

Anschließend sieht man in ~/.netbeans/7.0/var/log/messages
FINE [org.netbeans.modules.keyring.kde.KWalletProvider]: application exit with code 2 for commandString: [qdbus, org.kde.kwalletd, /modules/kwalletd, org.kde.KWallet.isEnabled]; errVal: Service 'org.kde.kwalletd' does not exist. FINE [org.netbeans.modules.keyring.gnome.GnomeProvider] java.lang.UnsatisfiedLinkError: Unable to load library 'gnome-keyring': libgnome-keyring.so: cannot open shared object file: No such file or directory at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:163) at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:236) at com.sun.jna.Library$Handler.(Library.java:140) at com.sun.jna.Native.loadLibrary(Native.java:379) at org.netbeans.modules.keyring.gnome.GnomeKeyringLibrary.(GnomeKeyringLibrary.java:62) [catch] at org.netbeans.modules.keyring.gnome.GnomeProvider.enabled(GnomeProvider.java:88) at org.netbeans.api.keyring.Keyring.provider(Keyring.java:72) at org.netbeans.api.keyring.Keyring.save(Keyring.java:109) at org.netbeans.modules.j2ee.deployment.impl.ServerRegistry$5.run(ServerRegistry.java:731) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1424) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:1968)
Nachdem ich sichergestellt habe, dass die Library installiert ist:
sudo apt-get install libgnome-keyring0 Reading package lists... Done Building dependency tree Reading state information... Done libgnome-keyring0 is already the newest version.
bleibt die Frage: Wieso findet Netbeans die gesuchte Library nicht? Die Lösung: Die Gnome Keyring Library ist nur noch mit einem anderen Dateinamen verfügbar, mit angehängter “0″. Das gab es zwar früher schon immer, dass die Libraries ohne Versionsnummer (oder was das ist) lediglich ein Symlink auf die “echte” Library waren, aber immerhin gab es die. (Da gibt es bestimmt einen guten Grund und viel Logik für, dass das abgeschafft wurde – mir erschließt sich das jedoch nicht.)
Der simple Work-Around ist daher:
sudo ln -s /usr/lib/libgnome-keyring.so.0 /usr/lib/libgnome-keyring.so
und danach funktioniert Netbeans wieder tadellos. Also gab es offenbar keine inkompatiblen API Änderungen, sondern “lediglich” eine Änderung des Library-Namens. Ob das ein Ubuntu/Debian Paketierungsproblem ist, oder ab Gnome 3 einfach die neue Marschrichtung, kann ich nicht sagen.

Update: Ich hab dazu ein Bug im Netbeans Issuetracker aufgemacht. Wer voten möchte – gerne: http://netbeans.org/bugzilla/show_bug.cgi?id=203735

Artikel von: everflux.de

Ubuntu Oneiric: Netbeans Master-Passwort / Keyring Integration

Ähnliche Beiträge:

Java Benchmarking mit Caliper, Maven und Java 7

everflux — Tue, 23 Aug 2011 11:12:49 +0000

Bei Caliper handelt es sich um ein Framework um Mikrobenchmarks für Java Programme durchzuführen. Caliper ist bei Google code gehostet – http://code.google.com/p/caliper/ – und steht unter der Apache 2 Lizenz, kann somit sehr frei verwendet werden.

Caliper verfolgt einen ähnlichen Ansatz wie JUnit, Methoden müssen mit “time” als Prefix benannt werden, und einen Parameter vom Typ int entgegennehmen um dann ausgeführt zu werden. Dieser Parameter gibt an, wie viele Iterationen der zu messenden Methode durchzuführen sind.

Leider ist Caliper bisher noch nicht in einer Version 1.0 released worden, daher bleibt nur selber bauen. Derzeit ist das jedoch auch nicht ganz einfach: Caliper haengt von Google Guava ab, nutzt in der svn-trunk Version dazu auch bereits Features von Guava r10, was auch noch nicht released ist. Also auch hier: Selber bauen, und die Abhängigkeit in Caliper korrigieren. Mein favorisiertes Build Tool ist in diesem Fall maven.

Möchte man noch während des Benchmarks die Speichernutzung analysieren, so bietet Caliper dies auch an – über einen Java Agent der von dem Google Projekt java-allocation-instrumenter (http://code.google.com/p/java-allocation-instrumenter/, Apache 2 Lizenz) bereitgestellt wird. (Leider ist hier derzeit der Maven Build nicht so konfiguriert, dass als Artefakt ein nutzbarer Java Agent erzeugt wird. Dies ist im Ant basierten Build in Ordnung, und kann mit einem kleinen Patch der Maven Konfiguration auch behoben werden.)

Der letzte Wehrmutstropfen bleibt nun, dass Caliper gerne eine Environment Variable, statt bspw. einem System Property, hätte, um den zu nutzenden Java-Agent zu spezifizieren – diese lässt sich bei Ausführung als Script zwar einfach setzten, jedoch aus einer Java Anwendung heraus eigentlich nicht. Dazu später mehr.)

Nach dem groben Überblick nun die Schritte im einzelnen:
Caliper per SVN auschecken:
svn checkout http://caliper.googlecode.com/svn/trunk/ caliper
Danach ändert man die pom.xml folgendermassen ab:

--- caliper/pom.xml    (revision 330)
+++ caliper/pom.xml    (working copy)
@@ -46,13 +46,13 @@
    
       com.google.guava
       guava
-      r08
+      r10-SNAPSHOT
       compile
     
     
       com.google.code.java-allocation-instrumenter
       java-allocation-instrumenter
-      2.0
+      2.1-SNAPSHOT

Wie zu sehen ist, werden damit die Abhängigkeiten auf die (gleich ebenfalls noch zu erstellenden) lokalen Bibliotheken umgestellt.

Nun wird Guava lokal gebaut, um die aktuelle Version zur Verfuegung zu stellen. (-SNAPSHOT Artefakte werden nicht vom Maven “Central” Repository angeboten, darum erstellen wir diese lokale selber.)
git clone https://code.google.com/p/guava-libraries/ cd guava-libraries mvn clean install
Das war schmerzlos.
Nun kommen wir noch zu dem java-allocation-instrumenter. Dieser ist in Version 2.0 released und auch über Maven Central verfügbar. Möchte man dies nicht selber bauen, kann man auch das Manifest in der Jar Datei patchen, ich hab mich jedoch für einen Patch der Maven Konfiguration und anschließendes neubauen entschieden.svn checkout http://java-allocation-instrumenter.googlecode.com/svn/trunk/ java-allocation-instrumenter
Danach wird die pom.xml folgendermassen geaendert:

--- java-allocation-instrumenter/pom.xml    (revision 17)
+++ java-allocation-instrumenter/pom.xml    (working copy)
@@ -83,6 +83,24 @@

package

+        
+            org.apache.maven.plugins
+            maven-jar-plugin
+            2.3.1
+            
+                
+                    true
+                    
+                        true
+                    
+                    
+                        
com.google.monitoring.runtime.instrumentation.AllocationInstrumenter

+                        true
+                        NotSuitableAsMain
+                    
+                
+            
+

Fehlt dieser Eintrag, so schlaegt die Nutzung als Java-Agent fehlt, und man erhaelt so eine Meldung:Failed to find Premain-Class manifest attribute from ... Error occurred during initialization of VM agent library failed to init: instrument
und das Programm bricht ab.
Nach dem Patchen wird nun das java-allocation-instrument auch übersetzt: “mvn clean install“. Nun kann auch caliper uebersetzt werden, auch hier kommt der bekannte Maven Aufruf zum Einsatz.
Nun gilt es noch eine kleine Hürde im Zusammenhang mit Java 7 zu umschiffen: Nutzt man die Instrumentierung um Informationen über die Speichernutzung während des Benchmarks zu sammeln, so bricht die JVM die Ausführung mit der Meldung
Exception in thread "main" java.lang.VerifyError: Expecting a stackmap frame at branch target 32 in method com.google.caliper.InProcessRunner.main([Ljava/lang/String;)V at offset 0
ab. Der Fehler ist im Zusammenhang mit Java 7 und der verwendeten ASM Library zur Instrumentierung bekannt und sollte eigentlich bereits mit ASM 3.3.1 behoben sein. Als Workaround kann die Verifizierung der JVM deaktiviert werden, "-XX:-UseSplitVerifier" ist die dazu nötige JVM Option.
Im Folgenden habe zwei Mini-Klassen, die die Verwendung von Caliper demonstrieren.
Zuerst die Benchmark Klasse, hier werden verschiedene Sortieralgorithmen gegeneinander getestet. (Die Implementierung überlasse ich dem geneigten Leser, lediglich Arrays.sort kommt direkt aus der Java Klassenbibliothek)

public class BenchmarkDemo extends SimpleBenchmark
{
    @Param int size; //injected by caliper with -Dsize=1,2
    private int[] values;

    @Override
    protected void setUp() throws Exception
    {
        values = new int[size];
        Random generator = new Random();
        for (int i = 0; i < values.length; i++)
        {
            values[i] = generator.nextInt(Integer.MAX_VALUE);
        }
    }

    public void timeHeapSort(int reps)
    {
        for (int i = 0; i < reps; i++)
        {
            HeapSort.sort(values);
        }
    }

    public void timeMergeSort(int reps)
    {
        for (int i = 0; i < reps; i++)
        {
            MergeSort.sort(values);
        }
    }

    public void timeQuickSort(int reps)
    {
        for (int i = 0; i < reps; i++)
        {
            QuickSort.sort(values);
        }
    }

    public void timeArraysSort(int reps)
    {
        for (int i = 0; i < reps; i++)
        {
            Arrays.sort(values);
        }
    }
}

Da ich gerne aus der IDE (Netbeans in meinem Fall) heraus Caliper programmatisch starten möchte, habe ich eine Klasse erstellt, die sich darum kümmert.
Etwas kompliziert war an der Stelle, dass der Java-Agent nicht über ein System Property gesetzt werden kann, sondern lediglich per Environment-Variable. Diese sind in Java eigentlich nicht änderbar, mit etwas Reflection klappte es jedoch bei mir. (Robust ist das sicherlich nicht.) Auch verlasse ich mich an der Stelle darauf, dass der Agent per Maven im Standardpfad für Artefakte im lokalen Repository zur Verfügung steht. (Alternativ kann man per Environment-Variable den richtigen Pfad zum Agent weisen.)

package de.trion.caliperdemo;

import java.lang.reflect.Field;
import java.util.Collections;
import java.util.HashMap;
import java.util.Map;

public class BenchmarkRunner
{
    public static void main(String[] args) throws Exception
    {
        //runBenchmark();
        runBenchmarkWithMemoryInstrumentation();
    }

    private static void runBenchmark()
    {
        com.google.caliper.Runner.main("-Dsize=100,1000,10000,100000",
                "--trials", "20", "de.trion.caliperdemo.BenchmarkDemo");
    }

    private static void runBenchmarkWithMemoryInstrumentation() throws Exception
    {
        if (System.getenv("ALLOCATION_JAR") == null)
        {
            Map environment = new HashMap(System.getenv());
            //you might want to replace this or setup an environment entry correctly
            String allocationAgent =
             "/.m2/repository/com/google/code/java-allocation-instrumenter"+
             "/java-allocation-instrumenter/2.1-SNAPSHOT/java-allocation-instrumenter-2.1-SNAPSHOT.jar";
            environment.put("ALLOCATION_JAR", System.getProperty("user.home") + allocationAgent);
            setEnvironmentHackOld(environment);
        }

        //JDK 7 instrumentation issue: -XX:-UseSplitVerifier
        com.google.caliper.Runner.main("-JjdkSevenFix=-XX:-UseSplitVerifier",
                "-Dsize=100,1000,10000,100000", "--trials", "20",
                "--measureMemory", "de.trion.caliperdemo.BenchmarkDemo");
    }

    public static void setEnvironmentHackOld(Map newenv) throws Exception
    {
        Class[] classes = Collections.class.getDeclaredClasses();
        Map env = System.getenv();
        for (Class cl : classes)
        {
            if ("java.util.Collections$UnmodifiableMap".equals(cl.getName()))
            {
                Field field = cl.getDeclaredField("m");
                field.setAccessible(true);
                Object obj = field.get(env);

                @SuppressWarnings("unchecked")
                Map map = (Map) obj;
                map.clear();
                map.putAll(newenv);
            }
        }
    }
}

Wie man gut sehen kann, kann Caliper System-Properties, wie in diesem Fall "size", verwenden um einen Benchmark zu parametrisieren. Das Pendant dazu findet sich im Quellcode:

@Param int size;

Auch können mehrere Parameter als Liste definiert werden und damit lässt sich in diesem Fall schön sehen, wie sich die verschiedenen Sortierverfahren bei steigender Größe verhalten.
Die Nummer der Durchführungen (trials) dient dazu, einen gemittelten Wert zu erhalten um temporäre Effekte mit Einfluss auf den Benchmark zu verringern.
Natürlich lässt sich caliper äquivalent auch durch ein Script oder von der Kommandozeile aus aufrufen, weitere Hinweise und Tutorials finden sich auf der Homepage - und einiges lediglich im Caliper Quellcode.

Artikel von: everflux.de

Java Benchmarking mit Caliper, Maven und Java 7

Ähnliche Beiträge:

Drools und Java 7

everflux — Sat, 30 Jul 2011 11:46:49 +0000

Drools (und JBoss Rules) funktioniert derzeit (Drools 5.2) nicht out-of-the-box mit Java 7 (OpenJDK bzw. Oracle Java 7). Der Grund ist, dass der von Drools verwendete Compiler lediglich Support bis Java 6 hat.

Eine einfache Loesung, die auch mit Java 7 funktioniert, ist die zu verwendende Java Version manuell zu konfigurieren, wenn man die KnowledgeBuilderFactory konfiguriert:
final Properties props = new Properties(); props.setProperty("drools.dialect.java.compiler.lnglevel", "1.6"); final KnowledgeBuilderConfiguration configuration = KnowledgeBuilderFactory.newKnowledgeBuilderConfiguration(props, getClass().getClassLoader());
Weitere Probleme mit Java 7 und JBoss Drools sind mir bisher nicht aufgefallen.

Artikel von: everflux.de

Drools und Java 7

Ähnliche Beiträge:

Jenkins, Java: java.net.SocketTimeoutException: Accept timed out

everflux — Mon, 25 Jul 2011 21:05:00 +0000

Lange gesucht, doch gefunden:
ERROR: Aborted Maven execution for InterruptedIOException java.net.SocketTimeoutException: Accept timed out

Jenkins (bzw. Hudson) bricht dann mit dieser Fehlermeldung den Build Prozess ab:

java.net.SocketTimeoutException: Accept timed out
	at java.net.PlainSocketImpl.socketAccept(Native Method)
	at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:408)
	at java.net.ServerSocket.implAccept(ServerSocket.java:462)
	at java.net.ServerSocket.accept(ServerSocket.java:430)
	at hudson.maven.AbstractMavenProcessFactory$SocketHandler$AcceptorImpl.accept(AbstractMavenProcessFactory.java:167)
	at hudson.maven.AbstractMavenProcessFactory.newProcess(AbstractMavenProcessFactory.java:221)
	at hudson.maven.ProcessCache.get(ProcessCache.java:231)
	at hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:668)
	at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:429)
	at hudson.model.Run.run(Run.java:1374)
	at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:467)
	at hudson.model.ResourceController.execute(ResourceController.java:88)
	at hudson.model.Executor.run(Executor.java:145)
Finished: ABORTED

Beheben über advanced und dort in die MAVEN_OPTS hinzufügen:
-Djava.net.preferIPv4Stack=true
Anschließend sollte der Build wieder korrekt funktionieren. Alternativ kann man dies auch als globale Environment Variable setzen, das Problem wird mehrere Java Anwendungen betreffen und nicht nur den CI Server.

Artikel von: everflux.de

Jenkins, Java: java.net.SocketTimeoutException: Accept timed out

Ähnliche Beiträge:

SSL Problem mit Java 7

everflux — Mon, 25 Jul 2011 18:54:56 +0000

Nachdem ich (wie im vorherigen Artikel beschrieben) nun OpenJDK / Java 7 selber kompiliert habe, habe ich mich auf die Suche nach dem SSL Problem gemacht, dass ich mit Jameica/Hibiskus habe. (No offense, ich find es leichter OpenJDK zu übersetzen oder anzupassen als Jameica und Hibiskus zu bauen… praktischerweise bringt OpenJDK auch Netbeans Projektdateien mit, so dass es ein Klacks ist, das Projekt mit Netbeans zu verwenden.)

Nachdem ich folgenden Patch geschrieben habe habe:

diff -r 9b8c96f96a0f src/share/classes/sun/security/ssl/SSLContextImpl.java
--- a/src/share/classes/sun/security/ssl/SSLContextImpl.java	Mon Jun 27 13:21:34 2011 -0700
+++ b/src/share/classes/sun/security/ssl/SSLContextImpl.java	Mon Jul 25 19:30:11 2011 +0200
@@ -871,7 +871,7 @@
                 }
             } catch (CertPathValidatorException cpve) {
                 throw new CertificateException(
-                    "Certificates does not conform to algorithm constraints");
+                    "Certificates does not conform to algorithm constraints", cpve);
             }
         }
     }

ist jetzt auch zu sehen, was die Ursache fuer den SSL Fehler ist:

Caused by: java.security.cert.CertPathValidatorException: Algorithm constraints check failed: MD2withRSA
	at sun.security.provider.certpath.AlgorithmChecker.check(AlgorithmChecker.java:200)
	at sun.security.ssl.AbstractTrustManagerWrapper.checkAdditionalTrust(SSLContextImpl.java:870)
	... 21 more org.kapott.hbci.manager.HBCIUtils.log(HBCIUtils.java:1052)

OpenJDK kommt übrigens ohne Root Zertifikate daher, so dass man sich nicht über einen solchen Dialog wundern sollte:

Nachdem man die Exception genauer ansieht, ist man auch etwas schlauer geworden: Irgendein Zertifikat ist mit einem nicht mehr als sicher geltenden Algorithmus signiert. Das der Apobank selbst ist es offensichtlich jedoch nicht, also muss die gesamte Zertifikatskette untersucht werden.
Hier habe ich etwas Shell-Magie und das OpenSSL Kommandozeilentool verwendet:
openssl s_client -showcerts -connect hbcibanking.apobank.de:443 < /dev/null | awk -v c=-1 '/-----BEGIN CERTIFICATE-----/{inc=1;c++} inc {print > ("cert-" c ".pem")}/---END CERTIFICATE-----/{inc=0}'; for i in cert-?.pem; do openssl x509 -noout -serial -subject -issuer -in "$i"; done
Danach finden sich alle Zertifikate in cert-1.pem, cert-2.pem usw., die Ausgabe der Seriennummern, Subject und Issuer sah bei mir so aus:
serial=4FCD4C50631D3BB4C747A319E816AD5D subject= /C=DE/ST=NRW/L=Duesseldorf/O=Deutsche Apotheker- und Aerztebank/OU=Terms of use at www.verisign.com/rpa (c)05/CN=hbcibanking.apobank.de issuer= /O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign serial=254B8A853842CCE358F8C5DDAE226EA4 subject= /O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign issuer= /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority serial=70BAE41D10D92934B638CA7B03CCBABF subject= /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority issuer= /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
Nun müssen alle Zertifikate untersucht werden:
openssl x509 -text -in cert-0.pem
Und entsprechend für die anderen Zertifikate in der Kette. Ich wurde dann bei dem dritten Zertifikat fündig:
tkruse@charix:~$ openssl x509 -text -in cert-2.pem Certificate: Data: Version: 1 (0x0) Serial Number: 70:ba:e4:1d:10:d9:29:34:b6:38:ca:7b:03:cc:ba:bf Signature Algorithm: md2WithRSAEncryption Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority Validity Not Before: Jan 29 00:00:00 1996 GMT Not After : Aug 1 23:59:59 2028 GMT Subject: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority
Ein “betagtes” altes VeriSign Zertifikat das mit MD2 und RSA signiert wurde. Auch wenn der MD2 Signaturalgorithmus noch nicht gebrochen ist, gibt es einige Angriffe, die dazu geführt haben, dass MD2 seit 2009 nicht mehr in OpenSSL verwendet wird.
Was heißt das nun für das konkrete SSL Problem? Die ApoBank wird sich eh um Januar 2012 herum spätestens ein neues SSL Zertifikat besorgen. Dann sollte der Spuk zu ende sein. Besser wäre es allerdings wenn die betroffenen Anbieter ihre SSL Zertifikate jetzt erneuern – es geht schließlich um Online Banking!
Und wieso fällt das erst seit Java 7 auf? Seit Java 7 ist offenbar die Möglichkeit neu hinzugekommen die Algorithmen zu prüfen oder wurde geändert. Eigentlich sollte seit Java 6u17 bereits MD2 nicht mehr unterstützt werden, zumindest gibt es einen entsprechenden Eintrag in den Release notes: http://www.oracle.com/technetwork/java/javase/6u17-141447.html.

Artikel von: everflux.de

SSL Problem mit Java 7

Ähnliche Beiträge:

OpenJDK – Java 7 – mit Ubuntu kompilieren

everflux — Sun, 24 Jul 2011 20:28:36 +0000

Ich habe ein merkwuerdiges SSL Problem mit Java 7 (Build 147, dem Release Candidate) im Zusammenhang mit Online-Banking und Jameica/Hibiskus:

Caused by: java.security.cert.CertificateException: Certificates does not conform to algorithm constraints
 at sun.security.ssl.AbstractTrustManagerWrapper.checkAdditionalTrust(SSLContextImpl.java:873)
 at sun.security.ssl.AbstractTrustManagerWrapper.checkServerTrusted(SSLContextImpl.java:804)
 at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1319)
 ... 19 more

Schaut man sich dazu den Source Code an, sieht man schnell, dass leider die verursachende Exception verschluckt wird. (Das kommt davon, wenn Committer und Reviewer identisch sind…)
Meine Idee war also, OpenJDK selber zu bauen und da ggf. besseres Logging einzubauen. Die im Internet veröffentlichten Anleitungen sind alle ein paar Jahre alt und nicht mehr ganz korrekt, daher hier meine Ergebnisse zum Nachmachen.
Ich habe Ubuntu als System verwendet, dort ist eine Übersetzung von OpenJDK / Java 7 sehr einfach.
OpenJDK wird mittels Mercurial verwaltet, zur Hierarchiebildung wird die Mercurial Forest extension benötigt (und Mercurial). Ist das “mercurial” Paket bereits installiert so kann man die Forest extension einfach herunterladen:

hg clone http://bitbucket.org/pmezard/hgforest-crew hgforest

Diese muss nun in die .hgrc eingetragen werden: (das “….” durch den Pfad zum Download ersetzen)

[extensions]
forest=......hgforest/forest.py
fetch=

Danach installiert man die Build Abhängigkeiten:

sudo apt-get install build-essential gawk libasound2-dev libfreetype6-dev libcups2-dev libxt-dev libx11-dev libxtst-dev libxrender-dev

Und checkt per mercurial-forest die Sourcen fuer OpenJDK aus:

hg fclone http://hg.openjdk.java.net/jdk7/jdk7 jdk7

Da beim späteren Build noch Java Abhängigkeiten heruntergeladen werden müssen, hab ich noch folgendens in die Ant Konfiguration eingesetzt: ~/.antrc

ANT_OPTS=”$ANT_OPTS -Dallow.downloads=true”

Für den build benötigt man ein existierendes Java, und setzt folgenden Umgebungsvariablen:

export ALT_BOOTDIR=/usr/lib/jvm/java-6-sun
unset JAVA_HOME
export LANG="C"
make sanity

Da sollten keine Fehler zu sehen sein und gibt dann den “make” Befehl (dauert bei mir rund 40 Minuten):

make

Und kann es dann aus dem aktuellen Verzeichnis testen ob “java” vorhanden ist:

build/linux-amd64/bin/java -version

Bei mir sieht das dann folgendermassen aus:

openjdk version "1.7.0-internal"
OpenJDK Runtime Environment (build 1.7.0-internal-tkruse-b00)
OpenJDK 64-Bit Server VM (build 21.0-b17, mixed mode)

Fertig.
(Ja man benötigt wirklich keine “binary plugs” o.a”. mehr!)

Artikel von: everflux.de

OpenJDK – Java 7 – mit Ubuntu kompilieren

Ähnliche Beiträge:

DKB Kreditkarte: Kontoabfrage mit Hibiscus/Jameica

everflux — Fri, 27 May 2011 13:13:07 +0000

Hibiscus ist ein Plugin für Jameica – zusammen ergibt sich daraus ein Homebanking Programm das auf verschiedenen Betriebssystemen läuft (überall wo Java verfügbar ist), die Software kann hier heruntergeladen werden.

Die normale Abfrage von Konten erfolgt über HBCI – dies Protokoll wird jedoch leider nicht von jeder Bank bzw. jedem Finanzdienstleister für alle Produkte unterstützt. So ist Paypal z.B. nicht per HBCI abfragbar, und auch die recht populären DKB Kreditkarten Konten nicht.

In neuen Versionen unterstützt Jameica auch Scripting und sogenannte Offline-Konten. Das sind Konten, die nicht per HBCI abgefragt werden, sondern von Hand gepflegt werden. (Z.B. kann man so ein “Bar Kasse” Konto führen.) Mittels Scripting – und dem richtigen Script – lassen sich so nun auch Paypal und die DKB Kreditkartenkonten abfragen. Dazu laedt man sich lediglich die neueste Jameica Version herunter und installiert das Hibiscus Plugin.

Anschließend muss man noch das jameica.scripting Plugin, HTMLUnit (wird zum Screen-Scraping der DKB und Paypal Webseiten verwendet) und die Scripte für Paypal und/oder DKB installieren – dafür gibt es zum Glück ein einzelnes Archiv, welches man hier herunterladen kann.

Das Archiv entpackt man – genauso wie das Hibiscus Plugin für Jameica – in den Plugins Ordner.

Nach dem Start von Jameica hat man unter “Datei->Einstellungen” den Punkt “Scripting”, wo man Paypal und/oder das DKB Script aktivieren kann.

Für die DKB Kreditkarte erstellt man nun ein Offline Konto – als Bankleitzahl nimmt man die der DKB (12030000), als Kontonummer verwendet man die eigene Kontonummer und als Kundennummer verwendet man die Nummer der Kreditkarte. Hier kann man die mittleren Stellen der Nummer durch “*” ersetzen – lediglich die ersten und letzten vier Ziffern der Kreditkartennummer müssen richtig angegeben sein.

Um Doppelbuchungen zu vermeiden, sollte unter “erweitert” noch das automatische Gegenbuchen ausgeschaltet werden.

Das Konto kann anschließend über den Knopf “per Scripting synchronisieren” abgefragt werden. (Leider nicht zentral mit den anderen HBCI Konten – aber immerhin.)

Artikel von: everflux.de

DKB Kreditkarte: Kontoabfrage mit Hibiscus/Jameica

Ähnliche Beiträge:

Hamcrest, Junit: NoSuchMethodError zur Test Laufzeit

everflux — Sat, 19 Mar 2011 15:00:49 +0000

JUnit 4 bringt die (bessere) Syntax von assertThat über Hamcrest Matcher mit. Und nicht nur die Syntax ist besser, es gibt für viele Testfälle bereits “Matcher”, die das Leben erleichtern können.
Genauso kann einem das Leben aber auch erschwert werden: JUnit bringt eben nur ein Subset der Hamcrest Funktionalität mit. Den Rest kann man über die entsprechenden Hamcrest Bibliotheken hinzufügen. Und genau da gilt es nun aufzupassen: JUnit bringt eben bestimmte Versionen der Bilbiotheken mit – und dann kann es zu Konflikten kommen, die sich zur Test-Laufzeit erst zeigen:
org.hamcrest.core.AnyOf.anyOf([Lorg/hamcrest/Matcher;)Lorg/hamcrest/core/AnyOf; java.lang.NoSuchMethodError: org.hamcrest.core.AnyOf.anyOf([Lorg/hamcrest/Matcher;)Lorg/hamcrest/core/AnyOf; at org.hamcrest.text.IsEmptyString.(IsEmptyString.java:18)
Die Lösung ist dann JUnit ohne eigene Versionen von Hamcrest etc. zu verwenden (die “no-dependencies” Version), und entsprechend die Abhängigkeiten selber aufzulösen.

Mit Maven sieht dann der Einsatz von JUnit, Mockito und Hamcrest z.B. folgendermaßen aus:



  junit
  junit-dep
  4.8.2
  test


  org.mockito
  mockito-core
  1.8.5
  test


  org.hamcrest
  hamcrest-core
  1.2.1
  test


  org.hamcrest
  hamcrest-library
  1.2.1
  test

Artikel von: everflux.de

Hamcrest, Junit: NoSuchMethodError zur Test Laufzeit

Ähnliche Beiträge:

Glassfish 3.1 und httpOnly Session Cookie

everflux — Fri, 04 Mar 2011 13:48:37 +0000

Wie bereits in meinem anderen Eintrag zu Glassfish 3.1 beschrieben, ist seit der Implementierung der Servlet 3.0 Spezifikation in Glassfish 3.1 der Session Cookie standardmäßig auf “httpOnly” gesetzt – dies kann Probleme mit einigen JavaScript Frameworks verursachen.

In dem web.xml Deploymentdescriptor kann dies umkonfiguriert werden, im glassfish-web.xml Descriptor ist dafür leider keine Möglichkeit vorgesehen. Weblogic, auch von Oracle mit BEA zugekauft, verhält sich dabei genauso, auch hier ist der Session Cookie auf httpOnly gesetzt – kann jedoch über den Weblogic spezifischen Deployment Descriptor unabhängig von der web.xml umkonfiguriert werden.

Und Glassfish 3.1 unterstützt nun auch ein Subset des Weblogic Deployment Descriptors um Weblogic kompatibel zu sein. (Vermutlich ist dies auch ein Grund, aus dem die Cookies httpOnly sind, um mit Weblogic konform zu sein.) Auch wenn es komisch ist, dass Glassfish selber keine Möglichkeit vorsieht das Verhalten im eigenen Deployment Deskriptor zu konfigurieren – über den Umweg des Weblogic spezifischen Descriptors geht es dann:
false

Artikel von: everflux.de

Glassfish 3.1 und httpOnly Session Cookie

Ähnliche Beiträge:

Glassfish 3.1: Probleme mit DWR 2 (und mehr)

everflux — Mon, 28 Feb 2011 19:32:07 +0000

Oracle hat heute den Glassfish 3.1 freigegeben – gleichzeitig als Open Source und als Oracle Glassfish Edition. Es gibt eine Menge neues, und dazu gehören auch neue Probleme.

Ich verwende Glassfish schon seit geraumer Zeit um mittels “Continuous Deployment” für aktuell entwickelte Anwendungen eine separate Umgebung zu haben, in der ich und Kollegen testen können. Das ganze funktioniert mittels eine CI-Servers (~~Hudson~~ Jenkins in diesem Fall), Maven und einem Deploy Plugin.

Auch mit Glassfish 3.1 funktionierte das Deployment prima – also hier war kein Update von Jenkins oder dem Deploy Plugin erforderlich. Auch die Anwendung startete – jedoch funktionierte nichts. Exceptions über ungültige Sessions gab es, auch Log-Einträge vom hier für Ajax eingesetzten DWR (Direct Web Remoting)
2011-02-28 18:57:13,037 [http-thread-pool-8090(2)] ERROR o.d.dwrp.Batch - A request has been denied as a potential CSRF attack. 2011-02-28 19:03:02,105 [http-thread-pool-8090(5)] ERROR o.d.dwrp.Batch - A request has been denied as a potential CSRF attack.
Dank Firebug etwas schlauem Rumraten und Probieren fand ich dann heraus: Glassfish 3.1 setzt Session Cookies per Default auf “HTTP Only”. Dazu gibt es bereits ein Ticket im Glassfish Tracker: GLASSFISH-15730

Es gibt nun mehrere Möglichkeiten für die nötige Kompatibilität mit Bestandsanwendungen zu sorgen:

Wird man die Anwendung zukünftig immer in einem Servlet 3.0 kompatiblen Container deployen, so kann man in der web.xml das Verhalten umkonfigurieren:


  
    
      true

Alternativ kann man bei DWR den CSRF Check deaktivieren, wovon ich jedoch abraten würde:


  dwr-invoker
  org.directwebremoting.servlet.DwrServlet
  
    crossDomainSessionSecurity
    false

Die letzte Möglichkeit ist – in diesem Fall – auf DWR 3 umzustellen, hier wurde das Problem grundsätzlich gelöst, so dass nicht mehr per JavaScript auf den Session Cookie zugegriffen werden muss. (Siehe DWR-26) Leider gibt es von DWR 3 bisher noch kein Release, sondern lediglich vorab-Versionen.

Das Problem tritt übrigens auch mit Tomcat 7 auf, und nicht nur mit Glassfish 3.1 – ich frage mich, ob dies Verhalten am Ende sogar in der Servlet 3 Spezifikation vorgegeben ist.
Natürlich betrifft dies nicht ausschließlich DWR, sondern auch andere Anwendungen, die per JavaScript auf den Session Cookie zugreifen wollen/müssen.

Artikel von: everflux.de

Glassfish 3.1: Probleme mit DWR 2 (und mehr)

Ähnliche Beiträge:

Jetty org.eclipse.jetty.io.EofException / Connection closed

everflux — Thu, 17 Feb 2011 13:27:52 +0000

Bei der Umstellung von Jetty 6 zu Jetty 7 gab es (wie bereits geschildert) das eine oder andere an Überraschungsmomenten. So auch bei einem länger laufenden Request ( Fileupload anschließendes Parsen und Datenbank Updates die sich einige Minuten hinziehen können).

Die saubere Lösung wäre hier natürlich dem Nutzer eine Art Fortschritts-Anzeige zu präsentieren. Da die Funktion jedoch so bereits getestet ist, und auch kein Umbau geplant war, sollte es so bleiben. Lediglich Jetty hat hier (mal wieder) einen Strich durch die Rechnung gemacht: Geschlossene Verbindungen die mit org.eclipse.jetty.io.EofException und vielen hässlichen Stacktraces kommentiert wurden. Erst hatte ich die Applikation in Verdacht.

Dann den Browser – macht der Browser vielleicht die Verbindung zu, wird der Socket nur solange wie “keep-alive” erlaubt ist offen gehalten? Mit etwas wireshark / tcpdump konnte ich dann beweisen: Es war Jetty. Der Server schloss die Verbindung bevor der Prozess fertig war.

Zum Glück kann man aber den idle Timeout von Jetty konfigurieren, das ist die Zeit, in der eine Verbindung ohne Fortschritt fortbestehen darf. (Fortschritt wäre hier ein gesendetes oder empfangenes Byte.) Hier kann man noch gut in die Falle tappen, dass die Zeit in Milisekunden angegeben werden muss – lediglich der verdeckte Hinweis, dass der Wert “grob gesagt” in den Parameter für Socket.setSoTimeout(int) übersetzt wird, bringt einen hier auf die Spur.

Für das Jetty Maven Plugin sieht das dann so aus:
8080 600000 600000

Artikel von: everflux.de

Jetty org.eclipse.jetty.io.EofException / Connection closed

Ähnliche Beiträge:

Maven, Jetty und der ExtraClasspath

everflux — Fri, 28 Jan 2011 16:23:41 +0000

Es hat nur wenige Monate gedauert, aber dann konnte ich endlich einen besonders nervigen Fehler finden. Ich verwende Maven (wie fast immer) als Buildsystem und habe ein Projekt, dass Eclipse BIRT verwendet.
BIRT nutzt die Eclipse OSGi Plattform und daher werden beim Start einige Bilbiotheken benötigt. Nun gab es das Problem, dass dies im Tomcat nach einer kleinen Anpassung des Classpath prima funktionierte – nicht jedoch wenn ich das Maven Jetty Plugin verwendet habe. Trotz lt. Dokumentation korrekter Konfiguration über webAppConfig und extraClasspath Elemente.

Die Lösung war dann schließlich nicht mehr das maven-jetty-plugin in Version 6.1.2 sondern das – Achtung – jetty-maven-plugin in Version 7.2.1.v20101111 (die Versionnummer ist kein Witz) zu verwenden. Offenbar ein Jetty Bug – anders kann ich es mir nicht erklären.

Und so sieht dann die vollständige Konfiguration aus, die bei mir dann endlich auch zum Testen schnell und komfortabel funktioniert:


  org.mortbay.jetty
  jetty-maven-plugin
  7.2.1.v20101111
  
    
      ${BIRT_HOME}/lib/engineapi.jar;${BIRT_HOME}/lib/coreapi.jar; \
${BIRT_HOME}/lib/modelapi.jar;${BIRT_HOME}/lib/org.apache.commons.codec_1.3.0.v20100518-1140.jar; \
${BIRT_HOME}/lib/scriptapi.jar

Artikel von: everflux.de

Maven, Jetty und der ExtraClasspath

Ähnliche Beiträge:

Maven, Jetty und Reloads: Session persistieren

everflux — Sat, 22 Jan 2011 15:24:31 +0000

Entwickelt man mit Jetty als Servlet Container, so fällt der im Vergleich zu Glassfish relativ hohe Aufwand für Re-Deployments auf: Startet man Jetty per “mvn jetty:run” für jedes Deployment erneut, so dauert der Neustart erst mal relativ lange, dazu geht noch die gerade aktive Session verloren. So muss man sich gegebenenfalls nach jeder Änderung bzw. jedem Restart erneut anmelden.
Das kann man relativ einfach ändern: Jetty verfügt über die Möglichkeit die Session zu persistieren – dazu müssen natürlich Session Objekte serialisierbar sein, aber das sollten diese ja sowieso sein. (Stichwort “Session migration” und “Clustering”)
Leider findet sich auf der Jetty Homepage lediglich eine Anleitung für Jetty 6 – Jetty 7 wird nun von Eclipse weiter entwickelt und damit gehen einige Änderungen einher, für die ich hier eine Beispielkonfiguration habe:


org.mortbay.jetty
jetty-maven-plugin
7.2.1.v20101111

  
    
      
      ${basedir}/target/sessions/
    
  
/${project.artifactId}

Mit dieser Einstellung werden die Session Daten in dem Order “target/sessions” persistiert, und man kann bei einem Neustart dort weitermachen, wo man aufgehört hat.

Artikel von: everflux.de

Maven, Jetty und Reloads: Session persistieren

Ähnliche Beiträge:

Java Servlet (Spring Controller) auf Root Path mappen

everflux — Wed, 12 Jan 2011 17:18:12 +0000

Nicht immer genuegt es, wenn man ein Servlets auf andere Pfade oder Patterns mappt, manchmal möchte man bereits auf den Context Root ein Servlet mappen. Der übliche Work-Around sieht so aus, dass man bspw. in einer “index.jsp” einen redirect auf eine tatsächlich einem Servlet zugeordnete URL (über den Pfad oder Datei Extension) macht, das könnte so aussehen:
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
Das ist aber nicht immer praktikabel – nun soll es darum gehen ein Servlet direkt auf den “/” Pfad zu mappen – dafür gibt es mehrere Möglichkeiten:

Das Default Servlet ersetzen, dazu wird auf den Root Pfad “/” in der web.xml ein Mapping angelegt:myServlet /
Ab Servlet Spezifikation kann auch ein Servlet in der welcome-file-list in der web.xml gemappt werden:
myServlet index.html index.jsp

Im folgenden beschreibe ich die Vor- und Nachteile der verschiedenen Ansätze, und welche Erfahrungen ich mit verschiedenen Web Containern dabei gemacht habe.Das Default Servlet wird in der Regel zur Auslieferung von statischen Ressourcen (z.B. Bilder, CSS Dateien) und dem Directory Listing verwendet. Ersetzt man das Default Servlet des Web Containers nun durch ein eigenes, muss man sich ggf. selber um die zusätzlichen Aufgaben kümmern, oder die statischen Inhalte über einen anderen Pfad ausliefern, z.B. “static” und diesen auf das Default Servlet mappen:


    default
    /static/*

Da inzwischen wirklich überall Servlet 2.4 konforme Webcontainer im Einsatz sein dürften, ist der Web über ein Servlet als Welcome-File praktischer: Das vom Container bereitgestellte Default Servlet kommt weiterhin für die restlichen Ressourcen zum Einsatz, an der Struktur des Projektes muss nichts geändert werden. Die zugehörige Konfiguration in der web.xml für ein Spring Dispatcher Servlet könnte z.B. so aussehen:
Spring Dispatcher Servlet myServlet org.springframework.web.servlet.DispatcherServlet 1

myServlet
*.do

myServlet
index.html
index.jsp

Das funktioniert soweit in Tomcat und Glassfish auch – allerdings nicht in Jetty. Und Jetty verwende ich sehr gerne zum lokalen Testen, z.B. über das Jetty Maven Plugin. Zu dem Fehler von Jetty gibt es auch einen Bug in der Jetty Bug Datenbank (936), offenbar sind die Jetty Entwickler der Auffassung, dass die Spezifikation in diesem Punkt “stupid” sei, man weigert sich da auch in dem Codehaus Jetty 6.1.x das Defaultverhalten der Spezifikation gemäss anzupassen.
Um das Verhalten zu korrigieren, muss man das Jetty Default Servlet anders konfigurieren – damit bekommt das Projekt eine Jetty Abhängigkeit, die in meinen Augen nicht gewünscht ist, vor allem nicht, wenn Jetty lediglich zur Entwicklung eingesetzt wird.

Jetty ist nun zu Eclipse umgezogen und mit Jetty 7 ändert sich das Problem ein wenig: Jetty 7 akzeptiert nun im Default auch Servlets für ein Welcome-File-Mapping – jedoch findet vorher noch eine Prüfung statt, ob die Datei existiert. Existiert sie nicht, wird ein 404 HTTP Fehler erzeugt. Natürlich kann man dies über Konfiguration des Default Servlets ändern – aber dann hat man wieder die Jetty Abhängigkeit im Projekt. Hier hilft ein kleiner Trick: Man legt einfach eine leere Datei, z.B. index.html, an, gibt diese (zusätzlich) in der Welcome-File-List an, und mappt diesen Pfad auch noch auf das entsprechende Servlet. Diese Lösung funktioniert mit allen von mir getesteten Containern. Also kommt zusätzlich in die web.xml:
myServlet /index.html
Für das Maven Plugin von Jetty 7 hat sich der Artefakt Name geändert, und auch der Default Context ist “/” statt des Artefakt Namens – so sieht der Eintrag im POM daher aus:


  org.mortbay.jetty
    jetty-maven-plugin
    7.2.1.v20101111
    
      
        /${artifactId}

Nun noch die Konfiguration für Spring 3 Controller, die auf den Root Path gemappt werden sollen. Ich verwende hier die Spring Annotationen für @Controller und @RequestMapping. Das Problem hier: Jetty ruft “natürlich” die “index.html” auf – auch hierfür muss der Controller dann ein Mapping haben. Die Lösung dafür ist ein Pattern zu verwenden, was Spring erlaubt:

@Controller
public class SampleController
{
   @RequestMapping(value = "*", method = RequestMethod.GET)
   public ModelAndView rootPathHandler()
   {
       //...
       return new ModelAndView("sample");
   }
}

Artikel von: everflux.de

Java Servlet (Spring Controller) auf Root Path mappen

Ähnliche Beiträge: