Actually, trying to print the roster entries out returns nothing like you said...I, will keep trying and report back if I have any success.

Any ideas Matt?

Cheers,

ribot.

Was there a resolution/workaround found for that problem. I have the exact same issue. Did that use to work on earlier version of the lib?

I think that code used to work. However, the roster code definitely needs to be polished up. I''ll see if I can get to that this weekend.

Regards,

Matt

Anyone managed to get the roster up and going? My attempts so far have failed.

Has anyone tired hacking around with the Smack source?

I could do with a quick fix solution in case Beta 4 isn''t released in time for my hand in date.

Thanks

Ben

I guess the real solution is to add a simple listener so that you can know when to load the roster after changes. I''ll try to get this done for the next beta.

Regards,

Matt

I would say that since the Roster is like the other high-level components of the library, I would make it act like the Message, Chat, GroupChat object with the same type of "PollMessage"/queue type arrangement. Or just add a "loadCompleted()" method call.

John

Matt,

I don''t think the login method should block, but the conn.getRoster() probably should. Maybe even eliminate and roster stuff from the login method altogether though I guess it would speed things up if login went ahead and asked for it async but getRoster blocks until it''s completed.

Take care,

John

Hi Matt and John,

I agree with this approach.  I have tried to make the getRoster() method blocking and made the GUI application that is loading the roster to execute in a separate thread.  Here are some of my suggested codes:

private boolean isRosterReady = false;

  public Iterator getGroups() {

    while (!isRosterReady) {

      try {

        wait(); 

      } catch (InterruptedException ie) {

      }

    }

    synchronized (groups) {

      List groupsList = Collections.unmodifiableList(new ArrayList(groups.values()));

      return groupsList.iterator();

    }

  }

  private class RosterListener implements PacketListener {

public void processPacket(Packet packet) {

      isRosterReady = false;

// same as the rest of the code body

      // Notify waiting threads that the roster groups are ready.

      isRosterReady = true;

      notifyAll();

    }

}

Hi,

I noted a number of other potential problems with the roster. 

1) The roster needs to have a blocking thread operation which fires an event when the roster is completely loaded. This can be done by implementing another static class (such as RosterSynchronizer) to handle roster synchronization.  A statement such as "RosterSynchronizer.getRosterSynchronizer().setRosterReady();" can be set at the end of the method "processPacket(Packet packet)" in class RosterListener now.

Similarly, the call to roster.getGroups() should be blocked by a statement like "RosterSynchronizer.getRosterSynchronizer().waitRoster();"

2) Another problem is that there could be a race problem between Presence messages that are sent by the server even before the roster packet is sent or completely loaded.  In this case, all Presence packets need to be pre-stored in an early-queue until the roster ready event is fired.  Once the roster is ready, the early Presence packets will need to be processed.  Else, the presence info will be lost! 

Hope I intepret the potential problems correctly and got the message across correctly

Cheers,

Joe