No incoming message for message with from = entitybare jid

Hi there,

using smack 4.3.4. I’m encountering incoming messages being received by smack (since it prints it to the console logs):

2019-09-03 14:50:21.059 D/SMACK: RECV (0): <message to="" id="..." type="chat" from="mybot@bot.domain.tld" xmlns="jabber:client"><body>...</body></message>

but not getting through to an incoming message listener:

ChatManager.getInstanceFor(connection).addIncomingListener { from, message, chat ->
    Timber.v("incoming message: from=$from, message=$message")

The message structures looks like these:

<message to="" id="uuid" type="chat" from="" xmlns="jabber:client">
    <body>this message does not make it to the incoming chat listener</body>

<message to="" id="uuid" type="chat" from="" xmlns="jabber:client">
    <body>this message is delivered successfully</body>

The only difference appears to be the from attribute. Looks like smack is rejecting the message with an entitybare jid, but processes the one with a full jid (including resource part) just fine. Is this a bug or expected? Any way to make receiving messages from entibare work?

It is not a bug. Messages from bare JIDs are atypical in XMPP. It should be easy to change, but I’d like to know more about the entity which generates those first.

thx for the quick response!

we’ve set up bots that can message people/post into MUCs. those bots are single instance, so we haven’t given them resources. and turns out - since we’re also developing clients for other platforms - only smack seem to not handle the message from bare jid. our JS and iOS framework appear to accept those.

so i could either give our bots resource paths or configure smack to accept those as well. hence my question here. how would i best make smack accept those messages? and depending on how invasive/hacky it is (my hope was this being a bug and you guys fix it proper for me :smiley: ), we’ll go the other route.

To be precise: Smack already accepts those, it is chat2.ChatManager which filters for message from full JIDs. But nothing prevents you from adding your own Stanza listeners with an appropriate filter.

It is not really a bug, but I don’t see a good reason why ChatManager shouldn’t also act on messages from bare JIDs, so I’ll eventually change this behavior. But this is no promise, I’ll first sleep a night or two over it, and even then, the change will probably not be introduced in Smack’s 4.3 branch but in the master.

1 Like

awesome, thx!

i’ll do that in the meantime :+1:t4: :

connection.addSyncStanzaListener(StanzaListener { stanza ->
    val message = stanza as? Message
        ?.takeIf { it.bodies.isNotEmpty() }
        ?.let { it.from.asEntityBareJidIfPossible() }
        ?.let { incomingListener.newIncomingMessage(it, message, chatManager.chatWith(it)) }

You usually want to implement the predicates as filter instead of evaluating them in the listener.

Should be possible to shorten this as ENTITY_JID filter.

good points! i’ll see to optimizing those :+1:t4:

FYI: i inlined things for brevity in that snippet. in my actual code i’ve extracted the filters into constants in an companion object. and the listener is it’s own function for testability. so they actually do not look as “packed” as here :slightly_smiling_face:

This topic was automatically closed 62 days after the last reply. New replies are no longer allowed.