DiscoverInfo for PubSubNode Failing

Good afternoon,

I am writing a Smack application and am using the OpenFire server.

I’ve tried these two methods of querying info about a pubsub node, both with the same results:

ServiceDiscoveryManager sdm = ServiceDiscoveryManager.getInstance(connection);
DiscoverInfo di = sdm.discoverInfo("pubsub.domain", "nodeName");


final IQ iq = new IQ () {
     public String getChildElementXML() {
          return "<query xmlns='' node ='nodeName' />";
}; iq.setType(IQ.Type.GET);

Both of these attempts (which are the same), result in the same error:

<iq id='123abc' to='myusername@domain' from='pubsub.domain' type='error'><error code='500' type='WAIT'><internal-server-error xmlns="urn:ietf:params:xml:ns:xmpp-stanzas'/></error></iq>

Any help with what I’m doing wrong, or is this something I must enable in OpenFire?

Also, I’ll state my goal because perhaps there is an easier way to achieve it. I have an account I’ve setup as the pubsub - sysadmin. This seems to work as i can subscribe/unsubscribe other users to a given node. What I’d like to do with this pubsub-admin account, is to see if a user is subscribed to a given node, or just to see all users subscribed to a node, or to see every node a user is subscribed to.

Try PubsubManager.getNode(“nodeId”) and then node.discoverInfo() and node.getSubscriptions()? These are convenience methods for getting at least some of the information you are looking for.

Is this PubsubManager a part of Smack by default or is it still the extension that you wrote? Problem there is it is not easy in my environment to grab extensions (or even to get the latest version of smack for that matter).

Also, the message I’m sending to the server is the one defined in the protocol: XEP-0060

So, I’m not sure it would make a difference if I change the code sending the message if the correct message is going to the server (determined by watching Smack debugger)?

Also, do you think this question may belong in OpenFire discussions?

Edit: I see it’s become part of 3.2, which I may eventually get, but for now I’m going to try to avoid updating from 3.1.

Found my problem. I was not setting the access_model to ‘open’ when creating my node, and assumed that was the default. I deleted and re-created my pubsub node with an open access model and now I can get to the information I want.

Thanks for your time rcollier : ).

Glad you found your problem. But to answer your other question, the extension in question is in the new Beta2 release and will of course be in the upcoming 3.2 release. If updating is an issue, that is too bad for you, since the pubsub API is not part of the previous release. Updating to the new beta release and the full release when it is ready would make life much easier for you.

We’ll eventually get the newer versions, but I’ll have to proceed without the pubsub API unfortunately for now and write the raw stanzas.

Do you know if they plan on adding somethign to the admin console for administering a pubsub? My plan for the moment is to create a Java GUI for creating/deleting nodes, viewing subscribers etc…


Althougth I fixed my ‘error’, it still didn’t yield the results I really need. I’m reading through the spec (XEP-0060), what I need is a way for my pubsub sysadmin to get a list of all subscribers to a given node, having a hard time finding the right stanza to use.

And I found my own answer, just had to keep going through spec:

proper stanza: Retrieive Subs

Thanks again, you’ve been very helpful!

There is a Jira issue for the admin UI. Unfortunately I don’t know how to do it right now and I don’t have time to learn

A word of warning to you, OpenFire does not implement the most recent version of the pubsub spec, so there are some differences in what the spec supports and what OpenFire does.

Good to know that it doesn’t implement the most recent, I think; fortunately, I have all the pieces I ‘need’ for now.

Seems like the OpenFire community is pretty active. I’m working on multiple projects involving xmpp, perhaps at some point in the distant future I can become more active myself with ignite.

Here’s hoping they get some free clustering going on in the future .

Here’s hoping you have time to contribute in the NOT so distant future

Strangely this problem has reappeared. previously I switched the access_model and then I could do a disco#info on a pubsub node. I’ve created another node since then, but other than that have not really modified the pubsub (besides publishing a bunch o’ items).