Also delete StanzaIdTest since the test was fundamentally weak and
flawed. It does not work anyway, since TestIQ has a fixed stanza ID.
Fixes SMACK-931.
Guus reports the following infinite recursing causing a
StackOverflowError:
Exception in thread "main" java.lang.StackOverflowError
at org.jivesoftware.smack.websocket.java11.Java11WebSocket.disconnect(Java11WebSocket.java:142)
at org.jivesoftware.smack.websocket.XmppWebSocketTransportModule$XmppWebSocketTransport.disconnect(XmppWebSocketTransportModule.java:265)
at org.jivesoftware.smack.c2s.ModularXmppClientToServerConnection$CloseConnectionState.transitionInto(ModularXmppClientToServerConnection.java:1086)
at org.jivesoftware.smack.c2s.ModularXmppClientToServerConnection.attemptEnterState(ModularXmppClientToServerConnection.java:472)
at org.jivesoftware.smack.c2s.ModularXmppClientToServerConnection.walkStateGraphInternal(ModularXmppClientToServerConnection.java:399)
at org.jivesoftware.smack.c2s.ModularXmppClientToServerConnection.walkStateGraph(ModularXmppClientToServerConnection.java:339)
at org.jivesoftware.smack.c2s.ModularXmppClientToServerConnection.shutdown(ModularXmppClientToServerConnection.java:551)
at org.jivesoftware.smack.c2s.ModularXmppClientToServerConnection.instantShutdown(ModularXmppClientToServerConnection.java:530)
at org.jivesoftware.smack.AbstractXMPPConnection.notifyConnectionError(AbstractXMPPConnection.java:1024)
at org.jivesoftware.smack.c2s.ModularXmppClientToServerConnection.access$100(ModularXmppClientToServerConnection.java:134)
at org.jivesoftware.smack.c2s.ModularXmppClientToServerConnection$1.notifyConnectionError(ModularXmppClientToServerConnection.java:185)
at org.jivesoftware.smack.websocket.impl.AbstractWebSocket.onWebSocketFailure(AbstractWebSocket.java:128)
at org.jivesoftware.smack.websocket.java11.Java11WebSocket.onWebSocketFailure(Java11WebSocket.java:162)
at org.jivesoftware.smack.websocket.java11.Java11WebSocket.disconnect(Java11WebSocket.java:146)
at org.jivesoftware.smack.websocket.XmppWebSocketTransportModule$XmppWebSocketTransport.disconnect(XmppWebSocketTransportModule.java:265)
at org.jivesoftware.smack.c2s.ModularXmppClientToServerConnection$CloseConnectionState.transitionInto(ModularXmppClientToServerConnection.java:1086)
at org.jivesoftware.smack.c2s.ModularXmppClientToServerConnection.attemptEnterState(ModularXmppClientToServerConnection.java:472)
...
This is because sendClose() in Java11WebSocket.disconnect() throws,
potentially because the output stream is already closed. We previously
would feed the exception into the onWebSocketFailure(Exception)
machinery, which would then again attempt a disconnect.
Since a failed sendClose() is nothing that needs special handling, we
simply log the exception as error. Furthermore, we only issue
sendClose() if the WebSocket's output is still open, i.e., if there is
a chance that it actually works.
Reported-by: Guus der Kinderen <guus@goodbytes.nl>
Previously low-level tests where run, potentially multiple times, with
the default connection descriptor.
Reported-by: Guus der Kinderen <guus@goodbytes.nl>
While markdown is easier to write, Smack's markdown documentation was
never tightly coupled with the source. For example, the markdown
documentation never provided links to the actual Java classes and
methods. This poses the risk that the documentation and the code
diverge over time. Furthermore, javadoc is constantly improving (for
example @snippet annotations) and I expect that one will be able to
write javadoc in markdown.
Fixes SMACK-928.
When enabled, the websocket implementation will attempt to use two implicit endpoints, using these URLs:
- `wss://[host]:5443/ws`
- `ws://[host]:5443/ws`
These endpoints should include ports that are used by default by known implementations, such as 5280/5281 (Prosody) and 7070/7443 (Openfire).
Set started with Smack 4.4 to set myRoomJid to null, introduced by
ab2822be3e ("muc: also set myRoomJid to null if we have left the
room"), however the code comment still states that we "do not reset
nickname here" (and myRoomJid contains the nickname as its
resourcepart).
Reported-by: Damian Minkov <damencho@jitsi.org>
On dinamically remove the last existed presence interceptor
we also should to remove the MUC's main presence interceptor from the connection.
Fixes: 60fee7b ("[muc] Fix Presence interceptors")
I am not happy with the concept of a build system wrapper, not to say
that I despise it. There is no reason why a single machine couldn't
have multiple versions of a build system-wide installed, and there is
no reason why each developer should download an individual copy of a
build system into the developers home directory. But here we are…
