Bug 779232 (SOA-1625)

Summary:	jUDDI v3 services not available (inc. login to jUDDI console) in ER4
Product:	[JBoss] JBoss Enterprise SOA Platform 5	Reporter:	Len DiMaggio <ldimaggi>
Component:	Monitoring and Management	Assignee:	trev <tkirby>
Status:	CLOSED NEXTRELEASE	QA Contact:
Severity:	urgent	Docs Contact:
Priority:	urgent
Version:	5.0.0 ER4
Target Milestone:	---
Target Release:	5.0.0 GA, 5.0.0 ER5
Hardware:	Unspecified
OS:	Unspecified
URL:	http://jira.jboss.org/jira/browse/SOA-1625
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:	ER4 build
Last Closed:	2009-12-11 18:11:51 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Len DiMaggio 2009-11-21 04:18:57 UTC

Date of First Response: 2009-11-23 05:30:22
project_key: SOA

The exception raised is:  

22:30:53,011 ERROR [SecurityServiceImpl] Could not obtain token. Cannot parse wsdlLocation: http://localhost:8080/juddiv3/services/security?wsdl
org.apache.juddi.v3.client.transport.TransportException: Cannot parse wsdlLocation: http://localhost:8080/juddiv3/services/security?wsdl
        at org.apache.juddi.v3.client.transport.JAXWSTransport.getUDDISecurityService(JAXWSTransport.java:79)
        at org.apache.juddi.v3.client.transport.Transport.getUDDISecurityService(Transport.java:56)
        at org.apache.juddi.portlets.server.service.SecurityServiceImpl.login(SecurityServiceImpl.java:124)
        at org.apache.juddi.portlets.server.service.SecurityServiceImpl.get(SecurityServiceImpl.java:76)
        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.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:527)
        at com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:164)
        at com.google.gwt.user.server.rpc.RemoteServiceServlet.doPost(RemoteServiceServlet.java:86)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
        at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
        at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
        at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
        at java.lang.Thread.run(Thread.java:619)
Caused by: org.jboss.ws.metadata.wsdl.WSDLException: Cannot parse wsdlLocation:http://localhost:8080/juddiv3/services/security?wsdl
        at org.jboss.ws.tools.wsdl.WSDLDefinitionsFactory.getDocument(WSDLDefinitionsFactory.java:191)
        at org.jboss.ws.tools.wsdl.WSDLDefinitionsFactory.parse(WSDLDefinitionsFactory.java:109)
        at org.jboss.ws.metadata.umdm.ServiceMetaData.getWsdlDefinitions(ServiceMetaData.java:293)
        at org.jboss.ws.metadata.builder.jaxws.JAXWSClientMetaDataBuilder.buildMetaData(JAXWSClientMetaDataBuilder.java:84)
        at org.jboss.ws.core.jaxws.spi.ServiceDelegateImpl.<init>(ServiceDelegateImpl.java:137)
        at org.jboss.ws.core.jaxws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:63)
        at javax.xml.ws.Service.<init>(Service.java:79)
        at javax.xml.ws.Service.create(Service.java:96)
        at org.apache.juddi.v3.client.transport.JAXWSTransport.getUDDISecurityService(JAXWSTransport.java:76)
        ... 32 more
Caused by: java.io.FileNotFoundException: http://localhost:8080/juddiv3/services/security?wsdl
        at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1311)
        at java.net.URL.openStream(URL.java:1010)
        at org.jboss.ws.core.utils.ResourceURL.openStream(ResourceURL.java:55)
        at org.jboss.ws.tools.wsdl.WSDLDefinitionsFactory.getDocument(WSDLDefinitionsFactory.java:167)
        ... 40 more

Comment 1 Kevin Conner 2009-11-23 10:30:22 UTC

Why is the console using non-existent WS endpoints?  Why is it not using the local transport???

Comment 2 trev 2009-12-01 16:25:50 UTC

this has been fixed, a build patch works round this issue , the patch should be removed when the next esb merge is taken by the build

Comment 3 Len DiMaggio 2009-12-07 13:10:12 UTC

So - in ER5 - these endpoints will be supported?

     <!-- JAX-WS Transport
     <proxyTransport>org.apache.juddi.v3.client.transport.JAXWSTransport</proxyTransport>
     <custodyTransferUrl>http://${serverName}:${serverPort}/juddiv3/services/custody-transfer?
wsdl</custodyTransferUrl>
    <inquiryUrl>http://${serverName}:${serverPort}/juddiv3/services/inquiry?wsdl</inquiryUrl>
    <publishUrl>http://${serverName}:${serverPort}/juddiv3/services/publish?wsdl</publishUrl>
    <securityUrl>http://${serverName}:${serverPort}/juddiv3/services/security?wsdl</
securityUrl>
    <subscriptionUrl>http://${serverName}:${serverPort}/juddiv3/services/subscription?wsdl</
subscriptionUrl>
    <subscriptionListenerUrl>http://${serverName}:${serverPort}/juddiv3/services/subscription-
listener?wsdl</subscriptionListenerUrl>
    <juddiApiUrl>http://${serverName}:${serverPort}/juddiv3/services/juddi-api?wsdl</
juddiApiUrl>
     -->

Comment 4 Kevin Conner 2009-12-07 13:35:38 UTC

The webservices are a separate issue but have been done as part of JBESB-2983.

We have our own implementation, because of a juddi deployment issue, and will provide all the services within the WSDL.

/services/custody-transfer
/services/inquiry
/services/publish
/services/replication
/services/security
/services/subscription
/services/subscription-listener
/services/valuesetcaching
/services/valuesetvalidation

The webservices are untested by us, however, as we do not make use of them.

Comment 6 Len DiMaggio 2009-12-07 17:04:26 UTC

Link: Added: This issue related SOA-1632

Comment 7 Len DiMaggio 2009-12-07 17:11:13 UTC

Link: Added: This issue related SOA-1657

Comment 8 Len DiMaggio 2009-12-11 18:11:50 UTC

Verified in ER5

Comment 9 Jiri Locker 2010-01-06 15:55:58 UTC

Link: Added: This issue related SOA-1775

Comment 10 Kevin Conner 2010-01-07 08:53:20 UTC

Link: Removed: This issue related SOA-1775