DataServices NameSpace magic
In SVN under the wsas Version 2.2 in revision 12176
You will see that a large overhaul was done to the DBUtils.java which seems to be a fix for "complex queries". The end result of this fix was now there are namespaces dynamically generated for every call to a dataservice. Which I'm not convinced shouldn't be optional... and at least some kind of documentation for this significant of a change could be in order? This line is giving us the grief
prefix = DBConstants.RESULT_PREFIX+BeanUtil.getUniquePrefix();
where it's generating a unique prefix every time through.
We are seeing a bit of difficulty parsing the response of a data service from php, when the namespace is changing every time. Or maybe I'm just corn-fused about how namespaces work, and our parsing method in php needs an overhaul. Either way, I think it should be optional whether or not to auto-generate a namespace (because wsas 2.1 didn't do it, and it worked fine for 100% of what we were using it for).
as a side comment the big chunk of code making decisions about namespaces is also identically used in two similar methods... maybe it should be it's own method called twice?
fac = OMAbstractFactory.getOMFactory(); //get prefix for namespace
HashMap namespacePrefixMap = null; HashMap queryLevelNamespaceMap = null; HashMap queryLevelPrefixMap = null; if(axisService.getParameterValue(DBConstants.NAMESPACE_PREFIX_MAP)!= null){ namespacePrefixMap = (HashMap)axisService.getParameterValue(DBConstants.NAMESPACE_PREFIX_MAP); queryLevelNamespaceMap = (HashMap)axisService.getParameterValue(DBConstants.QUERYLEVEL_NAMESPACE_MAP); queryLevelPrefixMap = (HashMap)axisService.getParameterValue(DBConstants.QUERYLEVEL_PREFIX_MAP); prefix = (String)namespacePrefixMap.get(resultElementNS); if(prefix == null){ prefix = DBConstants.RESULT_PREFIX+BeanUtil.getUniquePrefix(); namespacePrefixMap.put(resultElementNS, prefix); queryLevelNamespaceMap.put(new Integer(queryLevel), resultElementNS); queryLevelPrefixMap.put(new Integer(queryLevel), prefix); } }else{ namespacePrefixMap = new HashMap(); queryLevelNamespaceMap = new HashMap(); queryLevelPrefixMap = new HashMap(); prefix = DBConstants.RESULT_PREFIX+BeanUtil.getUniquePrefix(); namespacePrefixMap.put(resultElementNS, prefix); queryLevelNamespaceMap.put(new Integer(queryLevel), resultElementNS); queryLevelPrefixMap.put(new Integer(queryLevel), prefix); axisService.addParameter(DBConstants.NAMESPACE_PREFIX_MAP,namespacePrefixMap); axisService.addParameter(DBConstants.QUERYLEVEL_NAMESPACE_MAP,queryLevelNamespaceMap); axisService.addParameter(DBConstants.QUERYLEVEL_PREFIX_MAP,queryLevelPrefixMap); } omNs = fac.createOMNamespace(resultElementNS, prefix);
thanks
- Login or register to post comments
- Printer friendly version
- 247 reads











Hi sveesible1, Welcome
Hi sveesible1,
Welcome back!!!!
Namespace qualifying was added to overcome problems when it comes to supporting nested queries. (Esp. in the area of automatic client stub generation,WSDL generation).
However you can parse the XML without any regard to namespace **prefix**. Please take a look @ following example.
This is the output from my data service.
Here is the PHP script parsing the above xml (test.xml).
Since I am not aware of your environment, this might not be applicable as it is. But I hope this helps.
/sumedha
Excellent
Your knowledge and assistance is much appreciated. I believe this will make our php endpoint work for us.
Thanks
Getting around the same problem with IE DOM
Additionally, if we send our dataservice data directly to an Internet Explorer 6 browser and use the browser Dom to parse the data into Javascript, the new random namespace prevents IE from properly parsing the xml, as it appears IE is not smart enough to deal with namespaces in it's DOM.
Yes, we've also found that
Yes, we've also found that IE cannot handle namespaces when developing the WSAS console.
Regards
Afkham Azeez