Skip to main content

Cookie handling with Apache XML-RPC

The example on the Apache website that explains how to pass cookies when calling an XML-RPC service is unfortunately... a bit b0rked. It doesn't compile, for starters. It's also quite a bit more complicated (and handwavy) than it needs to be. I don't know if this is because the API has changed over time. I tend to think it has suffered the copy-paste equivalent of chinese whispers from an origin in some mailing list.

Anyway, I needed to send a single sign on (SSO) cookie to an XML-RPC service recently. I'm using Apache XML-RPC 3.1 (I notice in the Javadoc that this code might be slightly different if you're using a later version). Here's roughly what I did:

First, the standard, boring stuff:

XmlRpcClientConfigImpl config = new XmlRpcClientConfigImpl();
config.setServerURL(new URL("https://myservice.com/api"));
XmlRpcClient client = new XmlRpcClient();
client.setConfig(config);

Now, the juicy part. It's really, really easy. Look, ma, so much less code than the example on the ws.apache.org website, and it's even syntactically correct!:

XmlRpcTransportFactory factory = new XmlRpcSunHttpTransportFactory(client) {
  public XmlRpcTransport getTransport() {
    return new XmlRpcSunHttpTransport(client) {
      @Override protected void initHttpHeaders(XmlRpcRequest request) throws XmlRpcClientException {
        super.initHttpHeaders(request);
        setRequestHeader("Cookie", myLovelyCookieData);
      }
    }
  }
};
client.setTransportFactory(factory);
Update: Fixed a bug in the code. Oh, the irony. That'll teach me to be so arrogant :P

Comments

  1. This example does not seem to compile

    ReplyDelete
  2. I tried this and it works, but now I'm in a situation where I need two cookies. I tried making myLovelyCookieData = "cookie1=data1;cookie2=data2"
    but it seems the other end is not seeing it. Any ideas?

    ReplyDelete

Post a Comment

Popular posts from this blog

Java Blooper #2: Must be a Better Way...

The post you're reading is ancient, and yet slightly inexplicably popular :) I've recently started blogging again in 2020 with some fresh content. Check out some of the new topics about blogging again , dynamic method invocation , and aapt2 . It's Monday, which means it's time for another blooper ... What's wrong with this code? boolean hasThing( List things, Thing thing ) { for ( int i=0; i < things.size(); i++ ) { if ( thing.equals( things.get( i ) ) ) { return true; } } return false; } Update: Minor edit to add missing parenthesis from if statement that got "lost in translation" en-route to the blog :)

Configuring Mac OS X Terminal

The post you're reading is ancient, and yet slightly inexplicably popular :) I've recently started blogging again in 2020 with some fresh content. Check out some of the new topics about blogging again , dynamic method invocation , and aapt2 . I recently installed Leopard (Mac OSX 10.5) on a new mac. There are a few factory settings I usually change on a new installation, although by far fewer than I do typically with Windows. One of them is the default keyboard configuration for Ctrl+Left Arrow, Ctrl+Right Arrow, Page Up, Page Down, Home, and End in Terminal. The default settings drive me a bit potty since I'm used to using Linux and emacs every day at work. Changing them is easy, fortunately. Just visit Keyboard under Settings in Terminal->Preferences , and modify the following keys, so that their action matches the value shown. You can edit the keystroke for an item by double clicking on it, selecting "send string to shell", and typing the indicated ke

Java Blooper #1: Ternary Insanity

The post you're reading is ancient, and yet slightly inexplicably popular :) I've recently started blogging again in 2020 with some fresh content. Check out some of the new topics about blogging again , dynamic method invocation , and aapt2 . From time to time, we all write code that could be clearer. Sometimes in the rush of solving a problem, we don't pay attention to the micro details of the code flowing from our fingertips. Other times, we refactor some existing code, and don't necessarily take the opportunity to clean up as much as we could. I find it useful sometimes when reading code to think about whether it could be rewritten in a more straightforward way, and if so whether any lessons can be learned about writing tight and expressive, and most importantly, readable code. Over the next few weeks, I'm going to blog weekly examples of some Java code bloopers that I've seen. All the examples are real and have been observed "in the wild".