sco0ter / babbler Goto Github PK

Original report by Markus KARG (Bitbucket: mkarg, GitHub: mkarg).

Following the online avatar tutorial I added sending and receiving of avatars to my chat application. When I start my application, I twice receive MY OWN avatar, but I do not receive avatars of my chat partner. This happens on both ends, i. e. each side is receiving twice the OWN avatar, but never the other's avatar.

Original report by Geoffrey Knauth (Bitbucket: [Geoffrey Knauth](https://bitbucket.org/Geoffrey Knauth), ).

rocks.xmpp.extensions.caps.EntityCapabilitiesManager is dumping WARNING messages to my console, like:

Jun 08, 2015 9:10:11 PM rocks.xmpp.extensions.caps.EntityCapabilitiesManager$7 run
WARNING: Failed to discover information for entity '[email protected]/User' for node 'http://...'

I would really like to redirect these messages to a DailyRollingFileAppender I already have for my own log4j logging, but I haven't figured out the correct log4j.xml incantation to make that happen. Does anyone have any suggestions other than "read the log4j docs?" I've been doing that and tinkering with settings, but nothing has helped so far.

Original report by Markus KARG (Bitbucket: mkarg, GitHub: mkarg).

The ping manager automatically pings the server, but it does neither inform the application on a detected timeout nor does it automatically reconnect. If the client wants to detect a broken connection, it must instead manually invoke ping it is own timer. This is not nice. The automatic ping should either inform the application or restart the session or both.

Original report by Markus KARG (Bitbucket: mkarg, GitHub: mkarg).

Version
master d63b0fa

Stack Trace

IN : <iq id="4d4292b4-41af-47a3-80dd-643f3e380be6" type="result"><bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"><jid>[email protected]/mausloch</jid></bind></iq>
Feb 23, 2015 7:31:49 PM rocks.xmpp.core.roster.RosterManager readRosterFromCache
WARNING: Could not read roster from cache.
javax.xml.bind.UnmarshalException
 - with linked exception:
[org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 1; Unexpected end of file.]
        at javax.xml.bind.helpers.AbstractUnmarshallerImpl.createUnmarshalException(Unknown Source)
        at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.createUnmarshalException(Unknown Source)
        at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(Unknown Source)
        at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(Unknown Source)
        at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(Unknown Source)
        at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(Unknown Source)
        at rocks.xmpp.core.roster.RosterManager.readRosterFromCache(RosterManager.java:330)
        at rocks.xmpp.core.roster.RosterManager.requestRoster(RosterManager.java:498)
        at rocks.xmpp.core.session.XmppSession.loginInternal(XmppSession.java:956)
        at rocks.xmpp.core.session.XmppSession.connect(XmppSession.java:759)
        at rocks.xmpp.core.session.XmppSession.connect(XmppSession.java:673)
        at rocks.xmpp.core.session.ReconnectionManager$2.run(ReconnectionManager.java:137)
        at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
        at java.util.concurrent.FutureTask.run(Unknown Source)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(Unknown Source)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)
Caused by: org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 1; Vorzeitiges Dateiende.
        at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source)
        at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(Unknown Source)
        at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(Unknown Source)
        at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(Unknown Source)
        at com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(Unknown Source)
        at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(Unknown Source)
        at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown Source)
        at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(Unknown Source)
        at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
        at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
        at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
        at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source)
        at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown Source)
        at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
        ... 17 more

OUT: <iq id="bd17fdd7-54c0-4ade-8d2c-6b101e36dabe" type="get"><query xmlns="jabber:iq:roster" ver=""></query></iq>

Original report by Markus KARG (Bitbucket: mkarg, GitHub: mkarg).

When trying to use the AvatarManager Babbler throws a stacktrace due to Timeout:

