A few more things to add to the config, X2UDDI (WSDL/WADL, etc) ignore SSL errors, and client -> UDDI server ignore SSL errors.
we may also want to roll in settings for signature validation and certificate verification into it. On Tue, May 21, 2013 at 8:26 AM, Kurt T Stam <[email protected]> wrote: > 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 > >
