Quickie. Upping Memory for Tomcat and Railo 3.1

Sometimes it's just not hard to be a bit of a fan-boy. Yesterday afternoon I added a new post about Flex and Web Services that require more complex headers to be assigned. I realized later that evening that I did not see the post show up in my Reader from the Adobe MXNA feed.

This morning, out of curiosity, I decided to check the MXNA site to see if the post was aggregated but I just missed it. Turns out my site disappeared from MXNA. Naturally, I was a bit bummed but, really, it wasn't a big deal. I felt pretty good that I didn't do something "wrong", so I resubmitted my blog.

Before navigating away from MXNA, I dropped them a note to ask if there would have been any particular reason a site would be dropped. A few hours later I received a nice note from a member of the MXNA team at Adobe. The gentleman was very nice and apologized that my blog was removed and informed me that it was due to a technical issue related to their DB (kind of nice to know the "big boys" have these troubles, too :). He advised me just to resubmit my site. I replied to thank him and let him know it was no problem and that I did resubmit my site this morning.

And this is where I have to give some props and kudos to Adobe. Within a matter of minutes from my reply, the gentleman had replied back to let me know he found my submission and approved it so I was back in action.

I know this is a small thing and, perhaps, not worthy of a post. But I really think it speaks volumes about the kind of people and attitude at Adobe. It was an example of excellent customer service.

I think we developers (myself included!) often take corporations to task for behavior or practices we find bothersome, wrong, etc. Yet, when those same companies do right by their customers or take that extra step, we fail to give them the credit for it. So, in that vein, thank you MXNA/Adobe. You guys rock!

In my ongoing Flex/.NET Web Service hell, I've come across a solution to remove all the namespaces from the SOAP XML returned from a (.NET) Web Service.

You might be wondering why one would need to strip XML namespaces from the SOAP response. The long and short of it is that there are known bugs (that Adobe will not fix for v3.x but is fixed in Gumbo/v4) in the Flex 3 SDKs related to the auto-generation of AS3 classes from a WSDL file and the subsequent decoding of complex SOAP XML objects to their corresponding ActionScript objects. In brief, Flex doesn't create the AS3 classes "properly" such that they can decode the response how a developer not only would expect but also need. Google "SOAP decoding error Flex 3 .NET" and you should get plenty of information, or just skim through some of my Flex-labeled posts.

You can fight with this and waste hours upon hours, days upon days, and weeks upon weeks (like me -- this whole thing made me realize how stubborn I am/can be). Or, you can take a somewhat more efficient, if not more intelligent, approach and revert to using Flex's WebService class for methods that throw errors, manipulating the returned SOAP XML manually.

An issue (I use 'issue' very loosely here) with the e4x format in ActionScript is that namespaces in your XML will make it hard to impossible to work with the XML. Ultimately, in my opinion, one is better off simply stripping all the namespaces out of the XML. I initially tried to go about this programmatically, using properties of the XML class (i.e., namespace). This had mixed results and took up a lot of my time. So, this morning, with the help of some good blog posts and forum topics, I found a nice function that cleanly strips out all the namespace data from an XML file and returns a "clean" XML string.

I want to stress that the code from the following function is not mine. I found it on ActionScript.org's Forums. Scroll down to the question titled 'How do I strip all namespaces from the XML?'

If you don't want to go to that site, the function to strip namespaces follows with minor edits to the author's post (above) in order to fit the process into my app:

private function reportHistoryReceived( evt:ResultEvent ):void
{
 var dsReport:XMLList; // the parent of the next var, below, in the SOAP result XML
 var reportHistory:XMLList; // the XML list that contains the elements I ultimately want from the SOAP XML
 var xml:XML; // the XML that will be 'cleaned' of namespaces
 var item:XML; // the variable to be used in my for..each loop below
 var respXML:XML; // the raw XML from the result event
 var xmlSource:String; // the string representation of the response XML (respXML)
 respXML = evt.result[0] as XML;
 xmlSource = respXML.toXMLString();   
 xmlSource = xmlSource.replace(/<[^!?]?[^>]+?>/g, removeNamspaces); // will invoke the function detailed below
 xml = XML(xmlSource); // take the cleaned XML string and parse it back to valid XML
 dsReport = xml..*::DsReport; // grabbing the parent element of the returned data
 reportHistory = dsReport.children(); // the specific items of data being returned from the Web Service
 for each( item in reportHistory ) // looping over the reportHistory elements to act on them
 {
  trace( "XML Item Study: " + item.Study ); // ye ole boring trace statement :)
 } 
}
// the sweet little cleaner function from a User named: wvxvw (THANKS DUDE, OR DUDETTE!!!!)
private function removeNamspaces(...rest):String
{
    rest[0] = rest[0].replace(/xmlns[^"]+\"[^"]+\"/g, "");
    var attrs:Array = rest[0].match(/\"[^"]*\"/g);
    rest[0] = rest[0].replace(/\"[^"]*\"/g, "%attribute value%");
    rest[0] = rest[0].replace(/(<\/?|\s)\w+\:/g, "$1");
    while (rest[0].indexOf("%attribute value%") > 0)
    {
        rest[0] = rest[0].replace("%attribute value%", attrs.shift());
    }
    return rest[0];
}

The first function, reportHistoryReceived is invoked when the Web Service returns its successful result. I've commented out the function, line by line, to explain what it's doing with each step.

There is one thing I wanted to point out for anyone out there, like me, who might be looking at the parameter of the removeNamespace function and wondering what the hell '...rest' is. Rather than try to explain it myself, I think the person below did an excellent job.

"The ...rest parameter is a special parameter placed at the end of a parameter list in a function that specifies that there can be any number of additional arguments of any type passed into that function when its called. The form of the parameter is 3 periods followed by a keyword. When the function is called, the additional arguments are assigned to that keyword in the form of an array."

-Source: Kirupa.com


I have somehow missed this little gem thus far in my Flex/AS3 life (not to mention other languages) but think it's a nice, little tool to add to our arsenals!