You probably don't have any pki certificates installed in your browser's keystore. I know it works in IE and Chrome on windows and it "should" work on mac
On Tue, May 21, 2013 at 8:53 AM, Kurt T Stam <[email protected]> wrote: > Yeah want to open a jira for it? > > I just got the applet to work too, but when I sign I get the stack below, > which > must be bc of missing certs or something. > > java.lang.NullPointerException > at > org.apache.juddi.gui.dsig.XmlSignatureApplet.setupCertificates(XmlSignatureApplet.java:211) > at > org.apache.juddi.gui.dsig.XmlSignatureApplet.init(XmlSignatureApplet.java:92) > at com.sun.deploy.uitoolkit.impl.awt.AWTAppletAdapter.init(Unknown > Source) > at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown > Source) > at java.lang.Thread.run(Thread.java:722) > May 21, 2013 8:49:06 AM org.apache.juddi.gui.dsig.XmlSignatureApplet > jButton1ActionPerformed > SEVERE: null > java.lang.NullPointerException > at > org.apache.juddi.gui.dsig.XmlSignatureApplet.jButton1ActionPerformed(XmlSignatureApplet.java:339) > at > org.apache.juddi.gui.dsig.XmlSignatureApplet.access$100(XmlSignatureApplet.java:76) > at > org.apache.juddi.gui.dsig.XmlSignatureApplet$2.actionPerformed(XmlSignatureApplet.java:283) > at > javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2018) > at > javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2341) > at > javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402) > at > javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259) > at > javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:252) > at java.awt.Component.processMouseEvent(Component.java:6505) > at javax.swing.JComponent.processMouseEvent(JComponent.java:3321) > at java.awt.Component.processEvent(Component.java:6270) > at java.awt.Container.processEvent(Container.java:2229) > at java.awt.Component.dispatchEventImpl(Component.java:4861) > at java.awt.Container.dispatchEventImpl(Container.java:2287) > at java.awt.Component.dispatchEvent(Component.java:4687) > at > java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4832) > at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4492) > at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4422) > at java.awt.Container.dispatchEventImpl(Container.java:2273) > at java.awt.Component.dispatchEvent(Component.java:4687) > at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:729) > at java.awt.EventQueue.access$200(EventQueue.java:103) > at java.awt.EventQueue$3.run(EventQueue.java:688) > at java.awt.EventQueue$3.run(EventQueue.java:686) > at java.security.AccessController.doPrivileged(Native Method) > at > java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76) > at > java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:87) > at java.awt.EventQueue$4.run(EventQueue.java:702) > at java.awt.EventQueue$4.run(EventQueue.java:700) > at java.security.AccessController.doPrivileged(Native Method) > at > java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:699) > at > java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242) > at > java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161) > at > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:91) > > > > > On 5/21/13 8:48 AM, Alex O'Ree wrote: >> >> 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 >>> >>> >
