Monthly Archives: July 2014

The Other One

As JAX-RS implementations go, I suppose Apache CXF is as good as any. But among all the conveniences, it certainly has its share of surprises. For example, although I follow a typical REST resource URI scheme, I had to write a custom ResourceComparator to get certain lookups to work across multiple service beans. I’m over that now, but today’s bug was really weird.

In this case, I’m handling basic authentication in an upstream inInterceptor, pulling credentials from the message. This has several benefits, including simpler service beans. If credentials are missing or invalid, I do the usual 401 / 403 thing, but if authenticated, I inject a SecurityPolicy containing my Principal, like so:

        message.put(SecurityContext.class, new BasicSecurityContext(userProfile));

.. with the hopes of my service bean having access via:

        @Context SecurityContext securityContext

Trouble is, that came out null. Turns out, this is a known issue with CXF, and the work-around (barring unwanted extra plumbing) is to use, not So much for polymorphism.

Que penser de ces Pommes?

iOS AirPlay icons are infamous for disappearing when you need them most, but the usual work-arounds weren’t working under iOS 8 Beta 4.  So I went googling and found this gem:

On your iPad, iPhone or iPod touch, navigate to Settings > General > International > Language and change to a different language… The device will go through a language switch/reset process, and your AirPlay icon should be restored.

Next navigate back to Settings > General > International > Language (translated into the new language, of course) and switch back to your original language.

Change languages: love it! Fortunately, I remembered enough high school French to try it, but it seemed silly and didn’t work. But since it has worked for many others, it gets my vote for the most interesting work-around ever.


In today’s action, I wrote a new Google Cloud Messaging (GCM) server interface to the GCM Cloud Connection Server (CCS) via XMPP. GCM CCS offers several benefits over GCM HTTP including one of my key requirements, bidirectional messaging.

My app server didn’t yet have a XMPP interface, so I followed Google’s sample and plugged in Smack. Then the fun began. I immediately started getting exceptions (see Smackdowns below). These varied based on state and configuration, but basically the result was the same: the GCM CCS server was abruptly closing the connection during authentication. How rude; Smack was getting smacked down.

I dug in but ran into several red herrings. For example, Smack’s stream headers didn’t match Google’s doc (no tag close); Google’s doc is wrong. I debugged Smack, tried different Smack versions, tried other XMPP clients, tweaked configurations, studied XMPP protocols and SASL authentication, and updated authentication parameters and allowed IPs. Ultimately, I had a minor error in one of the authentication parms. I found it by Base64-decoding the auth value in Google’s example and comparing it to my own traces.

This would have been a quick fix if CCS had just given an authentication error message rather than just slamming the door. It must be a security thing. Oh well, on to the next adventure.


No response from the server.: 
	at org.jivesoftware.smack.NonSASLAuthentication.authenticate(
	at org.jivesoftware.smack.SASLAuthentication.authenticate(
	at org.jivesoftware.smack.XMPPConnection.login( Connection closed by remote host
	at Source)
	at Source)
	at sun.nio.cs.StreamEncoder.writeBytes(Unknown Source)
	at sun.nio.cs.StreamEncoder.implFlushBuffer(Unknown Source)
	at sun.nio.cs.StreamEncoder.implFlush(Unknown Source)
	at sun.nio.cs.StreamEncoder.flush(Unknown Source)
	at Source)
	at Source)
	at org.jivesoftware.smack.util.ObservableWriter.flush(
	at org.jivesoftware.smack.PacketWriter.writePackets( no more data available - expected end tag  to close start tag  from 
                                      line 1, parser stopped on END_TAG seen ...... @1:344
	at org.xmlpull.mxp1.MXParser.fillBuf(
	at org.xmlpull.mxp1.MXParser.more(
	at org.xmlpull.mxp1.MXParser.nextImpl(
	at org.jivesoftware.smack.PacketReader.parsePackets(

Android Studio

I’ve been waiting months for a “ready for prime time” version of Android Studio. Its move from “Preview” to “Beta” (version 0.8) on June 26 became my signal to dive in deep and use it for real work. After all “beta” in Google terms usually means a level of quality some products don’t achieve with years of “GA” releases.

Android Studio inherits many of its benefits from IntelliJ. I like the speed and stability, the quality of the development and rendering tools, the productivity, the rich static code analysis, and all the other benefits that come from its IntelliJ underpinnings.  I’ve bounced back and forth between Eclipse keymaps and IntelliJ defaults, but settled on the IntelliJ’s, with the cheat sheet on hand. “When in Rome,” don’tchaknow, although I haven’t yet joined the Darcula side. Even from a few days’ use, I’m sold on IntelliJ and certainly don’t miss Eclipse’s crashes and stalls.

I’m also pleased with the Gradle-based build system and AAR support. After fighting with Maven plugin bugs, apklib hacks, and other Eclipse-Maven clashes, it’s refreshing to have a build system that is elegant, is backed by Google, and just works. The factoring of content across build.gradle files, manifests, etc., is clean and DRY, and the Android-specific checks guide you toward best practices.

The main downside is that there is no automatic nor incremental build as with Eclipse, so builds are slower and many errors aren’t discovered during editing. Build speed will likely improve as it exits beta (perhaps with the help of parallel builds), but the rest is just the IntelliJ way.

Still, I’m happy with both IntelliJ and the Android Studio so far. Now if I could only switch from MyEclipse to IntelliJ for server-side code…