Hi see comments inline. On Wed, Jul 1, 2009 at 3:01 AM, Bhat, Suma <[email protected]> wrote:
> The product that I work on has a web services API which consists of > several specialized services. This api works off of axis2 1.3 currently. I > have been tasked with upgrading this to use axis2 1.4.1 or axis2 1.5. > > Minimally, I need to get a successful compile of our baseline and have all > web service junit tests (which consist of java test clients) run > successfully to consider an upgrade to 1.4.1 or 1.5 successful. The task has > been a lot harder than I imagined thanks to the roadblocks I describe below. > > > > I first tried to upgrade to axis2 1.5. > > > > I ran into issues which seem to stem from the fact that schema type for > java.util.Date has changed from xs:dateTime to xs:date in this version of > axis. The below thread discusses the same and one of the authors(Pétur > Runólfsson) mentions a patch to fix the problem, but I can’t seem to find > it. Could you point me to this patch ? or is this something that has been > integrated into the axis2 baseline ? I do like the idea of being able to > specify a service parameter to have the java.util.Date attribute as a > xs:dateTime type. > > http://osdir.com/ml/axis-dev-ws.apache.org/2009-06/msg00162.html > > An alternate suggestion was to change the Date type attribute to Calendar > type attribute, which would affect the service interface and we don’t want > to do that. > Yes this was done in order to fix a bug. What you could do is this change the return type in your service class from Date to Calendar, this will not break the interface cause your interface is the WSDL and that would stay the same with this change. > > > Then, I tried upgrading to axis2 1.4.1, no date/dateTime problems here, but > instead I get several exceptions with stack traces that look like below when > I run the junits. > > )org.apache.axiom.om.OMException: java.lang.NullPointerException > > at > org.apache.axiom.om.impl.builder.StAXOMBuilder.next(StAXOMBuilder.java:249) > > at > org.apache.axiom.om.impl.llom.OMNodeImpl.build(OMNodeImpl.java:327) > > at > org.apache.axiom.om.impl.llom.OMElementImpl.build(OMElementImpl.java:706) > > at > org.apache.axiom.om.impl.llom.OMElementImpl.detach(OMElementImpl.java:675) > > at > org.apache.axiom.om.impl.llom.OMNodeImpl.setParent(OMNodeImpl.java:124) > > at > org.apache.axiom.om.impl.llom.OMElementImpl.addChild(OMElementImpl.java:274) > > at > org.apache.axiom.om.impl.llom.OMElementImpl.addChild(OMElementImpl.java:203) > > at > org.apache.axiom.soap.impl.llom.SOAPBodyImpl.addChild(SOAPBodyImpl.java:231) > > at > org.apache.axis2.client.ServiceClient.fillSOAPEnvelope(ServiceClient.java:713) > > at > org.apache.axis2.client.ServiceClient.sendReceive(ServiceClient.java:545) > > at > org.apache.axis2.client.ServiceClient.sendReceive(ServiceClient.java:528) > > at > org.apache.axis2.rpc.client.RPCServiceClient.invokeBlocking(RPCServiceClient.java:102) > > at > com.bmc.bcan.ws.client.DeviceServiceStub.getDevices(DeviceServiceStub.java:86) > > at > com.bmc.bcan.ws.DeviceServiceTest.testGetDevicesGood(DeviceServiceTest.java:287) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > > Caused by: java.lang.NullPointerException > > at > org.apache.axis2.databinding.utils.BeanUtil.getPullParser(BeanUtil.java:137) > > at > org.apache.axis2.databinding.utils.reader.ADBXMLStreamReaderImpl.processProperties(ADBXMLStreamReaderImpl.java:989) > > at > org.apache.axis2.databinding.utils.reader.ADBXMLStreamReaderImpl.next(ADBXMLStreamReaderImpl.java:855) > > at org.apache.axis2.util.StreamWrapper.next(StreamWrapper.java:71) > > at > org.apache.axiom.om.impl.builder.StAXOMBuilder.parserNext(StAXOMBuilder.java:506) > > at > org.apache.axiom.om.impl.builder.StAXOMBuilder.next(StAXOMBuilder.java:161) > I think I know the problem you are facing here cause I have seen the same before. Again you see this because of a bug that was fixed. The reason is this previously if a method required two parameters named foo and bar you could have got away with sending two parameters named car and bar. But now axis2 checks the local name of the element. Fixing this will need changes in your clients probably (If they have bug compatible code :)). Thanks, Keith. > > > Searching the forums led me to several dated emails that talk about similar > problems when dealing with Collection objects and the suggestion was to use > arrays instead. But in our case we don’t have collections but arrays of a > complex type objects which is supposed to work. What maybe going on here ? > > > > Any help that will keep me going with upgrading to either 1.5 or 1.4.1 or > both will be greatly appreciated. > > > > Thanks, > > Suma > > > > > > > > > -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