OUT: <iq id="991c909d-0550-4432-bced-0187a69a74b8" to="[email protected]" type="get"><pubsub xmlns="http://jabber.org/protocol/pubsub"><items node="urn:xmpp:avatar:data"><item id="48560af9e7d64c87df9a03d9fadbac6a70cc02c6"></item></items></pubsub></iq>
IN : <iq from="[email protected]" id="991c909d-0550-4432-bced-0187a69a74b8" to="[email protected]/eclipse" type="result"><pubsub xmlns="http://jabber.org/protocol/pubsub"><items node="urn:xmpp:avatar:data"><item id="48560af9e7d64c87df9a03d9fadbac6a70cc02c6"><data xmlns="urn:xmpp:avatar:data">iVBORw0KGgoAAAANSUhEUgAAAEAAAABACAYAAACqaXHeAAAABHNCSVQICAgIfAhkiAAADSBJREFUeNrtm2tsW+d5x3+8H5KiKFEkJcqk7jdfJHtxZte5NKmNuS28S9Z2w7J9WYt1g9tiKJbsw74Xwz50WDp02ZaiK9phzbCtBYraQet2jhPHzuxanqybJZsUJZESKd5EiiZ5KPGQ+3DEQzKyk9qiZCXdCwivDg/P4fv8n//zf5/3ec9RlUqlEr/CTc2vePt/AHb7B0UxV9M/7qbaTQ0QxRyCSkUuVzFeJQgACILxow1A2eMlUQQgl0lu+Y5tX/dHE4Cy8dl4mPXsPYqJKACZQoUJgqUFAHvHIMam5o8eAMmAl2IiSnrJD8B68K5yXu/ulwWptQ0Ax8BRmhxtHw0AHmS8PrNIPrEGgBScQOMexmBrhMFTMgjHT+5KSOwKAGI6pRynQ/NoclnSS34sa/9BbEqHFJxQzmvcw6g8h9C7+2l99syOM0G70wgLKhUlnQGAVDQog7DJhPjar6HygGaTBWv+EI0AwQn0I0+zArDDIOw4ABgEVKUS2XiYYiJKdslPW8s7LN5qleM/swi2RvIM0+weVtiQHb+CCYi2tiFYTu7YNLkrIZC49S7pJX+N8FW3UmCyJgzW/CEau12yh068iHD0WdwHn9qR2WFHARDFHIHRixRXwjD736ybOygFJivksDUq/+cTaw8EofWTQ2T6/5z+p898eFLhXHKV6J1bFFfCsucHT6F392M48buK8mfHr5BPrCmzQbXx1f3/TrxJInmR8N2JDw8AqWgQTS4LQNPzL2DZ1426tY314F0Sh06jcQ8rQABEUjHiFhfLeZPi+WoQjJdmCYcufzgASEbDSqZn6juofF5cCSMcfZZ9fb0YXzjLouMYy3kTAZ+PlnSIfCxFuyGrGD11rwBAwxUZqOWxqbqzYEcAKK7LKa7F2YG5pbUGDIuzA8HSQnElzNDzn6KYngdgOW/CYLeynDexZtEwda/AwQZ5klqzaAjGIugnR5m5+uYeByAvL3b0pgb0pgaM5qYaMPSmBjS5LJZ93dwsDaG2dLFwZ1a+NCYnTI1piYMNWqbuFVizaGhMS7Ku+G+RTc0qDNuTAIilEmq9PGebWtrIb+TRGc0ITQ7lc8HdjWQ08WSbvCL0uAw0LPtk9qTnFQ042KAlEMorILjtTvSTo6RD83sXAEGlkkVr0/MGnQG9qQHBYsWgMygg6IxmxeBAKM/UvQK+nFwbeHciUKMB5fPBWIR8LMXEpX/d2wwQLFZUgoAgGFEJAqaWNgTBiLGpGcFiRa03ko4sUnz73wiE8sq13YUZAqG8Qn+Py7BVXzY1o14VpfonQnlRBkEwkoyGid4ZZckr0zubmsVkHSQ1ehn17XM1xr+3eVwGAqE86X1aLEuFms8jR1189qWrdVkj1H8tYBBAzDH7w2/jC96kdOkidPsojmvkhdAm7c6Pi4w4VPe9xcEGLVOhPB6XgcaUxFoVGNNIHE04EZNRqAMA9Q8BMcfF114m8JNvIf34Xyim51n4aSWWy/2IQ8V4VCbfe/vX/Rtbvl9mwoGihtGFm3tXAxbe+D4b3ogyyLIR58fFmmNAYUAZjOrjcitrwYGiRgmLQ+bevbkcTkbD+II3mZn9EZalAuejGzXnyx6ubmVjz4wINeCUjS2D5nEZmFZLHHAZ8OUETnn69h4AYjJK6dJFjOqDjEfHfqlrKqDkOTHsIRiLACjGTqvlJCiwlOfA5qzwiU9/sm71gbqGwEYugy8nMH1z7KGvHY+W+OeLiwC47U5O2+Rk6EBRg2WpwHi0pDBCOPrs3tQAx8Dhbd/j/LiosMBtdyrhMOJQkd6nRfNbX8Di7CCXXN2becDsD7/N3539ky2fdx/RAWAeKm45l5mR/eAfq2jGmRFBAWHNH2LNosGvHeL3//576E0NSqq93VDYkYrQN776VW6//g26j+gwDxXpdBtpbcxjbZYlZ0Pdi67oY0PdSzY+C4V+VrIy/ad/nlfAqAahujzmOXqSZMCL1eHedplsR4qi/T0b9LzcQGtjnt4OHbG0hL25BwBri0AqLmJtGSAVF5Esp4ikg3TTRTY+S+tn4Pp0kW50BJZk9S+Xx0qBSYrufsR0iiZPH8mAd9sA1J0B1/7rd+gzXwDA5tSQiEjYnHIWqHIeQsrYlO9qnAJSRM4P4gvyMFZTb5FaLbCyZmAhmCMzo+ZAUaMwQXviRZqef0HRm5IobgsE7W4YL6n6UJnaIQOalnZ54Oo2kMKoHW2sxxJYu0AM5+h1DODz3gHy4DayQA6mNUp5rNk9SdbbT9JopsnTh0oQ5F3nR9SCujHg2vmX6FO/qhgPKIZr+tyUUk5UNgcQAlxbS+OJKCpbgVJCi6oYJnJziUg6iN8vr/4WgvLqr3Nax8DZb8rVJVcXTY1N8vrjcYbA2Nuv4sm8VGM8gKr7NDQ/9wEj6ITSwhYwAPx3s2ws/pMSElwoKKHQ8JVX5fJakwPBYn1kBmw7BEQxhzbyj2CmJtYxt1eMV3V+MAjVh5sy0fPkFAX9AKmVWVjMw+dkgVxgiedGL2P59B/VjONRQNh2IjRz/Tu4zN4azwPQPFDl0oVf7malBSgtbDIgBBobWs+ToO2kt0O+f6dbNrIUmCQ1cZ3ieu3m664CUPZ+tedVzkPgGgFcpOdzjF3WkZ7P1YKQ/9T9eyA9n+PWVDvX3tggu6IH+zAtR57B5tTQ26FhoFPi2AE1v9BMY+o7yHr23uPLA2aufweP2QvISk9URNvVQynlZCVxkn/4wW05n+8/zDNpDZ7hazLdDT/ZLJ7U9tmVOL5AGz+4agfszIn7ePGzUWBCvj+z2C0lUqvgbIkST95kaODziOkUJVFE5OGfNdoWA9pzP1amOQBtVw9INlQ2B2+Oy9tdXp9cDnvnrrRVC6o8D2Bqe4Lb0cPKddN3l0j7Z8BuR+sQaDkkn+vt0NDamCef9iEIRpocbcrDVg9bK3xkAJLRMJriJTmhKXnROjanIrsdgP2OW3h9Pj5mXmH67hK/+cTlrVpQZkCVBjzTr1FAO2F6C0uXEaQEmNuRMjasrYNyRtmsJTL9mmJw2fPlqvSOT4Nz//MXdOteq0x3NcLnIrsSZ2I0w7mJ4/zVH09iam354NmgLISqTtL+GSxdVU+SSQlYLYIo7y7HZ5LEVhfJtX2dIx//0u7mAaKYw3vuGEM9GoX2Zc/LSc59kp3yfP+gvqaFag+lhNyvxeTDiEgpu4zPe4ek+jc4/rkf7e4sUC00UkSEZnWV8VV92ePVxj4IjJr2HvA0m4lBo11ZQwDYmzvAuL3S2CNrQMZ4mlRc9oTkDd7fc2XPVhtb/nvv+Zrr78OAMgiSTVlAxVYXMVh6Hw8AtqaTUFggFZcHQyx2/8E/VDL0gPDR2CphoJH7VFxkQ91Lm2t75bFHFkFRzDH+XSvWZi12S4mm7k/I4+tzV7y1xaj369+nVWmAFBG5PRnYzBuKHPvy1ONhgCAY0e9/BVPKBNpOkv43K+EgJSqD3q7x5bZpfHyhxFCPBl3Rh374y4+3KDo48iKpZhex1UXQdhIZb62AsFqshIU09YAYf4DaVx9LCSRvkLk7XSQDc7R0qhid62RD3UvX/s88XgCMTc0YXH+jHDtHVpiZk2QQ4su12lA27v366ljf7CVvkFJ2GWv6DRo6TnJvpRUzcxScZ+uyObrt1WD/02fwhT9PbHWRVFzEaXFz8xfTJANzFAI3ZNHanL8fCoxN4+MLJWbmJJo8PWhL8xTW38Xvn+fI8S/snX2Bk3/6dVJR+cFmmyNEb08Pvrk5UnGRwvxcJYlpVlfA+IBWNj6SDrL/kEeeSLLL+Obm+PUXrm6rClR3AATBSMfpf1eMlord9Pb0cHVsqRaE0HhNRnfffrWI5A1yY1LHtfF3FOMBfN476Pe/Qlv/cN3qmHWtCo+9/SrG8Mv09g0o+cHVsSWeOrIPa4tQWTCZ22svbLTLxks2pPgyNyZ1qFa8HD1VyRCTgTm862c4fuZv61rCr+vW2JGPf4mk+Syh0SA2m5wddnd38fo5LzNzEoXoZtKUWa7tN5mRmpb46YVuJm9M0NXXUWt8apDBY39Z9z2Muu8LiGKOW+f+gD7zBaytg6TiIrHVRX52ZZ1jA4P0Dki0DDXVxnvGxu3JANduZHC2RDn47Bfp0F9EZWqnlF1mZk7Cfvj7daX+jgEAkFjys/zub+Mye0HbCYUFYmkVP7uyrtT1njqyj1BK3i+8diPDz+Nf5A8H/prjI89gc4RQmdoVEbQOfAvPyMfYibZjT4sno2Fm3/oz+swX5E2ShJtQSsely7eVzdByMw8VOTYwyBMnZEDKxvvTejoPf21HPL/jAID8xPj4la/RvvxdTO5MRc0XJa5PFxU2DHRKNFufU6bRVFzEmxqk/8QrO/7e0K68NVaeHeyW+/9UmSEAoZSOgvPstqo8ew6Asi7cHfsm5twFdEUfdkuJWFql9BvqXjLG0/Qf+cquvkCp2u3X55PRMOnQPMuB/6xUlz2/J+/z7dK7gtXt/wDoRrFjs+raewAAAABJRU5ErkJggg==</data></item></items></pubsub></iq>
IN : <iq from="[email protected]/cheekychat" id="acc71ae5-f7ef-480b-81ff-d6f6eaa84590" to="[email protected]/eclipse" type="get"><query xmlns="http://jabber.org/protocol/disco#info" node="http://xmpp.rocks#YhsriNHd0WY9WvfFv1FIeNd6Elw="></query></iq>
Feb 14, 2015 9:35:15 PM rocks.xmpp.extensions.avatar.AvatarManager handleMessage
WARNING: Timeout reached, while waiting on a response.
rocks.xmpp.core.session.NoResponseException: Timeout reached, while waiting on a response.
	at rocks.xmpp.core.session.XmppSession.query(XmppSession.java:552)
	at rocks.xmpp.core.session.XmppSession.query(XmppSession.java:506)
	at rocks.xmpp.extensions.pubsub.PubSubNode.getItems(PubSubNode.java:349)
	at rocks.xmpp.extensions.avatar.AvatarManager.handleMessage(AvatarManager.java:387)
	at rocks.xmpp.core.session.XmppSession.notifyStanzaListeners(XmppSession.java:419)
	at rocks.xmpp.core.session.XmppSession.access$300(XmppSession.java:96)
	at rocks.xmpp.core.session.XmppSession$8.run(XmppSession.java:1014)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

For me this sounds like a similar problem as the file transfer stuff, but I have no clue where to send the whitespace this time...

Original report by Markus KARG (Bitbucket: mkarg, GitHub: mkarg).

A test drive using a rather busy line (simulated by a heavy background uploading process on the same DSL line) resulted in a rather lot of timeouts. As mobile use more and more is a trend, it might make sense to extend the default timeouts to get along with busy lines. The benefits are improved stability in downsized environments. The disadvantage is reduced agility due to longer wainting "if nothing goes on". It might be hard to find a good compromise value, but it might be worth at least optimizing a bit into the direction of "bad" lines.

