30.3.2009, 8 Uhr 44
30. März 2009

![]()
So manchmal frage ich mich wirklich, was manche Leute so denken. Diese ganzen dahergelaufenen Würstchen, die in ihrer eigenen Welt leben und glauben, dass sie den Laden regieren. Telepolis berichtet über so einen armseligen Resozialisierungsfall: Ulrich Hoeneß fordert im Interview mit der Wirtschaftswoche eine GEZ-Extragebühr für die notleidenden Fußballvereine. Peter Mühlbauer dazu:
Und Aktiengesellschaften, die mit schöner Regelmäßigkeit ein- oder zweimal die Woche so viele Gewalttäter zu rituellen Schlägereien und Sachbeschädigungsorgien anlocken, dass sich die Polizei an solchen Tagen kaum mehr um etwas anderes kümmern kann, werden nicht einmal zur Finanzierung der Wochenendzuschläge herangezogen, geschweige denn für die auf den Steuerzahler abgewälzten Kosten, welche ihr Geschäftsmodell tatsächlich verursacht. Dazu zählen auch zahlreiche von angeblich klammen Kommunen gebaute oder geförderte Sportstätten und U-Bahnen, welche Rotten von Krawallmachern bequem zu ihren Tatorten kutschieren.
Es war wohl wieder mal Zeit für die tägliche Portion Wahnsinn.
Zypries gibt von der Leyen Contra. Gut. Aber irgendwie werde ich das Gefühl nicht los, dass es gar nicht um die Sache geht, sondern hier einfach nur parteitaktische Spielchen gespielt werden. Btw: warum die Content-Mafia nicht schon längst auf die glorreiche Idee gekommen ist, dass ja “Bittorrent hauptsächlich von Perversen für KiPo genutzt wird” und damit das Totschlagargument in der Hand hätte, wundert mich ein wenig.
Der neue iPod Shuffle hat ein DRM-System verbaut, das verhindert, dass nicht durch Apple lizensierte Kopfhörer genutzt werden. Boing Boing meldet, dass “compliant Headphones” über einen DRM-Chip verfügen müssen. Die EFF berichtet ebenso und iLounge fasst sehr gut zusammen:
This is, in short, a nightmare scenario for long-time iPod fans: are we entering a world in which Apple controls and taxes literally every piece of the iPod purchase from headphones to chargers, jacking up their prices, forcing customers to re-purchase things they already own, while making only marginal improvements in their functionality? It’s a shame, and one that consumers should feel empowered to fight.
Einfach nur krank und ein weiterer Grund, keine Apple-Produkte zu kaufen. Defective by Design eben.
News from the gadget department: just got my PayPal/eBay Security token. It is a nice little device just the right size for a keychain. The token is made by Verisign and can be used to protect your PayPal and eBay accounts. Once activated, you have to log in to these accounts using the number displayed on the token. Every number is valid for 30 seconds. The idea is that you can only log in to your account when in physical possession of the piece of hardware.
You can order the token worldwide for around 5 Euros here.The device itself is a Vasco Digipass Go 3, which can also be ordered from Verisign directly (which costs $30). Verisign announces the Go 3 OTP device as a device usable with Verisign’s OpenID service. So, I was giving it a try and registered my token at Verisign’s OpenID site…and it works!
When registered with the service, you can use the PayPal token to log in into all OpenID enabled sites like Sourceforge or use it for your own applications. The access to the Quendor.org adminstration interface is now accessible thru OpenID authentication and I can use my keychain token to log in. Nice.
Neues von der Gadget-Front: ein chinesischer Game/Video/MP3-Player. Der Dingoo A320 emuliert alle gängigen Classic-Konsolen, kann MP3s abspielen und Videos darstellen. Und alles noch auf dem TV-Out ausgeben. Nett.
Mal abwarten ob noch ein paar bessere Emulatoren dafür erscheinen.

