powered by Jive Software

XMPPErrorException / StanzaError: additional error details in child elements

We’re trying to update Jigasi from 4.2 to Smack 4.4. For Jitsi Meet’s lobby functionality, the server sends an additional element in the error message that rejects joining the meeting MUC (to indicate in which room to wait). In 4.2 we could get access to the full stanza via XMPPErrorException.getXMPPError().getStanza(). Now that StanzaError.getStanza() is gone, we’re unable to access the additional child element. To make this work again, I thought about:

  • Just adding XMPPErrorException.getStanza() that returns the field stanza
  • Add StanzaError.getText() for RFC6120, 4.9.2’s text element
  • Adding a more complex logic that parses and exposes additional child-elements of the error-element, also RFC6120, 4.9.2
  • Something else?

What’s the best way to continue with this?

Thanks,
Ingo

Hi Ingo. NIce to hear that Jigasi is also in the process of updating Smack.

You should be able to access the descriptive texts via XMPPErrorException.getStanzaError().getDescriptiveTest(String xmllang).

Furthermore, you should be able to access the extension elements of the stanza error via XMPPErrorException.getStanzaError().getExtension(String elementName, String namespace).

It appears, however, that there is currently no method to iterate nor list all extension elements of an StanzaError (as part of the AbstractError superclass).

Furthermore, there is a getter for XMPPErrrorException.stanza missing. I have created SMACK-916. If I am not mistaken, then this should allow you to access all the elements you want. Even though not conveniently.

Note that RFC 6120 § 4.9.2 is about stream errors. It believe you are referring to stanza errors, which follow, thankefully, the same design as stream errors (hence the AbstractError superclass in Smack). But those are specified in RFC 6120 § 8.3.2.

Does this help your case? Do you need additional functionality in Smack? I ask because I am going to release Smack 4.4.4 soon. So this would be a good chance to get your required changes into this release.

XMPPErrrorException.getStanza() will fully solve the current issue, without any changes on the server side, so that would be my preferred short term solution. Long term I’ll try with @damencho to switch to StanzaError.getExtension(...) as this is cleaner than the current (ab)use of adding content below <error>. Thanks for this pointer!

I need the two pull requests I opened yesterday for SASL and BOSH to make Jigasi work at all. If you could squeeze them in for 4.4.4, this would be great.

For Jitsi Desktop (which is still the base for Jigasi), I need the OSGi metadata back. I’m working on this, but it’s not just Smack, but also MiniDNS, jxmpp ans hsluv (although I think I can use embed-dependency for hsluv, the others are more complicated).

I am confused by this, because extension elements added under <error> are exactly what you get with StanzaError.getExtension(). And this is even what the RFC suggests:

   <stanza-kind from='intended-recipient' to='sender' type='error'>
     [OPTIONAL to include sender XML here]
     <error [by='error-generator']
            type='error-type'>
       <defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
       [<text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'
              xml:lang='langcode'>
         OPTIONAL descriptive text
       </text>]
       [OPTIONAL application-specific condition element]
     </error>
   </stanza-kind>

So this is, for example, perfectly fine

<message type='error' …>
  <error type='modify' …>
    <bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
    <my-custom-error-content xmlns='https://jitsi.com'>
      …
   </my-custom-error-content>
  </error …>
</message>

Calling StanzaError.getExtension("my-custom-error-content", "https://jitsi.com") should return the extension element. So it appears you are doing what XMPP best practices recommends and Smack provides a way to retrieve the data. :slight_smile:

Isn’t that what you want? Or you add <my-custom-error-content/> as child of e.g. <bad-request/>?

The current XML looks like this, which is a mess and needs to be cleaned up. Please don’t ask why, I have absolutely no idea. :woozy_face:

<body xmlns='http://jabber.org/protocol/httpbind' sid='9825f09d-29ee-4b9e-90b9-bfa6279bde85' xmlns:stream='http://etherx.jabber.org/streams'>
  <presence id='X74DD-2' xmlns='jabber:client' type='error' from='someroom@conference.meet.jit.si/09f13f68' to='28edb6e2-1c67-41bf-adc9-52ea95154de0@meet.jit.si/cySCjEE8'>
    <error code='407' type='auth'>
      <registration-required xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
    </error>
    <x xmlns='http://jabber.org/protocol/muc'/>
    <lobbyroom>
      someroom@lobby.meet.jit.si
      <x xmlns='http://jabber.org/protocol/muc'/>
    </lobbyroom>
  </presence>
</body>

Haha, no worries. I am old enough to had my share of experience with “historically grown” stuff. :slight_smile: But thanks for clarifying, I now understand your situation.