You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Bernd Fondermann <be...@googlemail.com> on 2010/06/07 07:26:29 UTC
Re: XMPP PubSub Helloworld with Vysper and Smackx-PubSub
[moving thread over from users@]
On Sun, Jun 6, 2010 at 21:11, Niklas Gustavsson <ni...@protocol7.com> wrote:
> On Sat, Jun 5, 2010 at 11:13 PM, Bernd Fondermann
> <be...@googlemail.com> wrote:
>> We have a (unreleased!) sample PubSub client available in svn at
>> http://svn.apache.org/repos/asf/mina/vysper/trunk/demo/pubsub/client/
>> which also uses smackx-pubsub.
>> It works for me after applying the patch given below from revision
>> 938927 to the server code.
>
> I could not reproduce any problem with the pubsub demo with the
> current trunk. I would be grateful if you could provide further
> details on what problems you were seeing?
Exception in thread "AWT-EventQueue-0" java.lang.ClassCastException:
org.jivesoftware.smack.packet.DefaultPacketExtension cannot be cast to
org.jivesoftware.smackx.pubsub.Subscription
at org.apache.vysper.demo.pubsub.client.PubsubClientModel.discoverSubscriptions(PubsubClientModel.java:81)
at org.apache.vysper.demo.pubsub.client.PubsubClientModel.refresh(PubsubClientModel.java:136)
at org.apache.vysper.demo.pubsub.client.PubsubClientGUI.run(PubsubClientGUI.java:123)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:633)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:296)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:211)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:201)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:196)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:188)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
I cannot see the list of nodes, nor subscribe to any as a consequence of that.
> That being said, there are multiple issue with the current pubsub
> code, but the demo seems to be work fine with them:
> * message element created in the pubsub namespace
> * item element published in the pubsub (not pubsub#event) namespace
> (note that the proposed patch does not help with any of these)
I wasn't aware of these. Maybe have JIRAs for them would be helpful.
> * create node handler only allows exactly one inner element. However,
> the example used by Ken will send two elements since it uses a data
> form in addition to the create element
I'll look into his problem again more carefully.
> * The IQHandler namespace check is to lax in that it matches any
> element with equal declared namespace (even if not applied to the
> element at hand). This did in this case not cause any major problem
> since the element local name did not match.
Do you already have an idea how to improve this?
Bernd
Re: XMPP PubSub Helloworld with Vysper and Smackx-PubSub
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Mon, Jun 7, 2010 at 10:28 AM, Niklas Gustavsson <ni...@protocol7.com> wrote:
> On Mon, Jun 7, 2010 at 10:07 AM, Bernd Fondermann
> <be...@googlemail.com> wrote:
>> d'you want to fire this into svn?
>
> Sure, will do later today.
This is now in SVN.
/niklas
Re: XMPP PubSub Helloworld with Vysper and Smackx-PubSub
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Mon, Jun 7, 2010 at 10:07 AM, Bernd Fondermann
<be...@googlemail.com> wrote:
> d'you want to fire this into svn?
Sure, will do later today.
/niklas
Re: XMPP PubSub Helloworld with Vysper and Smackx-PubSub
Posted by Bernd Fondermann <be...@googlemail.com>.
On Mon, Jun 7, 2010 at 09:29, Niklas Gustavsson <ni...@protocol7.com> wrote:
> On Mon, Jun 7, 2010 at 7:26 AM, Bernd Fondermann
> <be...@googlemail.com> wrote:
>>> I could not reproduce any problem with the pubsub demo with the
>>> current trunk. I would be grateful if you could provide further
>>> details on what problems you were seeing?
>>
>> Exception in thread "AWT-EventQueue-0" java.lang.ClassCastException:
>> org.jivesoftware.smack.packet.DefaultPacketExtension cannot be cast to
>> org.jivesoftware.smackx.pubsub.Subscription
>> at org.apache.vysper.demo.pubsub.client.PubsubClientModel.discoverSubscriptions(PubsubClientModel.java:81)
>> at org.apache.vysper.demo.pubsub.client.PubsubClientModel.refresh(PubsubClientModel.java:136)
>> at org.apache.vysper.demo.pubsub.client.PubsubClientGUI.run(PubsubClientGUI.java:123)
>> at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
>> at java.awt.EventQueue.dispatchEvent(EventQueue.java:633)
>> at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:296)
>> at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:211)
>> at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:201)
>> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:196)
>> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:188)
>> at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
>>
>> I cannot see the list of nodes, nor subscribe to any as a consequence of that.
>
> I'm afraid I can not reproduce this. Just to make sure, you're up to
> date on trunk?
Ah, should've noted this. I'm lagging behind. Sorry. Just wanted to
make sure Ken has a chance getting over known problems, but if they
are resolved, even better. Thanks!
>>> That being said, there are multiple issue with the current pubsub
>>> code, but the demo seems to be work fine with them:
>>> * message element created in the pubsub namespace
>>> * item element published in the pubsub (not pubsub#event) namespace
>>> (note that the proposed patch does not help with any of these)
>>
>> I wasn't aware of these. Maybe have JIRAs for them would be helpful.
>
> The first one I've committed a fix for. The second one I've fixed but
> not committed. I agree that we should have them as JIRAs, I'll make
> sure to add them.
>
>>> * create node handler only allows exactly one inner element. However,
>>> the example used by Ken will send two elements since it uses a data
>>> form in addition to the create element
>>
>> I'll look into his problem again more carefully.
>
> I've fixed it by removing the check that there must be exactly one
> inner element. Not sure if this has any further complications?
>
>>> * The IQHandler namespace check is to lax in that it matches any
>>> element with equal declared namespace (even if not applied to the
>>> element at hand). This did in this case not cause any major problem
>>> since the element local name did not match.
>>
>> Do you already have an idea how to improve this?
>
> With the new parser, I think the following patch should be sufficient.
>
> Index: src/main/java/org/apache/vysper/xmpp/modules/core/base/handler/IQHandler.java
> ===================================================================
> --- src/main/java/org/apache/vysper/xmpp/modules/core/base/handler/IQHandler.java (revision
> 951378)
> +++ src/main/java/org/apache/vysper/xmpp/modules/core/base/handler/IQHandler.java (working
> copy)
> @@ -63,7 +63,8 @@
>
> List<XMLElement> innerElements = stanza.getInnerElements();
> XMLElement firstInnerElement = innerElements.get(0);
> - return firstInnerElement.getVerifier().namespacePresent(namespace);
> +
> + return firstInnerElement.getNamespaceURI().equals(namespace);
> }
>
> @SpecCompliance(compliant = {
>
d'you want to fire this into svn?
Bernd
Re: XMPP PubSub Helloworld with Vysper and Smackx-PubSub
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Mon, Jun 7, 2010 at 7:26 AM, Bernd Fondermann
<be...@googlemail.com> wrote:
>> I could not reproduce any problem with the pubsub demo with the
>> current trunk. I would be grateful if you could provide further
>> details on what problems you were seeing?
>
> Exception in thread "AWT-EventQueue-0" java.lang.ClassCastException:
> org.jivesoftware.smack.packet.DefaultPacketExtension cannot be cast to
> org.jivesoftware.smackx.pubsub.Subscription
> at org.apache.vysper.demo.pubsub.client.PubsubClientModel.discoverSubscriptions(PubsubClientModel.java:81)
> at org.apache.vysper.demo.pubsub.client.PubsubClientModel.refresh(PubsubClientModel.java:136)
> at org.apache.vysper.demo.pubsub.client.PubsubClientGUI.run(PubsubClientGUI.java:123)
> at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
> at java.awt.EventQueue.dispatchEvent(EventQueue.java:633)
> at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:296)
> at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:211)
> at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:201)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:196)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:188)
> at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
>
> I cannot see the list of nodes, nor subscribe to any as a consequence of that.
I'm afraid I can not reproduce this. Just to make sure, you're up to
date on trunk?
>> That being said, there are multiple issue with the current pubsub
>> code, but the demo seems to be work fine with them:
>> * message element created in the pubsub namespace
>> * item element published in the pubsub (not pubsub#event) namespace
>> (note that the proposed patch does not help with any of these)
>
> I wasn't aware of these. Maybe have JIRAs for them would be helpful.
The first one I've committed a fix for. The second one I've fixed but
not committed. I agree that we should have them as JIRAs, I'll make
sure to add them.
>> * create node handler only allows exactly one inner element. However,
>> the example used by Ken will send two elements since it uses a data
>> form in addition to the create element
>
> I'll look into his problem again more carefully.
I've fixed it by removing the check that there must be exactly one
inner element. Not sure if this has any further complications?
>> * The IQHandler namespace check is to lax in that it matches any
>> element with equal declared namespace (even if not applied to the
>> element at hand). This did in this case not cause any major problem
>> since the element local name did not match.
>
> Do you already have an idea how to improve this?
With the new parser, I think the following patch should be sufficient.
Index: src/main/java/org/apache/vysper/xmpp/modules/core/base/handler/IQHandler.java
===================================================================
--- src/main/java/org/apache/vysper/xmpp/modules/core/base/handler/IQHandler.java (revision
951378)
+++ src/main/java/org/apache/vysper/xmpp/modules/core/base/handler/IQHandler.java (working
copy)
@@ -63,7 +63,8 @@
List<XMLElement> innerElements = stanza.getInnerElements();
XMLElement firstInnerElement = innerElements.get(0);
- return firstInnerElement.getVerifier().namespacePresent(namespace);
+
+ return firstInnerElement.getNamespaceURI().equals(namespace);
}
@SpecCompliance(compliant = {
/niklas