Presence <show/>

Openfire Openfire Dev
1

Sending the following XMPP-Packet to the Server


<presence><show/></presence>

results in a warning like this:

2009.03.17 17:27:01 Invalid presence show for -<presence><show/></presence>              
java.lang.IllegalArgumentException: No enum const class org.xmpp.packet.Presence$Show.
at java.lang.Enum.valueOf(Enum.java:196)
at org.xmpp.packet.Presence$Show.valueOf(Presence.java:378)
at org.xmpp.packet.Presence.getShow(Presence.java:137)
at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:239)
at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:176)
at org.jivesoftware.openfire.nio.ConnectionHandler.messageReceived(ConnectionHandler.java:133)
at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived(AbstractIoFilterChain.java:570)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:299)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilterChain.java:53)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:648)
at org.apache.mina.common.IoFilterAdapter.messageReceived(IoFilterAdapter.java:80)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:299)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilterChain.java:53)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:648)
at org.apache.mina.filter.codec.support.SimpleProtocolDecoderOutput.flush(SimpleProtocolDecoderOutput.java:58)
at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:185)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:299)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilterChain.java:53)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:648)
at org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java:239)
at org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(ExecutorFilter.java:283)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51)
at java.lang.Thread.run(Thread.java:619)

RFC3921, Page 7, Section 2.2.2.1. is a bit misunderstanding in this case, but I think empty show-Elements like this are allowed. However, it seems some client out there does use this.

The OPTIONAL  element contains non-human-readable XML
   character data that specifies the particular availability status of
   an entity or specific resource.  A presence stanza MUST NOT contain
   more than one  element.  The  element MUST NOT possess
   any attributes.  If provided, the XML character data value MUST be
   one of the following (additional availability types could be defined
   through a properly-namespaced child element of the presence stanza):

   o  away -- The entity or resource is temporarily away.
   o  chat -- The entity or resource is actively interested in chatting.
   o  dnd -- The entity or resource is busy (dnd = "Do Not Disturb").
   o  xa -- The entity or resource is away for an extended period (xa =
      "eXtended Away").

   If no  element is provided, the entity is assumed to be online
   and available.

I think the problem is located in org.xmpp.packet.Presence#getShow

public Show getShow() {
        String show = element.elementText("show");
        if (show == null) {
            return null;
        }
        else {
            return Show.valueOf(show);
        }
    }

I’m not sure, but probably element.elementText returns an empty string in this case instead of NULL. An additional check should solve the problem. It is possible that this little problem is causing other problems. I had strange server problems in these days. Login not working, Clients get kicked when joining a MUC room…strange things. I’m not sure this is related, just wanted to mention it if someone else has this problems.

Message was edited by: Coolcat This WYSIWYG-Editor is like hell…even when working with the HTML-Editor the results are different than that you typed…

2

Hi Coolcat,

the “” element is optional. This does mean that one can send “”.

You did post: “If provided, the XML character data value MUST be one of the following …” So is must not be empty while is empty.

LG

3

The question is: Does the “if provided” reference to the element itself or the XML character data?

Because this is unclear I would say both is allowed.

4

Since there is no further response, I created an issue:

JM-1530

5

Hi,

the RFC contains also the schema:

<xs:element name='show'>
       <xs:simpleType>
         <xs:restriction base='xs:NCName'>
           <xs:enumeration value='away'/>
           <xs:enumeration value='chat'/>
           <xs:enumeration value='dnd'/>
           <xs:enumeration value='xa'/>
         </xs:restriction>
       </xs:simpleType>
     </xs:element>

So I’d say that show must contain either away, chat, dnd or xa.

LG

6

Ok, in that case I need to find out which client does use this, so I can report this bug there. Time for another extension to Raptor

7

Talkonaut for S60 definitely triggers this errors.

Since I have the issue with all contacts being shown as offline with basically every S60-based XMPP client, this seems to be a frequent issue.

8

I can confirm the issue with Talkonaut. I had just posted this on their forum:

http://www.talkonaut.com/forum/topic_show.pl?pid=2873
And was about to post here, then I found this thread.
Best regards,
Joao S Veiga
9

Hi Martin,

I am planning to try out Openfire+Spark+Talkonaut and would like to know the status of this issue.

You seem to have closed issue: JM-1530 , but I don’t find any reason given there.

Is it that the bug actually does not exist or is it fixed?

Thanks and Regards,

Indivar Nair

10

This issue was closed because is not allowed in the specification. See posts of ‘LG’ in this thread.

=> There is no fix for Openfire, this needs to be fixed on client side.

11

Oh, ok. Didn’t get LG’s message earlier.

Will check with Talkonaut guys now.

Thanks.

Regards,

Indivar Nair

12

Hey Martin,

On second thoughts, when you say ‘client side’ do you mean Spark or Talkonaut?

Regards,

Indivar

13

Openfire is a server. Spark and Talkonaut are clients.

Message was edited by: Coolcat

14

Ok.

Would you know if there an issue raised with Spark?

If so, could you point me to it.

I have already raised the question with Talkonaut team.

Thanks,

Regards,

Indivar Nair

15

Would you know if there an issue raised with Spark?
No, I’m not even using Spark as client…I have nothing to do with Spark development.

16

Hmmm… Will raise it with them then.

Thanks for all the info till now.

Regards,

Indivar Nair

17

OF-775 has been filed related to this.