How to report bugs im Smack?

Smack Smack Dev
1

Hi,

we use Smack and I wonder if it is possible to report bugs directly in the issue tracker?

I logged in to Jira, but I can’t find an “Create Issue” button.

The issue I found:

org.jivesoftware.smackx.packet.StreamInitiation#setSesssionID

has a typo (three s)

2

The issue tracker is not publicly available for creating new issues. Issues are reported in the forums, as you just did. You should also use the tag bug_report

SMACK-427

3

Hi,

In general, we like to handle these in the forums to prevent support requests from showing up in Jira. If you have some other bugs to report and would report more in the future, then I can get you elevated privs in Jira to report these.

daryl

4

Ok, I understand. I am ok with it, if I can report them here.

Currently I have no bugs to report. Smack is actually quite stable :slight_smile:

But two minor things I remember:

  1. RosterEntry had an issue, when you put it as key in a hash map. I believe it is because it does override the equals method but does NOT override the hashCode method.

I think I put it in a HashMap as key, and the called get() with the same object and the map returned null.

  1. Smack and Openfire should really use the same Core Library (Tinder) for Packets. We develop our own extensions and sometimes need them to process them in Openfire plugins as well. And it is difficult because both extensions are complete different objects. Openfire uses dom4j and Smack uses XmlPullParser.
5

And two improvements:

3.:

The MUC API could be easier to use. Especially the form. Right now, you have to read the XMPP specification to fill the form with String values like:

“muc#roomconfig_persistentroom”

An enum or constants for all possible values would help.

4.:

Enum values in general should be written UPPERCASE, as far as I am concerned. (e.g. Message.Type.CHAT)

6

  1. Good catch. SMACK-428

  2. Not likely to happen. There is little need to share a common code base between Smack and Openfire as they server fundamentally different purposes.

  3. Agreed. It should change to the same way it is done in pubsub. SMACK-429

  4. I personally don’t care if it is upper case or not although they are typically uppercase. I can only assume it was written this way since it makes the enums directly compatible with their representations in XMPP, without having custom methods to translate between them. This will not change as it would break any existing API usage with no real benefit.