powered by Jive Software

Unclear intialization of ServiceDiscoveryManager


I’‘m using Smack 1.3.0 and I found out that ServiceDiscoveryManager as well as XHTMLManager (and maybe others) use a static body to add themselves as ConnectionEstablishedListenerS. The problem is that -at least with Sun’'s client VM 1.4.2- in order for the static body to be called the class must have been previously referenced.

That is a problem when you reference one of these classes from a ConnectionEstablishedListener handler or even from the same block that calls the XMPPConnection#login method, for instance to set yourself as a not-XHTML-IM-capable client. As it might be the first time that the program accesses those classes, they haven’‘t been yet initialized, that means they didn’‘t have a chance to add themselves to the CEL handlers list, therefore they don’'t get called when the connection is established and you get a NullException.

I workarounded with the following code within the static initializer of my class:

try {


} catch (ClassNotFoundException e) {




I suggest fixing this by using lazy creation of the object in the case of ServiceDiscoveryManager.

I also don’‘t think it’‘s a good idea to add a CEL handler automatically to enable the XHTML service, as it might override the application’'s preferences set from that same handler, depending on the order in which the handlers were added to the list.

I think the best solution to this issue may be to load all packet providers when Smack first starts up. This will:

  • Make sure we don’'t run into this static initializer bug you describe.

  • Won’‘t trample on a user’'s settings if they set their own parser for a particular packet extension programatically.

This change might also remove the need for startup classes in SmackConfiguration? I’‘ll have to think about that a bit… In any case, I’‘ll file an issue on this and we’‘ll get it fixed in the near future. I’'ll post an update to this thread when the fix is in CVS.



Copying smack-config.xml into my source tree from the JAR that comes with the distribution solved this problem. I guess I missed that from the docs.