Kurt, Thanks for the reference. I looked over the example and it appears to utilize portlets to configure the subscriptions. The uddi.xml to configure the clerks is also part of the portlets.
Is use of these portlets required? I've been using the UDDI v3 services such as the UDDI Publication and Subscription to setup the two servers with the help of SoapUI. I searched the default UDDI Subscription message generated by SoapUI and couldn't find an element or attribute named clerk. Is the clerk entity part of UDDI or specific to jUDDI? Is there a way for to use the UDDI Subscription service (or another service) to create and associate the clerk with a subscription? If this can't be done using the UDDI Subscription service, how else can a clerk be created and associated with a subscription without using the portlet (entering database rows would be viable for me)? Sorry about not wanting to use a portlet, but I'm trying to automate the configuration of these servers. Thanks, Leon On Tue, Apr 19, 2011 at 5:19 PM, Kurt T Stam <[email protected]> wrote: > Hi Leon, > > If you are pushing changes from A to B, it should use B to obtain > a auth_token. You can specify the node to use in the clerk configuration > used by the subscription. This is defined in the uddi.xml. See also > the example referenced in chapter 10: > > http://juddi.apache.org/docs/3.0/userguide/html/chap-Subscription.html#sect-subscription_intro > > Are you able to get the example to work? I think this does exactly what you > want to be doing. > > Good luck, > > --Kurt > > On 4/19/11 5:02 PM, Leon Doud wrote: >> >> Hello, >> >> I'm trying to setup a subscription between two jUDDI servers. Server B >> has asynchronous subscription and subscription listener registered on >> server A. It appears that the SubscriptionNotifier is trying to push >> the changes from server A to server B, but the authentication is >> failing on server B. >> >> I noticed something strange after looking at the databases for server >> A and server B. The j3_auth_token table in server A's (the one pushing >> the changes) database has thousands of rows. Server B's j3_auth_token >> table has a few rows, all created on a previous day. If server A is >> pushing changes (generated by the subscription) to server B, shouldn't >> server A get the auth token from server B? I think because the auth >> token is being generated in server A's database so server B doesn't >> recognize it. >> >> Both servers are running jUDDI 3.0.1. I looked at the notify method >> for SubscriptionNotifier for both 3.0.1 and 3.0.4 and it appears to be >> coded to retrieve the auth token from the local server using the >> authorized name. Is there something I need to change in the >> subscription or the configuration of either server? Is server B really >> supposed to accept a token generated by server A? >> >> Here is the stack trace I get: >> >> 2011-04-19 16:41:50,229 ERROR >> [org.apache.juddi.subscription.SubscriptionNotifier] - Invalid >> authentication information >> javax.xml.ws.soap.SOAPFaultException: Invalid authentication information >> at >> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:145) >> at $Proxy85.notifySubscriptionListener(Unknown Source) >> at >> org.apache.juddi.subscription.SubscriptionNotifier.notify(SubscriptionNotifier.java:241) >> at >> org.apache.juddi.subscription.SubscriptionNotifier.run(SubscriptionNotifier.java:93) >> at java.util.TimerThread.mainLoop(Timer.java:512) >> at java.util.TimerThread.run(Timer.java:462) >> Caused by: org.apache.cxf.binding.soap.SoapFault: Invalid >> authentication information >> at >> org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:70) >> at >> org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:35) >> at >> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:220) >> at >> org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:96) >> at >> org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:69) >> at >> org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:34) >> at >> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:220) >> at >> org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:633) >> at >> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:2064) >> at >> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1942) >> at >> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1867) >> at >> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66) >> at >> org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:595) >> at >> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62) >> at >> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:220) >> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:466) >> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:299) >> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:251) >> at >> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73) >> at >> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124) >> ... 5 more >> >> >> >> Thanks in advance, >> Leon > >
