You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@juddi.apache.org by Kurt T Stam <ku...@gmail.com> on 2013/05/21 08:29:02 UTC

juddi-gui & maven

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

Re: juddi-gui & maven

Posted by Kurt T Stam <ku...@gmail.com>.
Here you go:

https://issues.apache.org/jira/browse/JUDDI-615


On 5/21/13 2:53 PM, Alex O'Ree wrote:
> Well a more user friendly error message should be presented
>
> On Tue, May 21, 2013 at 2:50 PM, Kurt T Stam <ku...@gmail.com> wrote:
>> Right I don't, so I guess we need to document that.
>>
>>
>> On 5/21/13 11:29 AM, Alex O'Ree wrote:
>>> 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 <ku...@gmail.com> 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 <ku...@gmail.com>
>>>>> 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 <ku...@gmail.com>
>>>>>>> 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
>>>>>>

Re: juddi-gui & maven

Posted by Alex O'Ree <sp...@gmail.com>.
Well a more user friendly error message should be presented

On Tue, May 21, 2013 at 2:50 PM, Kurt T Stam <ku...@gmail.com> wrote:
> Right I don't, so I guess we need to document that.
>
>
> On 5/21/13 11:29 AM, Alex O'Ree wrote:
>>
>> 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 <ku...@gmail.com> 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 <ku...@gmail.com>
>>>> 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 <ku...@gmail.com>
>>>>>> 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
>>>>>
>>>>>
>

Re: juddi-gui & maven

Posted by Kurt T Stam <ku...@gmail.com>.
Right I don't, so I guess we need to document that.

On 5/21/13 11:29 AM, Alex O'Ree wrote:
> 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 <ku...@gmail.com> 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 <ku...@gmail.com> 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 <ku...@gmail.com>
>>>>> 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
>>>>

Re: juddi-gui & maven

Posted by Alex O'Ree <sp...@gmail.com>.
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 <ku...@gmail.com> 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 <ku...@gmail.com> 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 <ku...@gmail.com>
>>>> 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
>>>
>>>
>

Re: juddi-gui & maven

Posted by Kurt T Stam <ku...@gmail.com>.
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 <ku...@gmail.com> 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 <ku...@gmail.com> 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
>>

Re: juddi-gui & maven

Posted by Alex O'Ree <sp...@gmail.com>.
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 <ku...@gmail.com> 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 <ku...@gmail.com> 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
>
>

Re: juddi-gui & maven

Posted by Kurt T Stam <ku...@gmail.com>.
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 <ku...@gmail.com> 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

Re: juddi-gui & maven

Posted by Alex O'Ree <sp...@gmail.com>.
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.

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

On Tue, May 21, 2013 at 2:29 AM, Kurt T Stam <ku...@gmail.com> 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