]]>
After a long time, commons-net 2.0 has finally been released. It is now also available in the central Maven repo. While there are many changes and general clean ups in the release, the big news for me is the support for FTPS. That’s a feature we use a lot in the unit testing of Apache FtpServer so now having commons-net release rather than as a snapshot should make life easier.
Now, countdown to getting 1.0-M4 of FtpServer released has started. Still got some bugs to fix.
If you liked his previous poster, The Web Is An Agreement, you’re going to love this one. I think psd has outdone himself. Find myself searching for new small details all the time.
Now it’s time to convince The Wife that this needs to go on a wall somewhere…
]]>]]>
“Statisticians are people who like figures but don’t the personality skills to become accountants.”
“How to you tell the introverted statistician from the extroverted statistician? The extroverted statistician is the one looking at the other persons shoes.”
Peter Donnelly in a TED talk. Made me spill my glass of milk.
Oh, and do watch Richard Dawkins talk while you’re at it.
]]>Woot! The epic battle between OSGi and JSR277 seems to have taken yet another turn. Sun has hired Richard S Hall, of Apache Felix fame. Possibly one of the very foremost experts on OSGi. His task is to work on OSGi for Glassfish. To me, this is interesting both in terms of JSR277 and what deeper OSGi support in Glassfish would mean. Is Sun looking at doing native bundle deployment to Glassfish, ala SpringSource Application Platform and Infiniflow? If so, it would be another major step towards a decent module model for Java EE applications. And, as a bonus it might do some good for the historically cold relation between Apache and Sun.
]]>Not only did Cisco see the need in inventing their own RPC protocol, now they become the third major player in a short time to open source it, or at least that’s the aim. The opening of Facebook’s Thrift was pretty much quite. But, as with anything touched by todays Midas, Google’s Protocol buffers stirred a bigger debate on the merits of RPC.
I think this is an area that merits some further discussion. By now, we’ve figured out that RPC is a bad fit in heterogeneous, cross-domain integrations. But, in the case you own both ends of the wire and you need some serious throughput and low latency communication, these types of protocols is likely a better fit. At least in the mega environments some of the web companies run these days. It’s interesting to follow along with the rapid development of such infrastructure, even though they are out of the hands of most of us. At least for now.
So, with all three combatants now in the open. Let the fight begin.
]]>Today I was creating a spiced up version of the TCP connection state diagram from RFC 793 for some documentation. It turned out pretty nicely so I thought I should post it here. It’s a 1-to-1 conversion of the diagram in the RFC. The theme is based on the very nice GTD wallpapers. Drawn in Visio, source available here
.
Click for a full size version. If there is any interest, I’ll provide a SVG version as well.
Feel free to comment with feedback and corrections.
]]>While I’m a big fan of Scala, and in general like to write more stuff in less code, I’ve seen a few cases of people showing examples of how terse the code gets once its in Scala (or Ruby or what ever) compared to Java. However, in many of those examples, the effect is solely due to using one liner code rather than those, actually readable constructs that code conventions has taught us to use. Not to pick on this post in particular (it does in fact mention that they are not satisfied with the result), but it does show my problem. Of course, that Java code could be written like this:
Vector v = new Vector ();
for(String s : map.keySet()) if(s.startsWith(prefix) && !s.equals(prefix)) v.add(s);
return v.size() > 0 ? v.toArray(new String[0]) : null;
Is that generics beautiful? Not exactly. Do we have to do a lot of stuff the compile could do for us? Yeah. But I would argue that this code is as readable as the Scala code in the post.
(for (val key < - map.keys if key.startsWith(prefix) && (key != prefix)) yield key).toList match {
case Nil => null
case list => list.toArray
}
Which is to say, not a lot. And it’s not significantly more verbose. Now, as the comment on the post show, there are better ways of doing this which really does make Scala shine. That’s the examples we need.
]]>This is a follow-up on my previous post on creating certificates for WebSphere MQ.
In one of my customers environment we began having troubles connecting to SSL secured WMQ channels as we upgraded the WebSphere Message Broker Toolkit to version 6.1. After opening a ticket with IBM and getting quite a few groups within Big Blue involved, it turned out that starting with the IBM Java 1.5 JRE, they have added a validation on Basic Constraints for CA certificates. WMB 6.1 ships with Java 1.5. The scripts I published in my last post does not set this attribute. As far as I’ve been able to find, there is no workaround besides recreating your CA certificate, which means re-signing all your keys. This annoys me, but given that the requirement for setting the Basic Constraints has been in the RFC since before dawn, the blame is pretty much my own.
4.2.1.10 Basic Constraints
The basic constraints extension identifies whether the subject of the
certificate is a CA and the maximum depth of valid certification
paths that include this certificate.
The cA boolean indicates whether the certified public key belongs to
a CA. If the cA boolean is not asserted, then the keyCertSign bit in
the key usage extension MUST NOT be asserted.
This extension MUST appear as a critical extension in all CA
certificates that contain public keys used to validate digital
signatures on certificates.
Anyways, the script is now updated. The required change is to add the argument “-ca true” when creating the CA certificate.
If you have any further suggestions to improve the scripts, please contact me and I’ll make sure to upgrade them.
last.fm just launched their brand new API (via Fredrik). Sporting support for both XML-RPC and REST. Now that’s a first sign of warning. And unsurprisingly it turns out that the “REST” API is just another RPC over HTTP incarnation.
For example.:
http://ws.audioscrobbler.com/2.0/?method=artist.getSimilar&api_key=xxx...If you are accessing a write service, you will need to submit your request as an HTTP POST request. All POST requests should be made to the root url:
http://ws.audioscrobbler.com/2.0/
WTF? Is it really that hard to get REST? To add insult to injury, they even managed to make up their own authentication protocol, despite, you know, OpenID and OAuth being fairly mainstream these days.
]]>