1. at line 50 of the NotificationServiceImpl it get its connection info
from the current server:
URL url = new URL(getThreadLocalRequest().getScheme(),
getThreadLocalRequest().getRemoteHost(),
getThreadLocalRequest().getLocalPort(),
"/juddiv3/notify/");
which really should be the remote jUDDI server! Can you please add a
jira for this?
Until then you could undeploy the SubscriptionNotificationPortlet to get
rid of the error.
2. What is the issue with the browser portlet? Do you mean that the
endpoint references 'localhost'?
If so then you have to set the correct for the server and port info in
the juddiv3.properties file. These values are then to populate the seed
data, at which time property replacement takes place. Note that this
will only happen on an empty database. Hopefully the console will allow
editing soon, so that you can modify things after the fact.
Hope this helps!
--Kurt
Natalie Turner wrote:
My jUDDI Publisher Portlet is hitting the jUDDI instance ok and
listing all of the publishers, but when I'm in the UDDI Browser
Portlet, you can see the screenshot says localhost:8080, when I've
changed the uddi.xml to acs-v1-r1-dev-node2:8180.
I'm also getting a notify error and I'm pretty sure it's because I
changed. Should this be looking at the uddi-portlet or the juddi
server?
2009-11-19 14:05:29,098 ERROR
[org.apache.juddi.portlets.server.service.NotifyServiceImpl] - Could
not obtain token. http://acs-v1-r1-dev-node2:818
0/juddiv3/notify/
java.io.FileNotFoundException: http://acs-v1-r1-dev-node2:8180/juddiv3/notify/
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1267)
at
org.apache.juddi.portlets.server.service.NotifyServiceImpl.getSubscriptionNotifications(NotifyServiceImpl.java:54)
at sun.reflect.GeneratedMethodAccessor285.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
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:230)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:173)
at
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182)
at
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:636)
Thanks for the quick feedback!
On Thu, 2009-11-19 at 14:17 -0500, Kurt T Stam wrote:
webapps/uddi-portlets/WEB-INF/classes/META-INF/uddi.xml
defines the juddi-server settings:
<uddi>
<reloadDelay>5000</reloadDelay>
<manager name="uddi-portlet-manager">
<nodes>
<node>
<name>default-ws</name>
<properties>
<property name="serverName"
value="remotehost"/>
<property name="serverPort"
value="8080"/>
<property name="rmiPort"
value="1099"/>
</properties>
<description>Main jUDDI node</description>
<!-- JAX-WS Transport -->
<proxyTransport>org.apache.juddi.v3.client.transport.JAXWSTransport</proxyTransport>
<custodyTransferUrl>http://${serverName}:${serverPort}/juddiv3/services/custody-transfer?wsdl</custodyTransferUrl>
and it is using JAX-WS transport by default, so really just these two
settings should matter:
<property name="serverName" value="remotehost"/>
<property name="serverPort" value="8080"/>
GWT is talking client (browser) - server (GWT widgets), then the widgets
talk the to UDDI server. So it maybe a bit confusing which 'server'
cannot be found.
So yeah some more info would be great.
--Kurt
Tom Cunningham wrote:
> Nathalie,
>
> Can you give us some more details, maybe a screenshot and an
> explanation of what the wsdlDeployment URL so we can try to
> reproduce? Stacktrace would be good too.
>
> Thanks,
>
> Tom
>
> Natalie Turner wrote:
>> I've deployed the jUDDI v3 uddi-portlets-3.0.1-SNAPSHOT.war to my
>> JBoss portal and when I bring up the UDDI Browser Portlet, the
>> wsdlDeployment URL is incorrect. My portal happens to be on the same
>> system as the juddi instance, but I'm not using localhost and I'm
>> using a different port. I have tried configuring this in several
>> different locations and rebuilding the uddi-portlets war to no
>> avail. Any suggestions?
>>
>> I appreciate it!
>>
>> Thanks,
>>
>> Natalie
>>
>>
>
>
------------------------------------------------------------------------
