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
