Revamping the XMPP transport

September 17 2009


Some time ago I wanted to do a Mule demo. I’m a Jabber fan so I wanted to use the XMPP transport for the demo.

I soon found out that the XMPP transport in its current form doesn’t work with real world Jabber servers any more. SSL connections are negotiated through TLS now and authentication seems to involve SASL – two things that the outdated smack version we’re using for the XMPP transport cannot currently do.

So I decided to not only update the library but rather make the config of the transport more user friendly.

One thing I never liked about the old XMPP transport was that all the connection information had to be in the endpoint URLs. This created weird runtime scenarios where for each endpoint a new connector object had to be created because the connector was the one holding the connection to the Jabber server.

The new config will allow you to configure Jabber host, user and password on the connector. Here’s a config example:

The endpoints will only have the type of message to use and the recipient/sender. Here’s a config example:

or, as endpoint URL:

For now I’m still developing the new transport in private because I don’t want to break the 3.0 build. Once I have a working transport it’ll be available as part of the public Mule 3.0 snapshots.

I’m really open to suggestions so if you want to help shape the new XMPP transport or have other suggestions, thoughts, or contributions, I’d like to hear about them.

We'd love to hear your opinion on this post

12 Responses to “Revamping the XMPP transport”

  1. Did you forget to include the config example?

  2. Thanks for taking this on. I had put in the JIRA to update the SMACK API about a year ago.

    While you are at it though, here’s a wishlist… 😉

    1. Support a proxy account that would establish a connection at Mule start up and stay alive forever or until a specified timeout.

    2. Support attachments.

    3. Support XMPPS.

  3. We have several cases where we want the recipient to be specified as part of the MuleMessage. So it would be great if you could specify an attribute on the endpoint OR set the recipient as a prop on the message. It should also allow for a comma-delimited-list of recipients.

  4. The config examples were missing in the first rev of this post because of technical difficulties. They’re fixed now.

  5. Steven, can you elaborate on your first wish? Right now the connector is the object that creates and holds the XMPP connection. So the connection is open as long as Mule runs.

    XMPPS support is somewhat automatic nowadays as the smack library can to TLS automatically. I’d have to find a public jabber server with “legacy” SSL support (on port 5223) to test against.

  6. Neil, the message property override is a good one, noted. The message property will override the recipient that’s configured on the endpoint.

    As for multiple recipients in the property I’m not convinced. That’s what the multicasting router is for.

  7. Neil, sounds like endpoint-selector-router will do the job today.

  8. One thing I’d like to see is masked passwords (not just for XMPP, but for anything requiring a password.) In our env we often need to use real usernames/passwords for certain transports (eg, XMPP), and plaintext is a nightmare.

  9. Dirk – I am working on a project where we are currently upgrading from Mule 2.0.2 (Phlexible Phonetician) to Mule 3.0.0 (Steamy Steampunk) – I “noticed’ that the folks at smack-soft depreciated / underappreciated the XmppsConnector class. We had some code written by a previous developer who is no longer available for support on the project who seemed use this flavor of the transport extensively. I’m just looking for some basic insight on how to use the 3.0.0 release of the mule-transport-xmpp XmppConnector class in lieu of Xmpps geared impl. The Mule 3.x docs are pretty lackluster on the topic of the Xmpp transport as they still claim that the Xmpps transport is supported. It looks like you were the sole guy that stuffed that support into one of the snapshots but it didn’t really take in the official release. (which makes sense since it is also not supported in the latest smack lib) Seriously – whats going on here? Is it that we are just supposed to use an Xmpp connection in a way where SSL is supported by the use of flags?

  10. XMPP uses SASL now which is supported by the smack API. Hence, no need for a dedicated XMPPS connector any more. I’m not an expert on SASL authentication but if you need conifguration options on the XMPP transport, file a JIRA and I’ll have a look at it.

  11. Thanks Dirk. That clears things up a bit.
    Someone else asked this, and we also have a need for it – Is there an easy way to make an inbound xmpp connection that can accept a Chat or Message regardless of the sender’s JID?

  12. I have created to track this.

    Please add the answer to the following question to the JIRA: what’s the exact requirement? Do you just want to receive *any* XMPP message that goes through the server or do you want to limit incoming messages by type, i.e. chat, message?