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
