Hi,
After viewing the HSQL and database design of the Jive Messenger Server , I could figure out that most of the attributes are not persisted to the database and thus can’'t be retrieved at later stage .
Like, in presence.setProperty() ; method there is no place holder for this property and hence is not retrieved.
Kinldy suggest what can be done for such issues …
Hi Neeraj,
Wildfire stores a lot of information in memory, it makes no sense to store non-persistent data in the database. But you can access nearly all values using Smack. I did not check for presence, maybe this is a bug?
It would help a lot if you could post a short example which so one can reproduce this problem.
LG
hi,
I appreciate your reply and if you find any problems in understanding just let me know.
Environment : JiveMessenger Server and Smack API
Step1 : User1 connects to the server using the code,
XMPPConnection conn = new XMPPConnection(SERVER_NAME);
//Set the Default Subsciption mode to Manual
conn.getRoster().setDefaultSubscriptionMode(Roster.SUBSCRIPTION_MANUAL)
//Login to the Server
conn.login(userId,password);
//Check the authencity and send it accordingly
if(conn.isAuthenticated()&& conn.isConnected()){
return conn;
}
Step2: Add a Packet Collector to the XMPPConnection conn as obtained in Step1 with Packet filter for the Presence Type of messages,
PacketCollector packetCollector = conn.createPacketCollector(
new PacketFilter(){
public boolean accept(Packet packet) {
if(packet instanceof Presence){
Presence presence = (Presence)packet;
if(presence.getType() == Presence.Type.SUBSCRIBE ||
presence.getType() == Presence.Type.SUBSCRIBED ||
presence.getType() == Presence.Type.UNSUBSCRIBE ||
presence.getType() == Presence.Type.UNSUBSCRIBED
presence.getType() == Presence.Type.AVAILABLE
presence.getType() == Presence.Type.UNAVAILABLE
){
return true;
}
return false;
}
return false;
}
}
);
Step3 : Create a packet of type Presence send it to user2 as below ,
Presence presence = new Presence (Presence.Type.SUBSCRIBE);
presence.setTo(“user2” + SERVER_NAME);
presence.setProperty(“ProfileName” , “JUST ROCK”);
System.out.println("Packet Sent : " + presence.toXML());
conn.sendPacket(presence);
Step4 : Now connect user2 with the server as done in step 1 and 2 for user1 and then try to check the packets in the Packet collector (intialized in step2) of user2 as,
Packet packet = packetCollector.nextResult(1000);
if (packet instanceof Presence){
System.out.println("Packet Recieved : " + packet.toXML())
}
If you compare the packet sent and recieved there will be a node for the property in packet sent which will not be there in packet recieved .
-Neeraj
Hi,
so it’‘s the jiveRoster table which should be able to store these values for offline users. Maybe the Wifi dev’‘s like to add another column. I didn’'t read the JEP, are there even more values which should be added? Spark does not offer to add a description, so using Spark one will likely not encounter this problem.
LG
public class RosterItemProvider {
private static final String CREATE_ROSTER_ITEM =
"INSERT INTO jiveRoster (username, rosterID, jid, sub, ask, recv, nick) " +
“VALUES (?, ?, ?, ?, ?, ?, ?)”;
/code
Hi,
may a developer review this and probably create an JM issue?
LG
ping
Neeraj,
Could you try out the Smack debugger? We need to track down whether this is a Smack issue or a Wildfire issue. I believe that the server should be passing along extensions in presence packets, so this could be a bug.
Regards,
Matt
Hi Matt,
where (in which column or table) should this value be stored if the 2nd user is offline?
If both users are online there is no problem.
LG
If both users are online there is no problem.
Ahh, I see – it’‘s only a problem with offline presence subscriptions being delivered. I’‘m not sure if this is a bug or expected behavior, honestly. I’'ll ask Gato to get his opinion…
Thanks,
Matt
Hi Matt,
it seems that not too much did happen since your last post…
LG
As far as we can tell, there’'s nothing in the XMPP spec that says that we should be persisting and delivering the packet extensions for offline presence requests. Adding in support would require some decently substantial changes.
Regards,
Matt