Let us consider a simple client which will use IM api and talk XMPP directly to the server.
The only modification to this client to use HTTP would be in the session creation phase , so I will restrict the client to that part of the code.
If you want to take a look at a more 'full fledged' client , take a look at org.netbeans.lib.collab.tools.Shell.


The behavior of this code is as follows :

• Lookup the system property "org.netbeans.lib.collab.CollaborationSessionFactory" if specified , use that as the session provider factory , else.
• Fallback onto the default CollaborationSessionFactory delegates to a direct socket based XMPP stream : org.netbeans.lib.collab.xmpp.XMPPSessionProvider.

The parameters are :

1. Server url - this is an overloaded parameter. For a direct stream based XMPP connection , this will be of the form "host:port". For our HTTP case , it is slightly different - and I will detail it below.
2. The user and password specified are used to authenticate the user. In a later post , I will write about how to use SASL.
3. The CollaborationSessionListener specified is the default listener to dispatch events to. More interesting things can be done with subinterfaces of CollaborationSessionListener - more on that too later
   

For a direct xmpp case , the above will look like this :

A bare bone CustomCollaborationSessionListener will just implement the "public void onError(CollaborationException e);" without taking any action about them.

Thats it , your basic code will work now (the server specified above is the netbeans collab server - create a valid userid and give the code above a whirl !).

How to make this HTTP enabled ?
Just two changes :

• Specify the HTTP session provider class explicitly using :

1. CollaborationSessionFactory _factory = new CollaborationSessionFactory("com.sun.im.service.xmpp.httpbind.HTTPBindSessionProvider");
2. Or , set the env variable "org.netbeans.lib.collab.CollaborationSessionFactory" to "com.sun.im.service.xmpp.httpbind.HTTPBindSessionProvider" before creating the session factory.
   

• Change the server to point to a httpbind connection manager which is JEP124 compliant. Additional parameters can be specified to this url as query params : refer to HTTPBindConstants for list of actual parameters.
  

So , a JEP124 version of the initial code would be :


It is mandatory to specify the domain you want to talk to using the 'to' parameter. I am using two other parameters just to illustrate how you would go about customising more.
The rest of the code which manipulates and uses the returned _session is the same irrespective of whether it is direct XMPP or through HTTP.

Some caveats about the HTTP provider in collab codebase from the top of my head (ignore these if required) :

1. It does not support proxies directly , but just relies on URLConnection. So to use proxies , the user will need to explicitly set the "http.proxyHost" and "http.proxyPort" system properties. (*More on this below.)
   
2. It does not honor the timeout's set as part of the initial handshake. (** More below).
   

* This limitation exists since the im module is also used from java 1.4 VM's. The ability to specify a per connection proxy was introduced only in java 1.5 ...
How to fix this ?
It is very easy for a developer to write a custom impl of ConnectionProvider to pick up the "proxytype" and "proxyhostport" param from the service url and use it to connect to the httpbind gateway (If you want to go with default impl itself , just extend it and override the openConnection(URL) method).

** As part of the initial handshake with the gateway, the client and httpbind gateway arrive at timeout's for the request.
These are not honored at the client side 'cos of the same limitation above. Custom implementation can override and use the setReadTimeout() and setConnectionTimeout() methods are appropriate.


If there is a need , I could always write a simple implementation of ConnectionProvider for java 1.5 which gets over the above limitations.
What to expect next ?
What about how to use the basic client and start using TLS and SASL ?!
Yep , that should be fun - so watch out for next update soon !