Hello guys,
I ve got a problem : when I want to send a request to add a new user to my roster, the user has to be online, else, the request is not taken in care, and in the openfire console, there is no line corresponding to this request.
How can I change this ?
However, when both users are connected, it works perfectly
Any idea ?
Thx for all,
SKahrz
I’ve never experienced that behavior.
However, there’s a relating bug in Openfire:
If you send a subscription request with a element to transport some additional text like “Hi, please add me to your contact list” (as suggested by the XMPP Core specification), Openfire will neglect that element in case the contact is offline. (+ any other presence extensions).
AFAIK, there’s no bug in the issuetracker yet. Maybe somebody could create one?!
This is how I do to send a subscription request :
Presence pres = new Presence(type);
pres.setTo(jid);
m_connexion.sendPacket(pres);
RosterPacket r = new RosterPacket();
r.setType(IQ.Type.SET);
Item ri = new Item(jid, null);
ri.setItemType(RosterPacket.ItemType.both);
r.addRosterItem(ri);
m_connexion.sendPacket®;
Am I wrong ?
ri.setItemType(RosterPacket.ItemType.both);
should be ignored by the server, but that is probably not the error.
http://xmpp.org/rfcs/rfc6121.html#roster-syntax-actions-set
The server MUST ignore any value of the ‘subscription’ attribute other than “remove”
Otherwise it looks well. But maybe try adding the item first and then send presence. Maybe Openfire overwrites pending subscription requests, if you update the roster afterwards.
In fact, when I use this, if the user is disconnected, the state of the request in openfire is “none”. Actually, it should be “to” no ?
And I tryed what you said, it didnt work
No. “none” is correct. It would be “to” if the contact has affirmed the subscription request, which it can’t, since it is not connected.
So, how can I get the state of a request ? For example, if I have a user A who requests a user B.
If B use a search function, how can I see if he receives à request, or if he sent a request, or if he is actually friend with the A user ?
Cause, I m probably wrong in my actual algorithm :
for (RosterEntry entry : entries) {
if(entry.getUser().equals(jid))
{
if(entry.getType().equals(ItemType.from))
{
result = 1; // sent by the oponent
}
if(entry.getType().equals(ItemType.to))
{
result = 2; //sent To the oponent
}
if(entry.getType().equals(ItemType.both))
{
result = 3; // actually friend
}
break;
}
}
So, when I send a request, with the “none” value, result is still equal to 0 , and I have always “add to friend” display on the button instead of a different info corresponding of the result value
AFAIK, you can only see “pending outgoing” presence subscriptions.
http://xmpp.org/rfcs/rfc6121.html#roster-syntax-items-ask
That means if User B has ask=“subscribe” in User A roster it means, that User A is still waiting on a response from User B.
If you want to know if User B has sent you (User A) a subscription request, but you didn’t respond yet, that is probably reflected in your roster with ItemType.none.
In my case, if A send a request to B, A will have a request with ItemType.none
But B doesnt have one… It’s problematic, I cant determine if anybody get a request from another user :-o
I can’t follow…
Here’s the workflow which works for me:
If A sends a subscription request to B, the server will make a roster push to A.
In that roster, User B is marked with subscription=“ask”, which indicates that B has not yet responded to A’s request.
If you want to know from B’s perspective if A has sent you a request, you can’t know that just by the roster item, but it’s probably “none”.
But you obviously know it, if you have received a presence of type=“subscribe”.
Ok, I’ll explain correctly what my problem is.
I have a user A.
This user sends a request to B.
The ItemType is actually None in A roster.
B has no entry in his roster actually.
My question is :
How could I know who requested B ? B has no entry in his roster, so how could I do this ?
The only information I have, is that A KNOWS that he sent a request to B. But B DOESNT KNOW that A wants to add him to his roster.
I m new in this big world, it’s a bit complicated sometimes…
Thanks for your help by the way 
Ah, ok. Just add a PacketListener to the connection object.
something like this:
connection.addPacketListener(new IncomingPresenceListener(), new PacketTypeFilter(Presence.class));
(IncomingPresenceListener is a class which implements PacketListener)
Then cast the packet into Presence and check for type==subscribe.
And what if I receive a message when I am offline ?
I ll have the request in a queue, loaded at the start of the connexion ?
Your XMPP server will then store the message and will deliver it as soon as you become available.
Thank you. I will try this.
However, I always got my problem.
When I send a subscribe request, it’s “none” in both roster. When the second user is connected (not accepting), the request switch to “to” or “from”, corresponding to the user.
Can I have the “to” and “from” state at the first request instead of “none” in both roster ?
I am not sure about this.
Usually it goes like this:
User A sends “subscribe”
User B responds with “subscribed” (accept) or “unsubscribed” (deny)
User B also sends a “subscribe” to make the subscription mutual “both”
User A responds with “subscribed”.
=> both rosters have “both”.
I guess, when User A sends “subscribe”, the state is still “none”.
If User B responds with “subscribed” it changes to “to” or “from”.
If User A also grants subscription by sending “subscribed”, it changes to “both”.
Yes, but the state changes if the user is offline or online.
If A is connected, and send a request to B who’s not connected, both will have a request with “none”.
When B will be connected, the state will be automatically changed. A will have “to” instead of none, and B will have “from” instead of “none”.
This is my real problem
Maybe you should check the real network traffic, i.e. look at the (presence) stanzas being sent and received by A and B.
Maybe B receives the “subscribe” and autosends “subscribed” back, which will cause the change.