On 5/21/13 7:25 AM, Alex O'Ree wrote:
uddi.xml doesn't support (unless i'm mistaken) alternate
authentication mechanisms to authToken, which is something i want to
support. Also, I wanted the web site to be browser configurable, which
is just easier in a properties file.
OK two valid points. I think both requirements should be be rolled into
the UDDIClient though. Commons Configuration supports saving
data back into the uddi.xml file, and we will need to support other
Auth mechnisms anyway to make the TCK more widely usable.
none of the service interactions work because of the UDDI client
config change. Copy over the uddi.xml from the simple-browse example
and all should work. I'm not sure why the error wasn't logged
Ah cool. I will update.
On Tue, May 21, 2013 at 2:29 AM, Kurt T Stam <[email protected]> wrote:
Hi Alex,
I checked in the maven build.
1. It creates a signed juddi-gui-dsign.jar with dependencies, so it's all in
one jar, which should make it easier to load the applet. I see a
master-applet.jnlp and a master-application.jnlp; do we need both?
2. The war seems to sort of work but gives my nullpointers for the port
services. Not sure why; haven't really looked at it.
3. Can we get rid of the config.properties and use the uddi.xml instead?
These two files seem to have duplication config info.
I think the maven build juddi-gui.war is really really close. I'm deploying
it in the juddi-tomcat module. We can talk about it tomorrow.
Cheers,
--Kurt
