Dc,
You can sign up for our mail-lists using the following page:
http://juddi.apache.org/mail-lists.html
Cheers,
--Kurt
On 4/25/11 3:13 AM, Computer Learning Inst wrote:
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] </mc/[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)
<http://old.nabble.com/Changes-required-to-the-client-code----%28when-switched-from-HP-to-jUDDI-v3.0.4%29-tp31455105p31466198.html>
Sent from the jUDDI - User mailing list archive
<http://old.nabble.com/jUDDI---User-f240.html> at Nabble.com.
