Kurt, Thank you for your message. We shall test more and let you know.
In response to your other question on my subscription to the list, I was naively using an Old Nabble list (http://old.nabble.com/jUDDI---User-f240.html). I haven't investigated much about Old Nabble. Thank you. --- On Sun, 4/24/11, Kurt T Stam <[email protected]> wrote: From: Kurt T Stam <[email protected]> Subject: Re: Changes required to the client code ?? (when switched from HP to jUDDI v3.0.4) To: [email protected], [email protected] Date: Sunday, April 24, 2011, 11:28 AM Hi cli_dc, Since we are now a top level project our mailing list is [email protected]. When did you subscribe? I'm just wondering how you ended up using our old mailing list. Anyway the reply is here: http://mail-archives.apache.org/mod_mbox/juddi-user/201104.mbox/browser Thx, --Kurt On 4/24/11 8:42 AM, cli_dc wrote: Kurt or anyone, any luck ? Can you reply with your opinion please ? Please see my question below - we need your help in knowing where we make mistake, or if we miss anything. Thank you. cli_dc wrote: We had to change our UDDI-client code a little when we switched our UDDI server backend !! That was a surprise to us !! Below are the details. Please suggest what is missing -- it's puzzling, and we need to solve this puzzle. Question: Why client code change is necessary when we switch from HP to jUDDI v3.0.4 ? Details: We switched our backend UDDI registry instance from HP to jUDDI v3.0.4. [Note that: The HP registry is also UDDI spec v3 compliant.] After the jUDDI instance started, we ran our existing piece of code (as included below) and ran into "org.uddi.v3_service.DispositionReportFaultMessage: At least one search criterion must be supplied". Stack Trace: Caused by: org.uddi.v3_service.DispositionReportFaultMessage: At least one search criterion must be supplied at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at com.sun.xml.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:141) at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:119) at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:89) at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:140) at $Proxy41.findBusiness(Unknown Source) at org.mine.connectmgr.uddi.MyUDDIAccessor.retrieveBizInfo(MyUDDIAccessor.java:581) Code that works on HP: UDDIInquiryPortType oInq = getUDDIInqWebSvc(); FindBusiness oFindBiz = new FindBusiness(); oFindBiz.setMaxRows(100); oBusinessList = oInq.findBusiness(oFindBiz); Code (with additions) that works on jUDDI v3: UDDIInquiryPortType oInq = getUDDIInqWebSvc(); FindBusiness oFindBiz = new FindBusiness(); Name findName = new Name(); // new code FindQualifiers qualifiers = new FindQualifiers(); // new code findName.setValue("%"); // new code qualifiers.getFindQualifier().add("approximateMatch");// new code oFindBiz.getName().add(findName); // new code oFindBiz.setFindQualifiers(qualifiers); // new code oFindBiz.setMaxRows(100); oBusinessList = oInq.findBusiness(oFindBiz); Thanks! Is the code change (// new code) necessary to get rid of org.uddi.v3_service.DispositionReportFaultMessage ? What are we missing ?? Please let us know at your earliest. View this message in context: Re: Changes required to the client code ?? (when switched from HP to jUDDI v3.0.4) Sent from the jUDDI - User mailing list archive at Nabble.com.
