You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@juddi.apache.org by cli_dc <cl...@yahoo.com> on 2011/04/22 10:52:46 UTC
Changes required to the client code ?? (when switched from HP to
jUDDI v3.0.4)
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: http://old.nabble.com/Changes-required-to-the-client-code----%28when-switched-from-HP-to-jUDDI-v3.0.4%29-tp31455105p31455105.html
Sent from the jUDDI - User mailing list archive at Nabble.com.
Re: Changes required to the client code ?? (when switched from HP
to jUDDI v3.0.4)
Posted by Kurt T Stam <ku...@gmail.com>.
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 /<ku...@gmail.com>/* wrote:
>
>
> From: Kurt T Stam <ku...@gmail.com>
> Subject: Re: Changes required to the client code ?? (when switched
> from HP to jUDDI v3.0.4)
> To: user@juddi.apache.org, cli_dc@yahoo.com
> Date: Sunday, April 24, 2011, 11:28 AM
>
> Hi cli_dc,
>
> Since we are now a top level project our mailing list is
> user@juddi.apache.org </m...@juddi.apache.org>. 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.
>
Re: Changes required to the client code ?? (when switched from HP to jUDDI v3.0.4)
Posted by Computer Learning Inst <cl...@yahoo.com>.
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 <ku...@gmail.com> wrote:
From: Kurt T Stam <ku...@gmail.com>
Subject: Re: Changes required to the client code ?? (when switched from HP to jUDDI v3.0.4)
To: user@juddi.apache.org, cli_dc@yahoo.com
Date: Sunday, April 24, 2011, 11:28 AM
Hi cli_dc,
Since we are now a top level project our mailing list is
user@juddi.apache.org. 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.
Re: Changes required to the client code ?? (when switched from HP
to jUDDI v3.0.4)
Posted by Kurt T Stam <ku...@gmail.com>.
Hi cli_dc,
Since we are now a top level project our mailing list is
user@juddi.apache.org. 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.
Re: Changes required to the client code ?? (when switched from HP
to jUDDI v3.0.4)
Posted by cli_dc <cl...@yahoo.com>.
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: 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 at Nabble.com.
Re: Changes required to the client code ?? (when switched from HP
to jUDDI v3.0.4)
Posted by Kurt T Stam <ku...@gmail.com>.
Hi cli_dc,
All UDDI implementations will try to be compatible and implement the
spec as best as they can. However sometimes the spec maybe ambiguous,
and there is no TCK testsuite for UDDI (Although we started maintaining
one as part of the jUDDI project).
In short this means that you may find slight differences. I think we
implemented it the way we did because of this sentence in the spec:
http://uddi.org/pubs/uddi_v3.htm#_Toc85908086
"In the event that no matches were located for the specified criteria,
the bindingDetail structure returned is empty (i.e., it contains no
bindingTemplate data). This signifies a zero match result. If no
arguments are passed, a zero-match result set will be returned. "
So I think it says that if no arguments are passed to the
find_businesses, a zero-match should be returned. Please read this
section also to see if you agree with us.
We should see where (client or server) and how we should fix the
incompatibility. i.e. does HP still work ok if you give it the same
query you send to make jUDDI work? It maybe that HP allows some sort of
default behavior not really specified in the spec. We could do something
similar if needed, and add config option to turn this on/off.
Cheers,
--Kurt
On 4/22/11 4:52 AM, 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: 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-tp31455105p31455105.html>
> Sent from the jUDDI - User mailing list archive
> <http://old.nabble.com/jUDDI---User-f240.html> at Nabble.com.