Bug in group integration using PostGreSQL


I posted a message some days ago in the support forum asking about the behaviour of Wildfire (Openfire) when integrating groups, which was incorrect. While I was able to customize Auth and Users, Groups simply refused to work. If I didn’'t integrate groups and let Wildfire manage them, everything was just perfect, enabling group sharing between members of a group and the stuff.

As I couldn’‘t get any helpful answer I solved the problem by myself (or at least that’‘s what I’‘m hoping) and thought I would post it so it can be corrected in future versions of Wildfire (Openfire). I’‘m now using version 3.2.3, but this error existed in 3.1.1. I downloaded the source, built it and debugged in Eclipse, and found how groups wouldn’'t appear in roster list of users even though they belonged to the group. Also, if I shared the groups with ALL users, then all the users in the server appeared in the roster of each other user but appeared as Transport Agents, not “normal” clients.

I think the problem exists in “src/java/org/jivesoftware/wildfire/group/JDBCGroupProvider.java”, on the “getMembers” method. Once the ResultSet is retrieved, the domain and resources are set to the value of the node since they are not retrived, and the lack of checking creates objects “users” with all the fields set to the same value. However, I found in the same method (getMembers) in class “DefaultGroupProvider.java” how this verification was properly done. All I did was, right after:

while (rs.next()) {

String user = rs.getString(1);

if (user != null) {

JID userJID = new JID(user);

Copied and pasted the following into “getMembers” of “JDBCGroupProvider.java”,

if (user.indexOf(’’@’’) == -1) {

// Create JID of local user if JID does not match a component’'s JID

if (!server.matchesComponent(userJID)) {

userJID = server.createJID(user, null);

else {

userJID = new JID(user);


I also had to add the following at the beggining of the class:

private XMPPServer server = XMPPServer.getInstance();

These two modifications did the job, so I now can connect to my customized group list and it will properly appear in the clients roster.

Hope this helps,


P.S. I also noticed a typo in the integration guide (http://www.igniterealtime.org/builds/wildfire/docs/latest/documentation/db-integ ration-guide.html), where the “Group Integration” part has some FORM instead of FROM in the SQL sentences, an error that took me forever to find. This other one is a minor annoyance, but the guide tries to retrieve users and admins with “isAdmin=’‘N’’” or “isAdmin=’‘Y’’”, while the examples and tables that Wildfire uses have this attribute stored as an integer with values ‘‘0’’ and ‘‘1’’.

Hi again,

While I noticed that my little round-up solution allowed the clients to properly load the groups they belong to and members of those groups, it has now brought a problem with presence not being properly redistributed. This is the scenario: user A connects and belongs to the group “family”. Now, user B, who also belongs to “family” connects and in his roster user A appears as connected. BUT, user A doesn’'t see user B as connected (nor notices any other change in his presence) until he reconnects.

Again, any help would be appreciated.

Thanks a lot

Hi again,

Once again I managed to find out the bug existing in “JDBCGroupProvider.java”, in method “public Collection<String> getGroupNames(JID user)” where the PreparedStatement “pstmt.setString(1, user.toString());” should be "

pstmt.setString(1, server.isLocal(user) ? user.getNode() : user.toString());" as in “DefaultGroupProvider.java”.

This bug prevented Wildfire server from updating presence to other members of the shared groups, since it didn’'t properly collect the group names out of the DataBase (PostGreSQL).

I hope this helps


I did create JM-1020 to track this issue. I didn’‘t look at the code so far but this issue makes sure that someone will. So it’'s probably a little bit to early to say thanks for a bug report (;