Original report by Julien Herr (Bitbucket: [Julien Herr](https://bitbucket.org/Julien Herr), ).

It's more a question than an issue but I don't know where to ask it, so... :)

As you use JAXB in order to marshall and unmarshall XML to Object, why did you not generate classes from XSD instead of writing them by hand?

Original report by Julien Herr (Bitbucket: [Julien Herr](https://bitbucket.org/Julien Herr), ).

Again, it's a question about the architecture.

Why don't you use a NIO framework like netty, Apache MINA, Grizzly, ...?

Original report by Markus KARG (Bitbucket: mkarg, GitHub: mkarg).

I notived that it is apparently a common pattern in the Babbler source code to register listeners even for disabled managers, and then ask for being enabled within the handleMessage listener.

This seems to be an unnecessary effort: A disabled manager will never react upon messages, so why notify it upon each single message? And an enabled manager will react upon each single message, but has to check its enabled flag again and again and again...

Performance could be improved and code complexity could be reduced, by simply registering and deregistering within setEnable(boolean), instead of just storing a flag and checkint it again and again...

Original report by Markus KARG (Bitbucket: mkarg, GitHub: mkarg).

Some (possibly most public?) servers contrain the communication with the client in some way, by applying policies. One policy might be that the data transmission is slowed down, another policy might be to restrict the number of logins per time. Both policies are in place with jabber.de for example.

I noticed that if such a policy prevents connection, no reconnect happens. Apparently Babbler is not assuming such policies (see stack trance below).

It might be a good future improvement to add some minimal support for "safe" reaction upoin failed policies, like reconnecting after some time.

OUT: </stream:stream>
Mar 08, 2015 1:01:15 PM rocks.xmpp.core.session.XmppSession connect INFORMATION: XmppSession:BEFORE throwAsXmppExceptionIfNotNull rocks.xmpp.core.stream.StreamErrorException: <policy-violation/>
        You exceeded the number of connections/logins allowed in 60 seconds, good bye.
Mar 08, 2015 1:01:15 PM rocks.xmpp.core.session.XmppSession connect 
<policy-violation/>
        You exceeded the number of connections/logins allowed in 60 seconds, good bye.

Original report by Markus KARG (Bitbucket: mkarg, GitHub: mkarg).

There should be a clarification in the XmppSession's JavaDocs whether it is safe to use one XmppSession instance from multiple threads at the same time or must be serialized explicitly, and it should be told whether all access has to be done using always the same thread (like in Swing or JavaFX). Only the implementor of the Babble framework can know this, but it is essential for the application programmer when using Babbler in a multi-threaded application.

Original report by Anonymous.

Bug appears when entering chat room. Debug log (JIDs redacted) shows the presence stanza is received, but it doesn't seem to be recognized:

#!xml

OUT: <presence to="[email protected]/bot"><x xmlns="http://jabber.org/protocol/muc"></x></presence>
[...]
IN : <presence from="[email protected]/bot" to="[email protected]/bot"><x xmlns="http://jabber.org/protocol/muc#user"><item affiliation="none" jid="[email protected]/bot" role="participant"></item></x></presence>
[...]

After a short time this exception is thrown:

#!java
rocks.xmpp.core.session.NoResponseException: Timeout reached, while waiting on a response.
	at rocks.xmpp.core.session.XmppSession.sendAndAwaitPresence(XmppSession.java:597)
	at rocks.xmpp.core.session.XmppSession.sendAndAwaitPresence(XmppSession.java:556)
	at rocks.xmpp.extensions.muc.ChatRoom.enter(ChatRoom.java:409)
	at rocks.xmpp.extensions.muc.ChatRoom.enter(ChatRoom.java:356)

The IQ stanzas aren't recognized either, leading to multiple of these:

#!java

Jan 22, 2015 8:43:37 AM rocks.xmpp.extensions.caps.EntityCapabilitiesManager$3 handle
Warnung: Timeout reached, while waiting on a response.
rocks.xmpp.core.session.NoResponseException: Timeout reached, while waiting on a response.
	at rocks.xmpp.core.session.XmppSession.sendAndAwaitIQ(XmppSession.java:531)
	at rocks.xmpp.core.session.XmppSession.query(XmppSession.java:472)
	at rocks.xmpp.core.session.XmppSession.query(XmppSession.java:452)
	at rocks.xmpp.extensions.disco.ServiceDiscoveryManager.discoverInformation(ServiceDiscoveryManager.java:382)
	at rocks.xmpp.extensions.caps.EntityCapabilitiesManager$3.handle(EntityCapabilitiesManager.java:180)
	at rocks.xmpp.extensions.caps.EntityCapabilitiesManager$3.handle(EntityCapabilitiesManager.java:136)
	at rocks.xmpp.core.session.XmppSession.notifyStanzaListeners(XmppSession.java:407)
	at rocks.xmpp.core.session.XmppSession.access$600(XmppSession.java:80)
	at rocks.xmpp.core.session.XmppSession$9.run(XmppSession.java:961)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:744)

Original report by Geoffrey Knauth (Bitbucket: [Geoffrey Knauth](https://bitbucket.org/Geoffrey Knauth), ).

My program ran great for days, then hung after logging this exception:

#!java

Exception in thread "XMPP Reader Thread" java.lang.NoSuchMethodError: java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView;
2015/06/16 03:01:11 | at rocks.xmpp.core.subscription.PresenceManager$3.sessionStatusChanged(PresenceManager.java:108)
2015/06/16 03:01:11 | at rocks.xmpp.core.session.XmppSession.notifySessionStatusListeners(XmppSession.java:1488)
2015/06/16 03:01:11 | at rocks.xmpp.core.session.XmppSession.updateStatus(XmppSession.java:1479)
2015/06/16 03:01:11 | at rocks.xmpp.core.session.XmppSession.notifyException(XmppSession.java:1320)
2015/06/16 03:01:11 | at rocks.xmpp.core.session.XmppStreamReader$1.run(XmppStreamReader.java:174)
2015/06/16 03:01:11 | at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
2015/06/16 03:01:11 | at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
2015/06/16 03:01:11 | at java.lang.Thread.run(Unknown Source)

I found another issue (#36) that seemed similar, in that the exception thrown should only have been possible with Java 8, whereas the OP (and I) use Java 7.

I'm supposed to catch this Exception and shutdown the service so that it may immediately restart. I'm not sure where to do that. I have a MyMessageListener that implements handleMessage(MessageEvent e).

Original report by Markus KARG (Bitbucket: mkarg, GitHub: mkarg).

The new sample application (FileTransferSender and FileTransferReceiver) fails with supposed timeout while IBB transfer.

Original report by Thomas Calmant (Bitbucket: tcalmant, GitHub: tcalmant).

The implied JavaFX dependency currenlty forces to install the Oracle JDK (at least on Ubuntu 14.04) to test xmpp-client.
Maybe it should be considered as non-GUI library, therefore with non-GUI tests. The JavaFX tests could be executed in a separated artifact.

Original report by Rodrigo Alvarez (Bitbucket: [Rodrigo Alvarez](https://bitbucket.org/Rodrigo Alvarez), ).

Im using maven dependency xmpp-core-client 0.5.1, to deploy a simple xmpp client.

#!java


public  JsonObject prebind(String user, String password){
        try {
            BoshConnectionConfiguration boshConfiguration = BoshConnectionConfiguration.builder().hostname(BOSH_SERV).port(5280).file("/http-bind/").wait(60).build();
            XmppSession xmppSession = new XmppSession(BOSH_SERV, boshConfiguration);
        try {
              xmppSession.connect();
            } catch (XmppException ex) {
                ex.printStackTrace();
            }
....
    }

It works fine with Apache-tomcat-8.0.22, but in production I use a Jboss/Wildfire and throws this exception:

#!java

 Exception com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 1 counts of IllegalAnnotationExceptions
 rocks.xmpp.extensions.compress.model.StreamCompression$Failure$Condition does not have a no-arg default constructor.
  this problem is related to the following location:
    at rocks.xmpp.extensions.compress.model.StreamCompression$Failure$Condition
    at rocks.xmpp.extensions.compress.model.StreamCompression$Failure$SetupFailed
    at private final rocks.xmpp.extensions.compress.model.StreamCompression$Failure$Condition rocks.xmpp.extensions.compress.model.StreamCompression$Failure.condition
    at rocks.xmpp.extensions.compress.model.StreamCompression$Failure
    at @javax.xml.bind.annotation.XmlSeeAlso(value=[class rocks.xmpp.extensions.compress.model.feature.CompressionFeature, class rocks.xmpp.extensions.compress.model.StreamCompression$Compress, class rocks.xmpp.extensions.compress.model.StreamCompression$Compressed, class rocks.xmpp.extensions.compress.model.StreamCompression$Failure])

There you talk about "no-args constructor" issues, but couldn't find a solution

Thank you, this library is great and easy to use.

Original report by Marcel Vo (Bitbucket: [Marcel Vo](https://bitbucket.org/Marcel Vo), ).

If I trie to add a MessageListener to a xmppSession i get the following Exception:

Eception in thread "main" java.lang.IllegalAccessError: tried to access class org.xmpp.stanza.StanzaEvent from class XMPPTest

Here is the Code:

#!java
xmppSession.addMessageListener(arg0 -> System.out.println(arg0.getMessage()));

I fixed that problem by making the StanzaEvent Class public.

Can you please fix that problem?

Original report by Anonymous.

Hi I 'm interseted well to your babbler library but we need the support of WebSocket (RFC 7395) instead of using BOSH.
Do you think that it is possible?

Original report by Markus KARG (Bitbucket: mkarg, GitHub: mkarg).

Babbler references the class com.sun.jndi.dns.DnsContextFactory, which not necessarily exists in any JRE, as it is not part of the Java SE standard. As a consequence it might happen that Babbler will fail to work on non-Oracle JREs. While this is acceptable for pre-10 releases, post-1.0 releases should address this issue.

Original report by Markus KARG (Bitbucket: mkarg, GitHub: mkarg).

Since Babbler explicitly is a Java 7 based product, it might make sense to replace File API by Path API.

The class File is an anachronism since Java 7: It mixes up referencing a file (hence a path), querying attributes (like directory flags) and accessing the content. Following the paradigm of separation of concerns, it made pretty good sense that Java 7 came up with a replacement in the form of Path API. Using the new Path API, code is getting much cleaner, as separate classes now show directly whether a former use of a File instance is meant to be a path (now an instance of Path), was meant to be a directory modification, or was meant to be concent access (now handled by FileSystem and Files classes). Also, it opens the way for different implements of FileSystems and Files, while the former File class was ubiquitous and rather limited. Ontop of all that, copying, loading and storing files is much simpler and faster using the new Files helper methods.

Original report by Markus KARG (Bitbucket: mkarg, GitHub: mkarg).

I noticed that AvatarManager is natively dealin with byte[], which is a bit awkward, as it mixes up the logic behind avatars (level 7) with the technology needed to hold the bits (level 6). I wonder whether it might make more sense to push down the transformation from java.awt.Image to byte[] and vice versa into an XmlAdapter<Image, byte[]> to have clear separation of concerns?

Original report by Markus KARG (Bitbucket: mkarg, GitHub: mkarg).

Steps to reproduce:

• Implement file transfer according http://sco0ter.bitbucket.org/babbler/xep/filetransfer.html
• Offer a file for transfer

Expected result:

• No exception. Outgoing message in console log.

Actual result:

• StanzaException. No outgoing message in console log.

Below is the console log. If there is something I can help / check please let me know! :-)

OUT:
IN :
rocks.xmpp.core.stanza.model.StanzaException: - (type 'cancel': do not retry (the error cannot be remedied))
at rocks.xmpp.core.session.XmppSession.query(XmppSession.java:527)
at rocks.xmpp.core.session.XmppSession.query(XmppSession.java:471)
at rocks.xmpp.extensions.disco.ServiceDiscoveryManager.discoverInformation(ServiceDiscoveryManager.java:293)
at rocks.xmpp.extensions.disco.ServiceDiscoveryManager.discoverInformation(ServiceDiscoveryManager.java:275)
at rocks.xmpp.extensions.caps.EntityCapabilitiesManager.discoverCapabilities(EntityCapabilitiesManager.java:210)
at rocks.xmpp.extensions.caps.EntityCapabilitiesManager.isSupported(EntityCapabilitiesManager.java:241)
at rocks.xmpp.extensions.filetransfer.FileTransferManager.offerFile(FileTransferManager.java:139)
at application.chat.XmppChat.lambda$7(XmppChat.java:396)
at application.chat.XmppChat$$Lambda$402/88777887.accept(Unknown Source)
at java.util.ArrayList.forEach(ArrayList.java:1249)
at application.chat.XmppChat.offerFiles(XmppChat.java:394)
at application.chatwindow.ChatWindowController.lambda$8(ChatWindowController.java:209)
at application.chatwindow.ChatWindowController$$Lambda$220/1066528549.handle(Unknown Source)
at com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:86)
at com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:238)
at com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191)
at com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59)
at com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58)
at com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
at com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
at com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74)
at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:54)
at javafx.event.Event.fireEvent(Event.java:198)
at javafx.scene.Scene$DnDGesture.fireEvent(Scene.java:2904)
at javafx.scene.Scene$DnDGesture.processTargetDrop(Scene.java:3130)
at javafx.scene.Scene$DnDGesture.access$6400(Scene.java:2880)
at javafx.scene.Scene$DropTargetListener.drop(Scene.java:2844)
at com.sun.javafx.tk.quantum.GlassSceneDnDEventHandler.lambda$handleDragDrop$305(GlassSceneDnDEventHandler.java:81)
at com.sun.javafx.tk.quantum.GlassSceneDnDEventHandler$$Lambda$401/1707311396.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.javafx.tk.quantum.GlassSceneDnDEventHandler.handleDragDrop(GlassSceneDnDEventHandler.java:79)
at com.sun.javafx.tk.quantum.GlassViewEventHandler.lambda$handleDragDrop$358(GlassViewEventHandler.java:663)
at com.sun.javafx.tk.quantum.GlassViewEventHandler$$Lambda$400/862119867.get(Unknown Source)
at com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(QuantumToolkit.java:404)
at com.sun.javafx.tk.quantum.GlassViewEventHandler.handleDragDrop(GlassViewEventHandler.java:662)
at com.sun.glass.ui.View.handleDragDrop(View.java:712)
at com.sun.glass.ui.View.notifyDragDrop(View.java:1027)
at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
at com.sun.glass.ui.win.WinApplication.lambda$null$144(WinApplication.java:101)
at com.sun.glass.ui.win.WinApplication$$Lambda$36/186276003.run(Unknown Source)
at java.lang.Thread.run(Thread.java:745)

Original report by Markus KARG (Bitbucket: mkarg, GitHub: mkarg).

Just noticed that sometimes it happens that a stack trace is printed after my laptop resumes from suspend mode:

Feb 12, 2015 7:01:13 PM rocks.xmpp.core.session.XmppStreamWriter closeConnectionAndNotify
WARNING: java.net.SocketException: Socket is closed
javax.xml.stream.XMLStreamException: java.net.SocketException: Socket is closed
        at com.sun.xml.internal.stream.writers.XMLStreamWriterImpl.close(Unknown Source)
        at rocks.xmpp.core.PrefixFreeCanonicalizationWriter.close(PrefixFreeCanonicalizationWriter.java:136)
        at rocks.xmpp.core.session.XmppStreamWriter.closeConnectionAndNotify(XmppStreamWriter.java:255)
        at rocks.xmpp.core.session.XmppStreamWriter.access$200(XmppStreamWriter.java:55)
        at rocks.xmpp.core.session.XmppStreamWriter$4.run(XmppStreamWriter.java:232)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)
Caused by: java.net.SocketException: Socket is closed
        at sun.security.ssl.SSLSocketImpl.checkEOF(Unknown Source)
        at sun.security.ssl.SSLSocketImpl.checkWrite(Unknown Source)
        at sun.security.ssl.AppOutputStream.write(Unknown Source)
        at java.io.BufferedOutputStream.flushBuffer(Unknown Source)
        at java.io.BufferedOutputStream.flush(Unknown Source)
        at java.io.FilterOutputStream.flush(Unknown Source)
        at rocks.xmpp.core.BranchedOutputStream.flush(BranchedOutputStream.java:60)
        at com.sun.xml.internal.stream.writers.UTF8OutputStreamWriter.flush(Unknown Source)
        ... 8 more

As it is quite normal that laptops run into socket timeouts after a resume, we should possibly deal with that situation in a smarter way. For example, we could simply restart the communication on a new socket without showing a stack trace to the end user, to not scare him.

Original report by Markus KARG (Bitbucket: mkarg, GitHub: mkarg).

We noticed problems with open chat sessions in case one of the chat partners sets his PC to suspend mode and resumes it (long time) later. While other chat programs like Skype or Pidgin recover from this within seconds, Babble fails more often than not.

Sometimes it just works. Many times the result is that the session still works but is really really slow. And sometimes the session just does not work. You can send messages, but they will not arrive on the other side of the network.

I assume that this actually is a problem of the JVM unable to detect suspend and resume events of the operating system, hence cannot recover the TCP session correctly or something like that.

It would be good if this could be checked to decide how to go on: If it is a Babbler problem, then we should fix it. If it is a JVM problem, then we should report it upstream, i. e. to Oracle as the super-upstream of rather all JREs currently on the market.

Original report by Markus KARG (Bitbucket: mkarg, GitHub: mkarg).

I just had this idea and thought it might be pretty cool to solve the AWT vs FX vs byte[] discussion in AvatarManager: We could simply make AvatarManager and non-final, which opens the possibility for me to implement an AwtAvatarManager subclass. That one provides nothing but the Image-to-byte[] conversions. Also the events fired by its listeners are of different type (Image vs byte[]). That makes the AvatarManager AWT-free, but provides exactly what I need.

In future we could even add FxAvatarManager, which does the same but simply with FX images.

Maybe this is what you like more? Just drop me a note if you want me to implement that instead of having AWT Image inside of AvatarManager.

Original report by Markus KARG (Bitbucket: mkarg, GitHub: mkarg).

I noticed that creation of XmppClient needs several seconds. This is not nice for the end user, and it is a bit weird that it is the case, as it does not perform a real lot of work, nor does it perform blocking operations. I traced performance a bit and found that the main problem seems to be creation of the JAXB context, but had not time to dig deeper.

It would be great if we could reduce creation time to under one second, as it is not nice that users have to wait four seconds for a pure in-memory operation.

Original report by Anonymous.

I am having issues to connect to a chat server using Babbler. It's working flawless with smack so I am not sure what went wrong or where I made a mistake.

After my session is configured the following error is thrown.

Error:javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,1]
Message: Vorzeitiges Dateiende.

