Hi Kurt, I've looked at uddi.xml and I think I understand the configuration of nodes and their clerks. It is also clear that SubscriptionListener utilizes the clerk.
I found the this article on the jUDDI blog. It explains how to use clerks for registering services when they startup. I won't go into details since I think you wrote it. :) http://apachejuddi.blogspot.com/2009/11/uddi-annotations-how-do-i-self-register.html Are the clerks used when jUDDI does callbacks to SubscriptionListener interfaces (I believe via SubscriptionNotifier) so the proper UDDI Security service is called to generate the auth token? I don't see in the example how the uddi.xml can associate subscription to use a specific clerk for. Is that possible via the uddi.xml? If not, must I use the API to create the association? I do see an <xregister> element in the uddi.xml on the webpage that you provided a link to. Right now all I can find is the the user guide (which doesn't mention xregister) and the code org.apache.juddi.v3.client.config.ClientConfig. Is there any additional documentation on the configuration options available in uddi.xml? Thanks, Leon On Wed, Apr 20, 2011 at 4:11 PM, Kurt T Stam <[email protected]> wrote: > Hi Leon, > > Yes sort of, but the data it receives is just a notification, it then needs > to run inquiries > to get the details before it can publish them: > > The SubscriptionListenerImpl > (http://svn.apache.org/repos/asf/juddi/tags/juddi-3.0.4/juddi-core/src/main/java/org/apache/juddi/api/impl/UDDISubscriptionListenerImpl.java) > receives a SubscriptionNotification. With the information in the > SubscriptionNotification the SubscriptionListenerImpl can then use the > XRegistration code ( > http://svn.apache.org/repos/asf/juddi/tags/juddi-3.0.4/juddi-core/src/main/java/org/apache/juddi/api/impl/XRegisterHelper.java) > to copy info from one UDDI to another using the UDDI inquiry and publish > APIs. > The other registries can be regular UDDI registries. > > --Kurt > > On 4/20/11 3:52 PM, Leon Doud wrote: >> >> Hi Kurt, >> >> Thanks for the clarification. I'm going to pick through through the >> examples more. >> >> Yes, you are right I'm trying to use the UDDISubscripionListener on my >> subscribing UDDI server to receive service entity updates >> asynchronously and apply them locally. Am I right that the >> UDDISubscripionListener provided with jUDDI persists the data it >> receives? >> >> Leon >> >> On Wed, Apr 20, 2011 at 10:05 AM, Kurt T Stam<[email protected]> wrote: >>> >>> Hi Leon, >>> >>> As of jUDDI 3.0.2 I believe we support multiple client configurations >>> (uddi.xml files, much like persistence.xml's in JPA). >>> So you can package them with your service archive. In the example we use >>> the >>> portlets >>> so you can see the deployment. They are not essential for the >>> registration >>> process. >>> If you add: >>> >>> <servlet> >>> <servlet-name>UDDIClerkServlet</servlet-name> >>> <display-name>Clerk Servlet</display-name> >>> >>> <servlet-class>org.apache.juddi.v3.client.config.UDDIClerkServlet</servlet-class> >>> <load-on-startup>1</load-on-startup> >>> </servlet> >>> >>> to your service archive web.xml, it will read the uddi.xml. You can >>> override the default names using: >>> >>> <context-param> >>> <param-name>uddi.client.manager.name</param-name> >>> <param-value>example-manager</param-value> >>> </context-param> >>> >>> A clerk is a concept of the (j)uddi-client libraries. It allows the >>> auto-registration, since you can set >>> the username and pw to use in there (much like a datasource). Our UDDI >>> client libraries should work >>> with any UDDI registry. >>> >>> The portlets use UDDI-API so anything done in the portlets can be done >>> programatically by you, but this is the reason >>> the portlets need their own uddi.xml to configure the client libs. >>> >>> Note that the jUDDI server also implements the UDDISubscripionListener >>> (client side UDDI API). >>> This to allow one jUDDI node to publish to another another jUDDI node >>> using >>> the XRegistration >>> stuff. For this client side API to function we added a WebService (part >>> of >>> JUDDI-API) to send across >>> the Clerk info (from client to server). I don't think your plan was to >>> use >>> this, so you don't >>> really need to worry about that. Or maybe you do want to use it.. since >>> that's sort of what your >>> subject line implies. >>> >>> I hope this clear things up, if not just ask another question :) >>> >>> Cheers, >>> >>> --Kurt >>> >>> >>> On 4/20/11 9:04 AM, Leon Doud wrote: >>>> >>>> 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 >>> > >
