Juddi.version.jar is not the same as the Juddiv3.war deployment. Kurt can correct me if I'm wrong, but I think that juddi.jar does not include the web service endpoints, only the war file does. I'm pretty sure you need the war file deployed to the server.
You may also want to consider upgrading once 3.1.5 comes out. On Wed, May 8, 2013 at 7:33 AM, Subash Chaturanga <[email protected]> wrote: > > Sorry that I didn't provide enough info. > > It is the client side I am getting this. In server side we are using juddi > jar, in axis2/OSGi environment. This should be something simple that I am > missing. And using juddi 3.0.3 in JDK 6..On the server side, with in JVM > calls using UDDIPublicationImpl and etc the same code works fine. This > happens on client side. > > On Wed, May 8, 2013 at 4:33 PM, Alex O'Ree <[email protected]> wrote: >> >> 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 >> > > > > > > -- > Subash Chaturanga > Department of Computer Science & Engineering > University of Moratuwa > Sri Lanka > > Blog - http://subashsdm.blogspot.com/ > Twitter - http://twitter.com/subash89 >