Attached is a java file with my code.

Original report by Markus KARG (Bitbucket: mkarg, GitHub: mkarg).

Steps to reproduce:

• Unknown. Initiated XMPP session as always.
• Possibly a side effect of using multipe threads?

Expected result:

• No exceptions.

Actual result:

• NPE at SAXConnector.startElement at EntityCapabilitiesManager.readFromCache

Here is the complete transcript (console debugger log):

OUT: <stream:stream xml:lang="de" to="jabber.de" version="1.0" xmlns="jabber:client" xmlns:stream="http://etherx.jabber.org/streams">
IN : <stream:stream xmlns:stream='http://etherx.jabber.org/streams' version='1.0' from='jabber.de' id='31810441-689c-4227-8c70-bccfd7bda76b' xml:lang='en' xmlns='jabber:client'>stream:features</stream:features>
OUT:
IN :
OUT: <stream:stream xml:lang="de" to="jabber.de" version="1.0" xmlns="jabber:client" xmlns:stream="http://etherx.jabber.org/streams">
IN : <stream:stream xmlns:stream='http://etherx.jabber.org/streams' version='1.0' from='jabber.de' id='4db4fe5d-5e38-4696-ac6e-3119b0f47efc' xml:lang='en' xmlns='jabber:client'>stream:featuresSCRAM-SHA-1PLAIN</stream:features>
OUT: biwsbj1ta2FyZyxyPWY4TDR6cGpJYmVib2h4QTI2a0tLYXc9PQ==
IN : cj1mOEw0enBqSWJlYm9oeEEyNmtLS2F3PT04NzRlNjliMy0zMWRlLTQwZGYtOWYzYS1mYTZiN2JjNWFkNGUscz1ObUkwTlRBM1lUa3RNMlF4TnkwMFlqVmxMVGs1T0RBdFptSTVZamMwTlRNek1XTmksaT00MDk2
OUT: Yz1iaXdzLHI9ZjhMNHpwakliZWJvaHhBMjZrS0thdz09ODc0ZTY5YjMtMzFkZS00MGRmLTlmM2EtZmE2YjdiYzVhZDRlLHA9N0RhRXhWbmd6V2FnUkgvL3BGejZyeFNZSERvPQ==
IN : dj1yTkZNSmhYTzhmck11U2pCOXlFTk4wMldaN0U9
OUT: <stream:stream xml:lang="de" to="jabber.de" version="1.0" xmlns="jabber:client" xmlns:stream="http://etherx.jabber.org/streams">
IN : <stream:stream xmlns:stream='http://etherx.jabber.org/streams' version='1.0' from='jabber.de' id='6cc35d0a-d598-4b13-b14b-1ba49d3238d5' xml:lang='en' xmlns='jabber:client'>stream:featureszlib</stream:features>
OUT: eclipse
IN : [email protected]/eclipse
OUT:
IN : FamilieBuddys
OUT: chat1
IN : chat1
IN : 148560af9e7d64c87df9a03d9fadbac6a70cc02c6
OUT: </stream:stream>
Jan 03, 2015 1:29:44 PM rocks.xmpp.core.session.XmppSession notifyStanzaListeners
WARNUNG: null
java.lang.NullPointerException
at com.sun.xml.internal.bind.v2.runtime.unmarshaller.SAXConnector.startElement(SAXConnector.java:147)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:509)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:379)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl$NSContentDriver.scanRootElementHook(XMLNSDocumentScannerImpl.java:605)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:3138)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(XMLDocumentScannerImpl.java:880)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:606)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:117)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:848)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:777)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:649)
at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:243)
at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:214)
at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:157)
at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:204)
at rocks.xmpp.extensions.caps.EntityCapabilitiesManager.readFromCache(EntityCapabilitiesManager.java:263)
at rocks.xmpp.extensions.caps.EntityCapabilitiesManager.handlePresence(EntityCapabilitiesManager.java:296)
at rocks.xmpp.core.session.XmppSession.notifyStanzaListeners(XmppSession.java:426)
at rocks.xmpp.core.session.XmppSession.access$600(XmppSession.java:99)
at rocks.xmpp.core.session.XmppSession$9.run(XmppSession.java:943)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

