Client side, what JRE/JDK are you using? Server side, what JRE/JDK are you using? what application server are you using? Which UDDI server is and what version? It is the tomcat bundle or something else? Finally, check the logs on the server side and see if there's anything out of the ordinary.
Looking back at the code for that sample, it will only work on jUDDI v3.x. If its a non-JUDDI server, remove anything related to juddiApi. It's a jUDDI specific web service that we're probably going to get rid of eventually. It's more of an administrative type service that provides functions above and beyond the UDDI spec On Wed, May 8, 2013 at 5:47 AM, Subash Chaturanga <[email protected]> wrote: > Thanks Alex, > This is exactly what I was looking for ;-). > > In the simple publisher example, I am getting following error when calling > security.getAuthToken(getAuthTokenRoot); I have edited the > simple-publish-uddi.xml to point to the correct JAX-WS service endpoints. > > javax.xml.ws.WebServiceException: java.net.SocketException: Unexpected end > of file from server > at > com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.readResponseCodeAndMessage(HttpClientTransport.java:201) > at > com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.process(HttpTransportPipe.java:151) > at > com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.processRequest(HttpTransportPipe.java:83) > at > com.sun.xml.internal.ws.transport.DeferredTransportPipe.processRequest(DeferredTransportPipe.java:105) > at com.sun.xml.internal.ws.api.pipe.Fiber.__doRun(Fiber.java:587) > at com.sun.xml.internal.ws.api.pipe.Fiber._doRun(Fiber.java:546) > at com.sun.xml.internal.ws.api.pipe.Fiber.doRun(Fiber.java:531) > at com.sun.xml.internal.ws.api.pipe.Fiber.runSync(Fiber.java:428) > at com.sun.xml.internal.ws.client.Stub.process(Stub.java:211) > at com.sun.xml.internal.ws.client.sei.SEIStub.doProcess(SEIStub.java:124) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:98) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78) > at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107) > at $Proxy41.savePublisher(Unknown Source) > at > org.apache.juddi.example.publish.SimplePublish.publish(SimplePublish.java:75) > at > org.apache.juddi.example.publish.SimplePublish.main(SimplePublish.java:135) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) > Caused by: java.net.SocketException: Unexpected end of file from server > at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:769) > at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:632) > at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:766) > at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:632) > at > sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1195) > at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:379) > at com.sun.xml.internal.ws.tran > > On Wed, May 8, 2013 at 4:31 AM, Alex O'Ree <[email protected]> wrote: >> >> There's a number of examples in the source code. >> http://svn.apache.org/viewvc/juddi/trunk/juddi-examples/ >> >> Be forewarned, this is from the latest development trunk. One class, >> UDDIConstants is probably not in your juddi-client jar file. It's >> fairly easy to figure out what the values represent from this link: >> >> http://svn.apache.org/viewvc/juddi/trunk/juddi-client/src/main/java/org/apache/juddi/v3/client/UDDIConstants.java?view=markup >> >> There's additional samples in the 3.2 branch which hasn't been >> integrated into maven yet and rely on some of the 3.2 functions (still >> very beta) >> >> http://svn.apache.org/viewvc/juddi/branches/juddi-3.2.x/juddi-examples/uddi-createbulk/src/uddi/createbulk/ >> >> At the very least, it should give you some examples that should easily >> translate into whatever you're trying to build >> >> On Tue, May 7, 2013 at 3:28 PM, Subash Chaturanga <[email protected]> >> wrote: >> > >> > >> > On Mon, May 6, 2013 at 8:39 PM, Kurt T Stam <[email protected]> wrote: >> >> >> >> Hi Subash, >> >> >> >> As Alex already said, that would be in a bindingTemplate - in the >> >> accessPoint, with a useType of "wdslDeployment" >> > >> > Thanks Kurt, >> > Useful information!. Do you have any documentation on how to use >> > juddi-client API to connect to the UDDI registry ? >> > >> >> >> >> >> >> See: >> >> http://uddi.org/pubs/uddi_v3.htm#_Toc85908387 >> >> >> >> Using the "wsdlDeployment" value >> >> >> >> Instead of directly providing the network address in the accessPoint, >> >> it >> >> is occasionally useful or necessary to provide this information through >> >> indirect means. One common scenario for such a behavior is when the >> >> accessPoint is embedded within a WSDL file. In such a scenario, the >> >> UDDI >> >> accessPoint contains the address of the WSDL file, and the client then >> >> must >> >> retrieve the WSDL file and extract the end point address from the WSDL >> >> file >> >> itself. >> >> >> >> In this case, decorating the UDDI accessPoint with a >> >> useType="wsdlDeployment" is appropriate. A sample of such behavior is >> >> as >> >> follows: >> >> >> >> <bindingTemplate bindingKey="uddi:example.org:catalog"> >> >> <description xml:lang="en"> >> >> Browse catalog Web service >> >> </description> >> >> <accessPoint useType="wsdlDeployment"> >> >> http://www.example.org/CatalogWebService/catalog.wsdl >> >> </accessPoint> >> >> >> >> <categoryBag> >> >> <keyedReference keyName="uddi-org:types:wsdl" >> >> keyValue="wsdlDeployment" >> >> tModelKey="uddi:uddi.org:categorization:types"/> >> >> </categoryBag> >> >> </bindingTemplate> >> >> >> >> >> >> In the example above, a client would be able to parse the result of the >> >> bindingTemplate and determine the end point of the Web service within >> >> the >> >> WSDL file discovered in the accessPoint element. Note that the >> >> bindingTemplate has also been categorized with the "wsdlDeployment" >> >> value >> >> from the uddi.org:categorization:types scheme so that it can be >> >> discovered >> >> through a find_binding API call. >> >> >> >> Cheers, >> >> >> >> --Kurt >> >> >> >> >> >> On 5/6/13 7:25 AM, Subash Chaturanga wrote: >> >> >> >> >> >> >> >> On Mon, May 6, 2013 at 4:40 PM, Alex O'Ree <[email protected]> >> >> wrote: >> >>> >> >>> Business > Service > Binding Template > Access Point >> >>> Value = usually a URL >> >>> UseType = wsdlDeployment, endPoint, hostingRedirector, or something >> >>> else that makes sense to you. The "useType" attribute is a descriptor >> >>> telling you want the value means. >> >>> >> >>> Kurt is currently working on implementing the WSDL to UDDI Technical >> >>> Note from OASIS that defines how to map Port Type and many of the >> >>> other WSDL elements into a UDDI structure. Overview URL can be used >> >>> for a WSDL location too. I"m sure Kurt will be answer to answer this >> >>> with more detail. The WSDL2UDDI should be in the next release 3.1.5 >> >>> which should hopefully be very soon (maybe next week) >> >> >> >> >> >> Thanks Alex, >> >> Would want to know what is the most appropriate place for a WSDL URL to >> >> reside in UDDI world . >> >>> >> >>> >> >>> >> >>> On Mon, May 6, 2013 at 6:54 AM, Subash Chaturanga >> >>> <[email protected]> >> >>> wrote: >> >>> > Hi, >> >>> > In the use case of adding a WSDL to UDDI registry through JUDDI, I >> >>> > would >> >>> > like to know where in general juddi allows to put the WSDL url ? I >> >>> > can >> >>> > see >> >>> > following two options . I would like to know the recommended, mostly >> >>> > used >> >>> > way to retrieve the WSDL url from a business entity. >> >>> > >> >>> > Is it BindingTemplate#getAccessPointUrl() ? (I happen to notice that >> >>> > this is >> >>> > not a direct WSDL like URL, I mean like ...?wsdl, but a service >> >>> > endpoint ) >> >>> > Is it TmodelInstanceInfo#getOverviewDocs()#getOverviewUrl() ? In >> >>> > this >> >>> > case >> >>> > as I know each WSDL port type maps to a TModel, if so for each >> >>> > TModels >> >>> > I >> >>> > have for a particular WSDL should have the same overview URL ? >> >>> > >> >>> > Thanks >> >>> > -- >> >>> > Subash Chaturanga >> >>> > Sri Lanka >> >>> > >> >>> > Blog - http://subashsdm.blogspot.com/ >> >>> > Twitter - http://twitter.com/subash89 >> >>> > >> >> >> >> >> >> >> >> >> >> -- >> >> Subash Chaturanga >> >> Department of Computer Science & Engineering >> >> University of Moratuwa >> >> Sri Lanka >> >> >> >> Blog - http://subashsdm.blogspot.com/ >> >> Twitter - http://twitter.com/subash89 >> >> >> >> >> >> >> > >> > >> > >> > -- >> > Subash Chaturanga >> > Department of Computer Science & Engineering >> > University of Moratuwa >> > Sri Lanka >> > >> > Blog - http://subashsdm.blogspot.com/ >> > Twitter - http://twitter.com/subash89 >> > > > > > > -- > Subash Chaturanga > Department of Computer Science & Engineering > University of Moratuwa > Sri Lanka > > Blog - http://subashsdm.blogspot.com/ > Twitter - http://twitter.com/subash89 >