Jay. In diesem Frühjahr erscheint tatsächlich “Giana Sisters 2″ für den NDS. Damit wird eines aus meiner Sicht besten Computerspiele aller Zeiten fortgesetzt. Mehr Infos beim Publisher, Spellbound Entertainment. Auf dem NDS gibts sowieso viel zu wenige 2D-Jump-and-Runs.
Der erste Teil war eigentlich ein böser Mario Rip-Off, aber damals wars egal, nur Noobs hatten ein NES, echte Kerle hackten auf dem C64. Nintendo fand das damals allerdings nicht so witzig, das Spiel wurde wegen einer Klage ziemlich schnell wieder zurückgezogen. War aber auch schon ziemlich dreist, vor allem, weil auf Seiten Rainbow Arts eine gewisse Doppelmoral vorhanden war.
Jaja, die gute alte Zeit..
Another thing about CXF: if you’ll get strange errors like this on server start:
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'myService': Invocation of init method failed; nested exception is javax.xml.ws.WebServiceException: org.apache.ws.commons.schema.XmlSchemaException: Schema name conflict in collection Caused by: javax.xml.ws.WebServiceException: org.apache.ws.commons.schema.XmlSchemaException: Schema name conflict in collection
then make sure your WSDL is WS-I compliant. You can check it by switching on WSDL verification with wsdl2java (using ‘-verify’).
CXF is surely a great tool to get JAX-WS up and running very fast and clean. But sometimes, it also put a bit of headache on me. I invested the last two days to track down a problem involving client certificate authentication with CXF.
I used CXF to set up a client for a SSL-secured web service. I set the environment variables for truststore and keystore as ususal:
System.setProperty("javax.net.ssl.trustStore", "truststore.jks");
System.setProperty("javax.net.ssl.trustStorePassword", "secret");
System.setProperty("javax.net.ssl.keyStore", "keystore.jks");
System.setProperty("javax.net.ssl.keyStorePassword", "secret");
This works out-of the-box with a simple Java SSL client. No other configuration is needed to authenticate with client certificates.
But not with CXF. The server side complained about “bad_certificate” and “certificate chain null” regardless on how I set up the keystore and truststore. A rather annoying day of CXF core code debugging followed until I found the solution: CXF needs the key and truststore explicitly set using the appropriate factories! It does not work with only the properties set, it does not work with user created trustmanagers and keymanagers! You have to exactly follow the example found in this article. Otherwise, CXF does not recognize the certificates right and simply do not send them to the server side, leaving the certificate chain empty.
More annoying is that you need both ways of setting the keystore and truststore: it also does not work without specifying the environment variables! So the resulting code example is like this:
System.setProperty("javax.net.ssl.trustStore", "truststore.jks");
System.setProperty("javax.net.ssl.trustStorePassword", "secret");
System.setProperty("javax.net.ssl.keyStore", "keystore.jks");
System.setProperty("javax.net.ssl.keyStorePassword", "secret");
Client client = ClientProxy.getClient(caPort);
HTTPConduit conduit = (HTTPConduit)client.getConduit();
TLSClientParameters tlsParams = new TLSClientParameters();
// disabling host name check
tlsParams.setDisableCNCheck(true);
// setup truststore - AGAIN!
KeyStore keyStore = KeyStore.getInstance("JKS");
String trustpass = "secret";
File truststore = new File("truststore.jks");
keyStore.load(new FileInputStream(truststore), trustpass.toCharArray());
// setting trust manager(s)
TrustManagerFactory trustFactory =
TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
trustFactory.init(keyStore);
TrustManager[] tm = trustFactory.getTrustManagers();
tlsParams.setTrustManagers(tm);
// setup keystore - AGAIN!
truststore = new File("keystore.jks");
keyStore.load(new FileInputStream(truststore), trustpass.toCharArray());
// setting up key manager(s)
KeyManagerFactory keyFactory =
KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
keyFactory.init(keyStore, trustpass.toCharArray());
KeyManager[] km = keyFactory.getKeyManagers();
tlsParams.setKeyManagers(km);
// setting parameters
conduit.setTlsClientParameters(tlsParams);
CXF is great, but sometimes, I’m getting real old with it..