Original report by Markus KARG (Bitbucket: mkarg, GitHub: mkarg).

I'm using master 2a3c456 to send an avatar:

#!java
try (final ByteArrayOutputStream os = new ByteArrayOutputStream()) {
	ImageIO.write(SwingFXUtils.fromFXImage(new Image(Paths.get("My Pictures", "My Portrait.jpg").toUri().toString()), null), "png", os);
	final byte[] bytes = os.toByteArray();
	final AvatarManager avatarManager = session.getManager(AvatarManager.class);
	avatarManager.setEnabled(true);
	avatarManager.publishAvatar(bytes);
} catch (final Throwable t) {
	t.printStackTrace();
}

which results in the following output:

OUT: <iq from="[email protected]/eclipse" id="disco" to="[email protected]" type="result"><query xmlns="http://jabber.org/protocol/disco#info"><identity category="client" type="pc"></identity><feature var="http://jabber.org/protocol/bytestreams"></feature><feature var="http://jabber.org/protocol/caps"></feature><feature var="http://jabber.org/protocol/chatstates"></feature><feature var="http://jabber.org/protocol/disco#info"></feature><feature var="http://jabber.org/protocol/disco#items"></feature><feature var="http://jabber.org/protocol/ibb"></feature><feature var="http://jabber.org/protocol/rsm"></feature><feature var="http://jabber.org/protocol/si"></feature><feature var="http://jabber.org/protocol/si/profile/file-transfer"></feature><feature var="jabber:iq:last"></feature><feature var="jabber:iq:oob"></feature><feature var="jabber:iq:version"></feature><feature var="jabber:x:oob"></feature><feature var="jid\20escaping"></feature><feature var="urn:xmpp:avatar:metadata"></feature><feature var="urn:xmpp:avatar:metadata+notify"></feature><feature var="urn:xmpp:hash-function-text-names:md5"></feature><feature var="urn:xmpp:hash-function-text-names:sha-1"></feature><feature var="urn:xmpp:hash-function-text-names:sha-224"></feature><feature var="urn:xmpp:hash-function-text-names:sha-256"></feature><feature var="urn:xmpp:hash-function-text-names:sha-384"></feature><feature var="urn:xmpp:hash-function-text-names:sha-512"></feature><feature var="urn:xmpp:hashes:1"></feature><feature var="urn:xmpp:ping"></feature><feature var="urn:xmpp:time"></feature><feature var="vcard-temp"></feature></query></iq>
IN : <presence from="[email protected]/eclipse"><priority>10</priority><x xmlns="vcard-temp:x:update"></x><c xmlns="http://jabber.org/protocol/caps" hash="sha-1" node="http://xmpp.rocks" ver="YhsriNHd0WY9WvfFv1FIeNd6Elw="></c></presence>
IN : <iq id="7ef56b90-3512-40b0-9934-54c448d06fc5" to="[email protected]/eclipse" type="error"><error type="cancel"><item-not-found xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"></item-not-found></error></iq>
IN : <iq id="d0bf3e5d-0b4a-4950-b40f-7a012d3dd2ab" to="[email protected]/eclipse" type="error"><error type="cancel"><item-not-found xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"></item-not-found></error></iq>
OUT: <presence><priority>10</priority><x xmlns="vcard-temp:x:update"><photo></photo></x><c xmlns="http://jabber.org/protocol/caps" hash="sha-1" node="http://xmpp.rocks" ver="YhsriNHd0WY9WvfFv1FIeNd6Elw="></c></presence>
rocks.xmpp.core.stanza.StanzaException: <item-not-found/>  -  (type 'cancel': do not retry (the error cannot be remedied))
	at rocks.xmpp.core.session.XmppSession.query(XmppSession.java:540)
	at rocks.xmpp.core.session.XmppSession.query(XmppSession.java:483)
	at rocks.xmpp.extensions.vcard.temp.VCardManager.getVCard(VCardManager.java:62)
	at rocks.xmpp.extensions.avatar.AvatarManager.publishToVCard(AvatarManager.java:500)
	at rocks.xmpp.extensions.avatar.AvatarManager.publishAvatar(AvatarManager.java:482)
	at application.chat.XmppChat$1.call(XmppChat.java:182)
	at application.chat.XmppChat$1.call(XmppChat.java:1)
	at javafx.concurrent.Task$TaskCallable.call(Task.java:1423)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.lang.Thread.run(Thread.java:745)
OUT: </stream:stream>
IN : <presence from="[email protected]/eclipse"><priority>10</priority><x xmlns="vcard-temp:x:update"><photo></photo></x><c xmlns="http://jabber.org/protocol/caps" hash="sha-1" node="http://xmpp.rocks" ver="YhsriNHd0WY9WvfFv1FIeNd6Elw="></c></presence>

Original report by Markus KARG (Bitbucket: mkarg, GitHub: mkarg).

Sometimes attempts to connect via TCP are hanging forever. This happens at about ever 25th attempt to connect or even less often, but often enough to be annoying.

So I added "paranoid" tracing to find the problematic code line, and apparently it is the DNS SRV lookup...

