I don't know exactly how to change it, but I'm pretty sure it can be done. Check the documentation on Apache CXF (good luck). I think it's defined in the beans.xml file on the server. You should be able to adjust the path from there.
Alternatively, you can use a URL rewriter to sort of make an alias. On Fri, May 10, 2013 at 3:47 AM, Subash Chaturanga <[email protected]> wrote: > 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 >
