JUnit report StackOverflowError ; a quick hack fix

Posted by Rajesh Shetty on June 08, 2010

Blog post after a long time but this one deserves it because this can save someone a day or few minutes/hours of their time for sure.

Issue: When you run JUnit report generation using Ant target you will run into java.lang.StackOverflowError.

Where: Happens only on Windows machine (at least I have seen it). Works fine on linux/mac os x.

Why: When XSLT engine runs thru all the properties supplied to it while doing the actual test case to report translation, it runs into java.class.path variable specified and if your class path has too many path elements , it goes into infinite death loop.

How to fix: A Quick hack or fix (whatever you want to call it as); is to tell XSLT engine ignore the java.class.path while evaluating properties. To do that you will have to explicitly specify where to pick up the stylesheet from. Luckily junitreport lets us specify the external xsl folder location using styledir attribute in

 <report ...

tag. So this is what you need to do.

  1. get a copy of junit-noframes.xsl (if you are using with frames get a copy of that) from the internet. or you should be able to get this from the latest version of Apache Ant and it should be located in /etc folder. Now copy this xsl fi
  2. Now change

    <xsl:template match="properties">

    section from

    <xsl:for-each select="property">

    to

    <xsl:for-each select="property[not(@name = 'java.class.path')]">

    and save this file in some location e.g c:/junit/xsl

  3. In your ant target explicitly specify the junit-noframes.xsdl location by adding styledir . It should look something like this

    <report format="noframes" todir="${junit.test.reports.dir}" styledir="c:/junit/xsl" />

That should fix the issue.
Point # 2 above tells the xsl engine to ignore classpath variable.

Issue with Facebook Java API’s photos upload with caption.

Posted by Rajesh Shetty on March 22, 2008

Context : Facebook-Java API usage for uploading photos.
Problem : You get error "Incorrect Signature" while doing  client.photos_upload with caption as one of the parameter. This happens when you have caption with 
more than one words or any special character.


Reason: In FacebookRestClient.java : postFileRequest method it encodes all the form data. So when you send caption with photo, it URL encodes the caption also. One word caption is fine , but  if you have more than one word "my buddies" will be encoded and result will be "my%20buddies" which Facebook does not like at the receiving end. Have a look at their documentation for photos upload. 


Solution: Simple brute force solution is not to send caption encoded. Drop following line in postFileRequest method 
        if (entry.getKey()!=null && entry.getKey().equals("caption"))
         doEncode = false;


right before following line out.writeBytes(doEncode? encode(entry.getValue()): entry.getValue().toString());


compile the Facebook source again , bundle the jar file and you are done. 
BTW, I have not really looked their bug list or discussion forum , they might have a better solution for this but thought would share this for people who want to know what the issue is when they see this error "Incorrect Signature" , which is completely misleading.
Another effort to save someone's day.



Blogged with MessageDance using Gmail

Apache Axis namspace quirk in a SOAP response

Posted by Rajesh Shetty on February 01, 2007

When you use Apache Axis for your web services implementation , its a wise move but you got to remember its few one off situations, like this one that I’m going to explain.
Apache axis generates namespaces in every single element of the response , which can be very painful for the client if client is going parse and moreover its additional overhead in your SOAP response back to client, you are pushing more data over the wire where it can be avoided. sample looks something like this

<SOAP ENV..>
<SOAP Header..>
</SOAP Header..>
<SOAP body>
<ns1:elemenntname xsi:type=”xsd:string”
xmlns:ns1=”http://a.b.c/….” >
<ns2:elemenntname xsi:type=”xsd:string”
xmlns:ns2=”http://a.b.c/….” >

<ns3:elemenntname xsi:type=”xsd:string”
xmlns:ns3=”http://x.y.z/….” >

</SOAP body>
</SOAP Env…>

So above if you see , its unnecessary data getting duplicated in each element, where as ideally axis should be doing this internally by aggregating namespaces. So what you have to do is add following code in the your services code

org.apache.axis.utils.NSStack namespaceList = new org.apache.axis.utils.NSStack();
namespaceList .add(”http://a.b.c./…”, “ns1″);
namespaceList .add(”http://x.y.z./…”, “ns2″);
soapRespEnv.setNSMappings(namespaceList .cloneFrame());

Where as soapRespEnv is SOAP response envelope fetched from MessageContext. So what will above code do is, it will notify Axis engine to aggregate SOAP response namespaces in the SOAP envelope root. your response would look like below after above change

<SOAP ENV. xmlns:ns1=”http://a.b.c/….” xmlns:ns2=”http://x.y.z/….”>
<SOAP Header..>
</SOAP Header..>
<SOAP body>
<ns1:elemenntname xsi:type=”xsd:string”>
<ns1:elemenntname xsi:type=”xsd:string”>

<ns2:elemenntname xsi:type=”xsd:string”>

</SOAP body>
</SOAP Env…>

benefitof above approach is

* Sheer data size reduction, that goes over the wire
* SOAP response looks like very clean.