LOGGER.finest("Looking up SRV records");
Attributes attributes = ctx.getAttributes(query, new String[]{"SRV"});

Mar 08, 2015 1:12:38 PM TcpConnection connect(Jid) FINER: ENTRY null
Mar 08, 2015 1:12:38 PM rocks.xmpp.core.session.TcpConnection connect FINEST: Getting hostname
Mar 08, 2015 1:12:38 PM TcpConnection connectWithXmppServiceDomain(String) FINER: ENTRY jabber.de
Mar 08, 2015 1:12:38 PM rocks.xmpp.core.session.TcpConnection connectWithXmppServiceDomain FINEST: Creating JNDI context for DNS lookup
Mar 08, 2015 1:12:38 PM rocks.xmpp.core.session.TcpConnection connectWithXmppServiceDomain FINEST: Looking up SRV records

I noticed that the used default timeout is ZERO, which apparently seems to mean INFINITE, which is never a good thing... So my proposal would be to modify the default timeout to be ten seconds or something like that, so Babbler at least has any chance to notice that the DNS server is not responding. Another proposal would setting a retry count as described in http://docs.oracle.com/javase/7/docs/technotes/guides/jndi/jndi-dns.html, so Babbler is not forced to retry on its own, but could safely rely on the JNDI provider doing the retries, hence correctly fail with exception.

The proposed ideas are not tested yet and open for discussion. Anyways, what ASAP should be fixed, is the fact that "INFINITE" is the default, as that leads to hangs definitively.

Original report by Dan Devine (Bitbucket: dandevine, GitHub: dandevine).

Interested in using this library on Tomcat instance with XEP-0114 type connection to Openfire / ejabberd server.

See link to XMPP spec here: http://xmpp.org/extensions/xep-0114.html

Is this possible with this library? Are there any technical limitations that would prevent it?
May be able to provide solution too, I'm just doing a preliminary investigation at present and looking for quick guidance.

Original report by Markus KARG (Bitbucket: mkarg, GitHub: mkarg).

The description of PingManager says that the pings are not sent in case other stanzas as sent.

This is wrong.

(a) Set PingManager to 15 seconds. Wait for 15 seconds. A ping is correctly sent. Then start to send one chat state message per second, and you will notice that after 15 seconds there actually is a ping sent! According to the description, that must not happen.

(b) It actually is a bad idea to not sent any pings in case there are other stanzas sent, as that stanzas do not imply any answers from the server -- so the client cannot detect whether the connection is broken or the server is down. The ping manager must always send pings, independent of any other traffic, so the client will see the fail.

Original report by Markus KARG (Bitbucket: mkarg, GitHub: mkarg).

Exceptions should only happen in case something really exceptional (hence: unexpected) happens. The sense of a ping(Jid) is to know whether or not the chat partner's software still is online. The outcome is expected to be "false" more often than not. Hence, from a design view, ping(Jid) should not throw an exception but instead return a boolean.

BTW, also, from a technical aspect, exceptions should never be used for expected results, as they imply more computational overhead that "normal" results: A result just pops the stack. An exception instead puts new information (the exception object) on the stack. So unless the outcome really is exceptional, it shouldn't be an exception. :-)

Original report by Markus KARG (Bitbucket: mkarg, GitHub: mkarg).

Since JRE5 there is a drop-in replacement for StringBuffer: StringBuilder. That one has the same interface, but is not synchronized. Hence it works faster. :-)

Original report by Markus KARG (Bitbucket: mkarg, GitHub: mkarg).

Since Windows Vista, the Windows operating system family has rather restricted security defaults. On of these defaults is that only system administrators, and even only when acting in an elevated mode, are allows to write into the location where executable code is stored (i. e. %ProgramFiles% and %ProgramFiles(x86)% folders). The aim is that viruses will fail conatimating executable code.

Unfortunately the Babbler library tries to write cache information collocated to the using application. This leads to the fact that an exception happens due to missing access rights:

Feb 05, 2015 11:09:48 AM rocks.xmpp.extensions.caps.EntityCapabilitiesManager wr
iteToCache
WARNUNG: Could not write entity capabilities to persistent cache. Reason: java.i
o.FileNotFoundException: cache\caps\77d6fe485d274c11c97fb609c646a73e244fe065.cap
s (Das System kann den angegebenen Pfad nicht finden)
java.lang.RuntimeException: java.io.FileNotFoundException: cache\caps\77d6fe485d
274c11c97fb609c646a73e244fe065.caps (Das System kann den angegebenen Pfad nicht
finden)
at rocks.xmpp.core.util.cache.DirectoryCache.put(DirectoryCache.java:117
)
at rocks.xmpp.extensions.caps.EntityCapabilitiesManager.writeToCache(Ent
ityCapabilitiesManager.java:285)
at rocks.xmpp.extensions.caps.EntityCapabilitiesManager.access$400(Entit
yCapabilitiesManager.java:85)
at rocks.xmpp.extensions.caps.EntityCapabilitiesManager$4.run(EntityCapa
bilitiesManager.java:398)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.FileNotFoundException: cache\caps\77d6fe485d274c11c97fb609c64
6a73e244fe065.caps (Das System kann den angegebenen Pfad nicht finden)
at java.io.FileOutputStream.open0(Native Method)
at java.io.FileOutputStream.open(Unknown Source)
at java.io.FileOutputStream.(Unknown Source)
at java.io.FileOutputStream.(Unknown Source)
at rocks.xmpp.core.util.cache.DirectoryCache.put(DirectoryCache.java:114
)

The correct solution is to explicitly store this information in the program's profile (on Windows, this is %ProgramData%) or the user's profile (on Windows, this is %AppData%). Both places are the official places where user processed may write into by default.

Original report by cmsimike (Bitbucket: cmsimike, GitHub: cmsimike).

Hi,

I've been prototyping an xmpp bot and one of the features I'd like has to do with broadcasting messages to a room of users. I'm able to confirm that I can log in with my xmpp creds and send a direct message to me.

The issue is that I get the above exception when trying to enter a ChatRoom.

    MultiUserChatManager multiUserChatManager = xmppSession.getExtensionManager(MultiUserChatManager.class);

    ChatService chatService = multiUserChatManager.createChatService(Jid.valueOf("conference.im.xxxx.com"));
    List<ChatRoom> publicRooms = chatService.getPublicRooms();
    System.err.println("public rooms: " + publicRooms); // returns the correct amount of rooms

When I get to the next line, however, I get an exception:

    bottest.enter("xxxxbot");

I've confirmed that my bot does indeed enter the room correctly (as I see it in the list of users) but it always throws an exception. I've set the time out to be 30 seconds but that did not help the situation.

Thoughts?

Original report by Markus KARG (Bitbucket: mkarg, GitHub: mkarg).

Currently PingManager frequently tries to ping server, but simply prints a stack trace when the ping fails. It is doubtful whether this makes pretty much sense: While the stack trace is visible to the end user of a calling application, that user cannot know what the stack trace means hence might "panic", on the other hand, the application would be able to deal with the problem (like disabling application functionality) but has no means to detect the problem.

Hence handling of server ping timeout should be given an improved handling:

• No stack trace printed to not confuse end users.
• Forwarding the server ping timeout to the calling application (i. e. new interface ServerPingListener).
• Possibly changing the XmppSession state and any running Chats.

Original report by Anonymous.

Exception in Room Config : layer_ce61f985-1d2d-4621-97c2-d416424ead9f
rocks.xmpp.core.stanza.StanzaException: - (type 'cancel': do not retry (the error cannot be remedied))
Invalid value for 'whois'
at rocks.xmpp.core.session.XmppSession.query(XmppSession.java:516)
at rocks.xmpp.core.session.XmppSession.query(XmppSession.java:462)
at rocks.xmpp.extensions.muc.ChatRoom.configure(ChatRoom.java:835)

Original report by Anonymous.

don'n work:

#!java
xmppSession.getManager(FileTransferManager.class).addFileTransferOfferListener(event -> {
            try {
                final FileTransfer fileTransfer = event.accept(Paths.get(event.getName()));
            } catch (IOException e) {
                e.printStackTrace();
            }
        });

rocks.xmpp.extensions.filetransfer.FileTransferManager$2 run
WARNING: null
java.lang.NullPointerException
at java.util.Objects.requireNonNull(Objects.java:203)

Original report by Markus KARG (Bitbucket: mkarg, GitHub: mkarg).

Sometimes it happens that one writes code like if (status == A || status == B || status == C) which easily gets hard to read with many status to check.

A solution which not only reduces code size and improves readability, but also provides potentially faster execution due to eager compilation of shared code and using a bit-mask (!) internally, is the use of EnumSet:

