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

Reply via email to