Hi, Can we configure the JAX-WS enpoint URLs ? I mean like https://localhost:8080/services/UDDIInquiryService?wsdl TO http://localhost:8080/juddiv3/services/inquiry?wsdl. Is there a service.xml that we can edit ?
On Wed, May 8, 2013 at 5:29 PM, Subash Chaturanga <[email protected]>wrote: > > > On Wed, May 8, 2013 at 5:08 PM, Alex O'Ree <[email protected]> wrote: > >> 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, > > > You mean the JAX-WS endpoints ? Those are there. I can view the WSDLs and > call them via SOAPUI. (tried with InquiryService) > > >> 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 >> > >> > > > > -- > 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