if (EnumSet.of(A, B, C).contains(status)

or even better...

static EnumSet ABC = EnumSet.of(A, B, C);
if (ABC.contains(status))

Why is this faster? The trick is twofold. First, there is no need for the JVM to load and interpret lots of custom boolean terms, but it can simply invoke the static enum set. Second, an EnumSet is solely a bitmap. That bitmap is and'ed with the the bitmap provided to contains() or containsAll() ins a single operation, as it fits into one register. In comparison, the binary term has to be executed sequentially, which means many operations.

In reality, a performance gain will only be measurable in scarce cases, as modern CPUs are lightning fast, and the typically the same bitmap pattern is only used seldomly. Nevertheless, it is a good pattern due to its readability, compared to rather long boolean chains.

Original report by Markus KARG (Bitbucket: mkarg, GitHub: mkarg).

Several parts of Babbler are using the same code again and again:

    scheduledExecutorService = Executors.newSingleThreadScheduledExecutor(new ThreadFactory() {
        @Override
        public Thread newThread(Runnable r) {
            Thread thread = new Thread(r, "...thread name...");
            thread.setDaemon(true);
            return thread;
        }
    });

It makes sense to use a common implementation, like

public static final ThreadFactory createNamedThreadFactory(final String threadName) {
return new ThreadFactory() {
@OverRide
public final Thread newThread(final Runnable r) {
final Thread thread = new Thread(r, threadName);
thread.setDaemon(true);
return thread;
}
}
}

Less code = less memory consumption, less load time, less gc length, less possible failure modes, higher execution speed :-)

Original report by Dan Devine (Bitbucket: dandevine, GitHub: dandevine).

Not sure why this is happening..
I'm getting a test failure on the Birthday Card extension test for the 0.6 Snapshot.

marshalBirthDayVCard(rocks.xmpp.extensions.vcard.temp.VCardTest) Time elapsed: 0.008 sec <<< FAILURE!
java.lang.AssertionError: expected [2004-03-20Z] but found [2004-03-19Z]
at org.testng.Assert.fail(Assert.java:94)
at org.testng.Assert.failNotEquals(Assert.java:494)
at org.testng.Assert.assertEquals(Assert.java:123)
at org.testng.Assert.assertEquals(Assert.java:176)
at org.testng.Assert.assertEquals(Assert.java:186)
at rocks.xmpp.extensions.vcard.temp.VCardTest.marshalBirthDayVCard(VCardTest.java:173)

Off by an hour, so I've gotta assume there's some interaction with my time zone?
Anyone else see this?

Thanks in advance.

Original report by Markus KARG (Bitbucket: mkarg, GitHub: mkarg).

Like any non-trivial program, the Babbler library makes strong use of logging. Most logged information in fact is not intended to be presented to the end user, but is merely existing for tracing purposes in case of failure. Rather most logging code is dealing with messages never ever being actually logged in production environment, hence are logged with levels of FINE.

While this is absolutely correct use of the Java Logging API, it bears potential of unnecessary code execution, resulting in effects like processing overhead (i. e. inappropriate power consumption), cache locality desturbance, and heap fragmentation: In case message strings are built at runtime, i. e. concatenated from one or more template literals concatenated with one or more parameters. The reason simply is that lines like LOGGER.log(Level.FINE, String.format("Problem '%s' at line %d!", error, line)); will execute string-building even in case the provided logging level is not being handled by any handler or not being logged by any logger! As we all learned in the early days of Java programming, String concatenation is expensive, because each concatenation implies the technical need to do a full copy of both concatenated terms, hence multiple concatenations copy over and over again the same bytes (and, remember, Java's UNICODE String class implies two bytes in memory per single character). String.format() is an optimization, but cannot reduce the fact that it provides at least one full copy, still.

There are two effective and highly advised solutions:

• Before Java 8
  : Let the Java Logging API build the string for you. It is guaranteed that it will do this only in case the logging level is active:
  LOGGER.log(Level.FINE, "Problem '{0}' at line {0}!", error, line);

• Since Java 8
  : Provide a supplier to the Logging API. It is guaranteed that it will be requested to provide a message string only in case the logging level is active:
  LOGGER.log(Level.FINE, () -> String.format("Problem '{0}' at line {0}!", error, line));

Original report by Anonymous.

You advise in your documentation not to override the default hostnameVerifier.

#!java
TcpConnectionConfiguration tcpConfiguration = TcpConnectionConfiguration.builder()
.hostnameVerifier(hostnameVerifier)

However, I don't think you currently support the ability to connect securely to a server with a certificate which has a name miss-match with the domain. Without overriding it to always return true, the following exception is thrown.

#!java

java.io.IOException: javax.xml.stream.XMLStreamException: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No name matching domain.com found

Turning off ssl allows this connection, but you may still want a secure connection regardless of the validity of the certificate.

It would be nice if you could handle this scenario without having to overriding hostnameVerifier.

The desired behaviour of an application in this scenario would be to popup a dialog asking the user if they want to continue connecting to the server having reviewed the certificate. Currently the connection to the server is terminated by an exception. Would it be possible for a check to be made on the severs certificates, before the full connection step. In this way the details of the certificate can be relayed to the user of the application before a decision is made?

Original report by Sven Bartscher (Bitbucket: Kritzefitz, GitHub: Kritzefitz).

When calling the .close() method on a XmppSession, while another thread, that uses the XmppSession, is running (e.g. PresenceListeners) the running threads throw IllegalStateExceptions, because the XmppSession was closed.

This is very inconvenient. Especially if your main thread doesn't run long enough for letting the other threads process the batch of presence changes after the login.

I would expect the .close() method to wait for the running threads to terminate and only then close the connection (or optionally take a timeout after which the connection is closed, thus crashing the running threads).

Original report by Markus KARG (Bitbucket: mkarg, GitHub: mkarg).

Due to Java's language specification, a in interface's method has to be public when implemented by a class. Extensions have to implement two interfaces: The API, used by the application vendor and typically small (for example only "getAvatar" and "publishAvatar" for AvatarManager), and the SPI, used by the Babbler kernel to invoke extensions (for example sessionStatusChanged, handleMessage and handlePresence). As a consequence, it is sometimes not easy for the begginer to understand what methods of an extensions are part of the API and which are part of the SPI. It would be good if this could be more clear, and to prevent applications from calling SPI methods (so applications do not "see" those messages).

Original report by Markus KARG (Bitbucket: mkarg, GitHub: mkarg).

As the chat partner might switch from one device to a different, partner's software version can change from time to time, and with it, the restrictions of a device. In case a user switches e. g. from laptop to mobile phone, the chat partner might like to get informed about that, since it has the impact that for example he (as a human) SHOULD abstain from offering large pictures, or writing too wide text lines, as the mobile phone user is getting annoyed by that due to the limited bandwidth and small screen of the mobile phone.

The SoftwareVersionManager can be used to explicitly ask for the software version the chat partner is using. Unfortunately it does not offer a simple way to continuously trace a software version, like e. g. the AvatarManager provides. Hence it is a bit tricky to closely follow software version changes in an ongoing chat session.

Therefore it would be a great thing to have a SoftwareVersion Change Listener just the same way there is an Avatar Change Listener: SoftwareVersionManager.addSoftwareVersionChangeListener(Consumer). This would make it much simpler for chat applications to trace ongoing software version changes compared to the current situation where an app has to listen for resource binding and explicitly request software versions as soon as another resource is bound -- and remove current software version once no resource is bound anymore.

Original report by Gary U (Bitbucket: [Gary U](https://bitbucket.org/Gary U), ).

Blabber: 0.5.0
JAXB: 2.2.3 (jaxb-api)
Lombok: 1.16.2

I have found that registered Context classes with Collections members do not unmarshall from XML correctly. The example code is not that dissimilar from the actual code ...

-- Context Class --

@NoArgsConstructor
@getter
@XmlRootElement(name = "example", namespace = "org.example")
@XmlAccessType(XmlAccessType.FIELD)
public class Example {
@XmlElementWrapper(name = "items")
@xmlelement(name = "item")
protected List items;
}

-- XmppSessionConfiguration --
...
.context(new CoreContext(Example.class);
...

-- XmppSession --
...
session.addInboundMessageListener(new MessageListener() {
@OverRide
public void handleMessage(MessageEvent e) {
System.out.println(e.getMessage().getExtension(Example.class));
}
}
...

When the Message.class is unmarshalled from XML the items are not. Having registered the debugger I can see the following with an empty collection:

IN:

But, when I comment out the context class and rerun the same test I see in the debugging output:

IN: applebananacarrot

I have tried two POM dependencies firstly javax.xml.bind (2.2.3) and then com.fasterxml.jackson.core (2.5.1) with the same results. Given the fact that Babbler uses JAXB at its core I would have thought this would had worked?

Original report by Anonymous.

Babbler: 0.5.0
JDK: /Library/Java/JavaVirtualMachines/jdk1.7.0_67.jdk

OUT: <stream:stream xml:lang="en" version="1.0" xmlns="jabber:client" xmlns:stream="http://etherx.jabber.org/streams"><stream:stream xml:lang="en" version="1.0" xmlns="jabber:client" xmlns:stream="http://etherx.jabber.org/streams">

IN : <stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="chat" id="53f4cb76" xml:lang="en" version="1.0">stream:featuresPLAINzlib</stream:features><stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="chat" id="53f4cb76" xml:lang="en" version="1.0">stream:featuresPLAINzlib</stream:features>

OUT: ADEzMjU5ODUwADxWRU5UVVJFPmJvdGVtYW5pYTwvVkVOVFVSRT48VE9LRU4gVFlQRT0iMSI+PFBVQkxJQz48TUVNQkVSLUlEPjEzMjU5ODUwPC9NRU1CRVItSUQ+PE5BTUU+Y3BnYW1pbmc8L05BTUU+PEVYUElSWS1EQVRFPjE0MjcxMjg3ODYzOTk8L0VYUElSWS1EQVRFPjwvUFVCTElDPjxDSVBIRVItVEVYVD5NTllJZXVnYkd1SjdWMXpxOW5NbTgySlRsbWlTc3dKTTRESDJZZmcrL1ZwMmVqUUEwS05PNm1iVUJvK2ZzdTZybWZDYzZCWDdtNyt0b2dFRzRiQUZzUzFRZ0Z3cWQ4bWRZZFN2MFo5Z2RsK2lEdjlNK3ZwNlpkY1ZiMXJVYnQ2Wm8xQWxRblVwTWN5SlBQSURPZWZLWjEvdWo4RHN2RnRaSmpjN3BGSFF4V284SGhVWUkxV2JFbld3UCtkOU9LZytpM0lrTHFoUEJiOGJ0V3MzRUdVT2NIT3VvYVR6VllUaGZZL21Fa1JjZFFjPTwvQ0lQSEVSLVRFWFQ+PC9UT0tFTj4=ADEzMjU5ODUwADxWRU5UVVJFPmJvdGVtYW5pYTwvVkVOVFVSRT48VE9LRU4gVFlQRT0iMSI+PFBVQkxJQz48TUVNQkVSLUlEPjEzMjU5ODUwPC9NRU1CRVItSUQ+PE5BTUU+Y3BnYW1pbmc8L05BTUU+PEVYUElSWS1EQVRFPjE0MjcxMjg3ODYzOTk8L0VYUElSWS1EQVRFPjwvUFVCTElDPjxDSVBIRVItVEVYVD5NTllJZXVnYkd1SjdWMXpxOW5NbTgySlRsbWlTc3dKTTRESDJZZmcrL1ZwMmVqUUEwS05PNm1iVUJvK2ZzdTZybWZDYzZCWDdtNyt0b2dFRzRiQUZzUzFRZ0Z3cWQ4bWRZZFN2MFo5Z2RsK2lEdjlNK3ZwNlpkY1ZiMXJVYnQ2Wm8xQWxRblVwTWN5SlBQSURPZWZLWjEvdWo4RHN2RnRaSmpjN3BGSFF4V284SGhVWUkxV2JFbld3UCtkOU9LZytpM0lrTHFoUEJiOGJ0V3MzRUdVT2NIT3VvYVR6VllUaGZZL21Fa1JjZFFjPTwvQ0lQSEVSLVRFWFQ+PC9UT0tFTj4=

IN :

rocks.xmpp.core.XmppException: javax.xml.stream.XMLStreamException: Can not output XML declaration, after other output has already been done.
at rocks.xmpp.core.session.XmppSession.throwAsXmppExceptionIfNotNull(XmppSession.java:324)
at rocks.xmpp.core.session.XmppSession.loginInternal(XmppSession.java:1101)
at rocks.xmpp.core.session.XmppSession.login(XmppSession.java:1052)
at rocks.xmpp.core.session.XmppSession.login(XmppSession.java:1020)
at rocks.xmpp.core.session.XmppSession.login(XmppSession.java:998)
at rocks.xmpp.core.session.XmppSession.login(XmppSession.java:981)
at gamesys.qa.coreplatform.Test.test(Test.java:53)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:74)
at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:211)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:67)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)
Caused by: javax.xml.stream.XMLStreamException: Can not output XML declaration, after other output has already been done.
at com.ctc.wstx.sw.BaseStreamWriter.throwOutputError(BaseStreamWriter.java:1473)
at com.ctc.wstx.sw.BaseStreamWriter.reportNwfStructure(BaseStreamWriter.java:1502)
at com.ctc.wstx.sw.BaseStreamWriter.doWriteStartDocument(BaseStreamWriter.java:699)
at com.ctc.wstx.sw.BaseStreamWriter.writeStartDocument(BaseStreamWriter.java:687)
at rocks.xmpp.core.session.XmppStreamWriter$3.run(XmppStreamWriter.java:190)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)

