You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by "Bhat, Suma" <Su...@bmc.com> on 2009/06/30 23:31:54 UTC

Unable to upgrade to axis2 1.4.1 or 1.5

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.

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)

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

Re: Unable to upgrade to axis2 1.4.1 or 1.5

Posted by keith chapman <ke...@gmail.com>.
Hi see comments inline.

On Wed, Jul 1, 2009 at 3:01 AM, Bhat, Suma <Su...@bmc.com> 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