10-17 10:40:13.540 29462-29975/com.canshu.canshuchat W/AbstractXMPPConnection﹕ Connection closed with error java.text.ParseException: Unparseable date: “20141017T02:40:06” (at offset 8) at java.text.DateFormat.parse(DateFormat.java:555) at org.jxmpp.util.XmppDateTime$DateFormatType.parse(XmppDateTime.java:99) at org.jxmpp.util.XmppDateTime.parseXEP0082Date(XmppDateTime.java:150) at org.jivesoftware.smackx.delay.provider.DelayInformationProvider.parseDate(Delay InformationProvider.java:33) at org.jivesoftware.smackx.delay.provider.AbstractDelayInformationProvider.parseEx tension(AbstractDelayInformationProvider.java:50) at org.jivesoftware.smack.util.PacketParserUtils.parsePacketExtension(PacketParser Utils.java:892) at org.jivesoftware.smack.util.PacketParserUtils.parseMessage(PacketParserUtils.ja va:241) at org.jivesoftware.smack.util.PacketParserUtils.parseStanza(PacketParserUtils.jav a:122) at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPC onnection.java:1022) at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$200(XMPPTCPCon nection.java:969) at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnecti on.java:988)
The problem is, that “20141017T02:40:06” is no valid date format as per XEP-0082, which must be “CCYY-MM-DDThh:mm:ss[.sss]TZD”.
Flow, I suggest to not close the connection on such a parse error, but simply log a warning.
I think this is the api bug, because I did not set about this time, I think this api should be able to adapt themselves this error
Flow, I suggest to not close the connection on such a parse error, but simply log a warning.
Thats something that has been discussed before. It’s not as easy as just “ignoring exceptions”, the parser must be in a valid state after such an exception has been occured. Smack supports since a few versions (3.3 I think) the ParsingExceptionCallback, which can be configured to ignore the Exception and set the parser “to the next stream element”, see XMPPTCPConnection.setParsingExceptionCallback(ParsingExceptionCallback).
But the default will always be throw.
Ok, I haven’t looked at the parsing code, but I thought as it’s no “XMLParseException”, but a “DateParseException”, it would be more easily doable.
E.g.
try {
Date date = parseDate(parser.getText());
}
catch (Exception e) {
// log
}
finally {
parser.nextElement();
}
I mean the XML is still well-formed, it just contains unexpected content here, so it shouldn’t confuse the parser too much, no?
Similarly, how are unspecified enum values handled, e.g. if Smack receives ? I think this example is comparable to the date example, since it’s unexpected content, too.
Ignoring the error in this way means that information that is meant for the receiver is not delivered to the receiver and that the receiver is not aware of this. That is why masking such errors from the user is pretty bad.
Similarly, how are unspecified enum values handled, e.g. if Smack receives ? I think this example is comparable to the date example, since it’s unexpected content, too.
Never extend XMPP in this way. If you define custom values (or attributes) for top level XMPP elements, you are extending XMPP the wrong way. Be aware that XMPP is sacred.
If I don’t draw a line how to allow Smack extending, people would start extending XMPP in all kinds of ways, breaking interoperability.
For example, how would you expect an XMPP server to route a message of type “foo”? There are well defined rules for stanza routing, that’s why you MUST NOT invent custom message types.
No, of course I don’t want to extend XMPP in such a bad way. But I’ve already seen (upper case), which either came from an older Smack version, or maybe from ejabberd, I can’t remember/know exactly.
If you would convert this to an enum e.g. using Enum.valueOf it would throw an IllegalArgumentException, very similar to the exception on a wrong date.
I was curisous, if the connection is closed in that case, too, or how do you deal with it?
Btw, your link about extending in the wrong way is hilarious 
But I’ve already seen
Case sensitiveness is something on my TODO list. The question is whenever to lowercase the input for Enum.valueOf() or not. I don’t think that ‘error’ == “ERROR” == “eRRoR”, so in this example, we have a wrong IQ type. Therefore Smack is not really required to lowercase the type prior calling valueOf(). I also have never heard a report that this is an actual issue in deployments, you are the first who tells me about that, and it appears the issue is also solved (e.g. the entity does no longer produce uppercase type values).
thanks