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
