Proper way to decode response in Dojo cometd java client

Question

I want to push arbitrary XMLEncoded java objects back and forth using Dojo cometd channels, and I have a problem decoding the payload properly.

In order to do this I have this send method in a stripped down version of the chat room client demonstration program:

private void send(String string) {
  Map<String, Object> map = new HashMap<String, Object>();
  map.put("intArray", new int[] {1});

  ByteArrayOutputStream baos = new ByteArrayOutputStream();
  XMLEncoder xmlEncoder = new XMLEncoder(baos);
  xmlEncoder.writeObject(map);
  xmlEncoder.close();
  Map<String, Object> encodedMap = new HashMap<String, Object>();
  try {
    String encoded = baos.toString("UTF-8");
    encodedMap.put("xmlpayload", encoded);
  } catch (Exception e) {
   throw new RuntimeException("could not use UTF-8", e);
  } 
  bayreuxClient.publish("/prototype/a", encodedMap, String.valueOf(System.currentTimeMillis()));
}

Which for now creates a XML snippet flattened to an UTF-8 encoded byte stream (I am aware I need to take care of the encoding too, but that is not the issue now).

The message listener accepting this looks like:

listener = new MessageListener() {
  @Override
  public void deliver(Client fromClient, Client toClient, Message msg) {
    if (!_connected) {
      _connected = true;
      synchronized (this) {
      this.notify();
    }
  }
  Object data = msg.getData();
  if (data instanceof Map) {
    Map map = (Map) data;
    Object rawPayload = map.get("xmlpayload");
    if (rawPayload instanceof String) {
      System.out.println("xmlpayload = " + rawPayload);
      ByteArrayInputStream bais;
      try {
        String xmlPayload = ((String) rawPayload).replaceAll("&gt;",">").replaceAll("&lt;", "<").replaceAll("&amp;","&");
        bais = new ByteArrayInputStream(xmlPayload.getBytes("UTF-8"));
        XMLDecoder xmlDecoder = new XMLDecoder(bais);
        Object o = xmlDecoder.readObject();
        xmlDecoder.close();
        System.out.println(">> decoded payload=" + o + ", class=" + o.getClass());
      } catch (UnsupportedEncodingException e) {
        throw new RuntimeException("no UTF-8", e);
      }
     }
   }
  }
 };
 address = new Address("localhost", 8080);
 bayreuxClient = new BayeuxClient(httpClient, address, "/cometd/cometd");
 bayreuxClient.addListener(listener);

As you can see I have found by trial and error that the string sent has its less than, greater than, and ampersand characters protected which I then unprotect and call XMLDecode on.

The output is:

xmlpayload = <?xml version="1.0" encoding="UTF-8"?> 
<java version="1.6.0_16" class="java.beans.XMLDecoder"> 
 <object class="java.util.HashMap"> 
  <void method="put"> 
   <string>intArray</string> 
   <array class="int" length="1"> 
    <void index="0"> 
     <int>1</int> 
    </void> 
   </array> 
  </void> 
 </object> 
</java> 

>> decoded payload={intArray=[I@2f1e75}, class=class java.util.HashMap

so it is reversible. My experiments with putting these characters inside string objects being XMLEncoded/XMLDecoded were not good - they were not double proctected - so my brute decoding also affected them.

The question is: What is the proper way to decode these strings? Is there a JSON library I need to use instead of my quick and dirty code? Might I have hit an error in the Java client library for cometd?

(Note: I have been using the cometd-1.0.0rc0 libraries for this experiment).

---

EDIT: It turned out that the communication happened through another deployment in the same webserver than the one I thought took care of the cometd communications, and that deployment contained filter.json which did the XML protection.

http://groups.google.com/group/cometd-users/browse%5Fthread/thread/6fbdaae669e5f9d3

In other words a configuration issue outside my code. Hopefully a revised deployment will remedy this issue.

Answer 1

The best library to use to unescape XML is Apache Commons Lang,

   StringEscapeUtils.unescapeXml();

Looks like this is a bug in the Bayeux Java client you use. Its encoding/decoding are not symmetric. I was going to use it. Now I will think twice :)