Exception in thread "XMPP Writer Thread" java.lang.NoSuchMethodError: java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView;
at rocks.xmpp.core.subscription.PresenceManager$3.sessionStatusChanged(PresenceManager.java:108)
at rocks.xmpp.core.session.XmppSession.notifySessionStatusListeners(XmppSession.java:1488)
at rocks.xmpp.core.session.XmppSession.updateStatus(XmppSession.java:1479)
at rocks.xmpp.core.session.XmppSession.notifyException(XmppSession.java:1320)
at rocks.xmpp.core.session.XmppStreamWriter.notifyException(XmppStreamWriter.java:267)
at rocks.xmpp.core.session.XmppStreamWriter.access$200(XmppStreamWriter.java:54)
at rocks.xmpp.core.session.XmppStreamWriter$3.run(XmppStreamWriter.java:210)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)

Process finished with exit code 255

Original report by Markus KARG (Bitbucket: mkarg, GitHub: mkarg).

Tried to receive an avatar, but got another stack trace :-(

IN : <presence from="[email protected]/standalone"><priority>10</priority><c xmlns="http://jabber.org/protocol/caps" hash="sha-1" node="http://xmpp.rocks"
ver="sOPln8pAyLKewaaJAhBHIJTPIVE="></c></presence>
OUT: <message to="[email protected]" type="chat"><thread>549db665-cf61-4334-a39a-cf025daec618</thread><gone xmlns="http://jabber.org/protocol/chatstates"></gone><
/message>
IN : <presence from="[email protected]/standalone"><priority>10</priority><c xmlns="http://jabber.org/protocol/caps" hash="sha-1" node="http://xmpp.rocks"
ver="YhsriNHd0WY9WvfFv1FIeNd6Elw="></c><x xmlns="vcard-temp:x:update"></x></presence>
OUT: <iq from="[email protected]/standalone" id="disco" to="[email protected]" type="result"><query xmlns="http://jabber.org/protocol/disco#info"><ide
ntity category="client" type="pc"></identity><feature var="http://jabber.org/protocol/bytestreams"></feature><feature var="http://jabber.org/protocol/caps"></fe
ature><feature var="http://jabber.org/protocol/chatstates"></feature><feature var="http://jabber.org/protocol/disco#info"></feature><feature var="http://jabber.
org/protocol/disco#items"></feature><feature var="http://jabber.org/protocol/ibb"></feature><feature var="http://jabber.org/protocol/rsm"></feature><feature var
="http://jabber.org/protocol/si"></feature><feature var="http://jabber.org/protocol/si/profile/file-transfer"></feature><feature var="jabber:iq:last"></feature>
<feature var="jabber:iq:oob"></feature><feature var="jabber:iq:version"></feature><feature var="jabber:x:oob"></feature><feature var="jid\20escaping"></feature>
<feature var="urn:xmpp:avatar:metadata"></feature><feature var="urn:xmpp:avatar:metadata+notify"></feature><feature var="urn:xmpp:hash-function-text-names:md5">
</feature><feature var="urn:xmpp:hash-function-text-names:sha-1"></feature><feature var="urn:xmpp:hash-function-text-names:sha-224"></feature><feature var="urn:
xmpp:hash-function-text-names:sha-256"></feature><feature var="urn:xmpp:hash-function-text-names:sha-384"></feature><feature var="urn:xmpp:hash-function-text-na
mes:sha-512"></feature><feature var="urn:xmpp:hashes:1"></feature><feature var="urn:xmpp:ping"></feature><feature var="urn:xmpp:time"></feature><feature var="vc
ard-temp"></feature></query></iq>
IN : <iq id="053f4962-54e6-4bcc-8329-297e2026d619" to="[email protected]/standalone" type="error"><error type="cancel"><item-not-found xmlns="urn:ietf:para
ms:xml:ns:xmpp-stanzas"></item-not-found></error></iq>
Feb 15, 2015 9:28:02 AM rocks.xmpp.extensions.avatar.AvatarManager$2 run
WARNUNG: <item-not-found/>  -  (type 'cancel': do not retry (the error cannot be remedied))
rocks.xmpp.core.stanza.StanzaException: <item-not-found/>  -  (type 'cancel': do not retry (the error cannot be remedied))
        at rocks.xmpp.core.session.XmppSession.query(XmppSession.java:563)
        at rocks.xmpp.core.session.XmppSession.query(XmppSession.java:506)
        at rocks.xmpp.extensions.vcard.temp.VCardManager.getVCard(VCardManager.java:61)
        at rocks.xmpp.extensions.avatar.AvatarManager.getAvatarByVCard(AvatarManager.java:184)
        at rocks.xmpp.extensions.avatar.AvatarManager.access$000(AvatarManager.java:83)
        at rocks.xmpp.extensions.avatar.AvatarManager$2.run(AvatarManager.java:496)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)