powered by Jive Software

Problem with XMPPTCPConnectionConfiguration.Builder setXmppDomain and related method not found

In Smack 4.2.0, I am not able to access the setXmppDomain methods or the setInetAddress method of XMPPTCPConnectionConfiguration.Builder. In the former case, the code compiles correctly but fails on execution with the error:

java.lang.NoSuchMethodError: org.jivesoftware.smack.tcp.XMPPTCPConnectionConfiguration$Builder.setXmppDomain (Ljava/lang/String;)Lorg/jivesoftware/smack/ConnectionConfiguration$Builder;

Unfortunately I think this makes it impossible to use a custom configuration with XMPP TCP Connections? I have checked via reflection during execution and indeed the returned builder class does not include the setXmppDomain methods. It seems to be a different class or different version than indicated in the source? Could this be a JAR/packaging problem or problem with Maven/repository?

In trying to access the setInetAddress method, I get a different runtime exception (again, compiling is fine):

java.lang.NoSuchMethodError: org.jxmpp.util.cache.Cache.lookup(Ljava/lang/Object;)Ljava/lang/Object;

My application is deployed as an EAR. This is my Gradle configuration:

maven {
url ‘https://oss.sonatype.org/content/repositories/snapshots

dependencies {

earlib “org.igniterealtime.smack:smack-java7:4.2.0”
// Optional for XMPPTCPConnection
earlib “org.igniterealtime.smack:smack-tcp:4.2.0”
// Optional for XMPP-IM (RFC 6121) support (Roster, Threaded Chats, …)
earlib “org.igniterealtime.smack:smack-im:4.2.0”
// Optional for XMPP extensions support
earlib “org.igniterealtime.smack:smack-extensions:4.2.0”


(Side note: I have no idea why this pasted as a table?)

This is my code:

// Create our configuration
XMPPTCPConnectionConfiguration.Builder configurationBuilder = XMPPTCPConnectionConfiguration.builder();
configurationBuilder.setXmppDomain(messagingServerHost); // <------- Fails with method not found
configurationBuilder.setUsernameAndPassword(userName, password);
configurationBuilder.setSecurityMode(ConnectionConfiguration.SecurityMode.disabl ed); // XMPP server is on same host as app

// etc…

// Create configuration
XMPPTCPConnectionConfiguration conf = configurationBuilder.build();

The messagingServerHost is a string with the domain.

I have also tried using a bare JID domain, etc., but none of the methods seem to allow me to set the address of the XMPP server, which makes it seemingly impossible to use the custom configuration? Any help is appreciated, thanks!!

Sounds like a stale class shadowing in the classpath. Did you try something like “gradle clean” followed by the command to rebuild the IDE of your choice’s configuration, e.g. “gradle eclipse”?

A good suggestion. I am running NetBeans 8.1 on Windows. I went to the ~/.netbeans folder and deleted everything under cache and I also went to our Archiva server and deleted its cached copies of the smack artifacts from Maven. I also deleted the cache files under the .nbgradle private cache folder. This forced NB and Gradle to reload all the dependencies, which took a while, but unfortunately made no difference. I am running the latest build of Payara server and checked its deployed applications folder and the JARs located under it for this application include the smack-tcp-4.2.0.jar. It seems to be the correct version. (I opened it up.) I am at a loss as to where it could be getting a different set of classes for runtime? I’ve looked at the source code and unfortunately the Builder uses a design pattern that I am not familiar with, and it’s not obvious to me how to trace the inheritance. I will say that I have also seen this same problem reported by a few other users (one in Smack 4.1.8) but there have been no answers posted, so I’m wondering if it is something more fundamental than just my development system? Very weird…

Well I have discovered the problem. Glassfish/Payara includes Smack within it (specifically in the glassfish/modules folder) as it apparently uses smack for some kind of internal notifications. Because of a long-standing GF bug, classes from within GF can leak into applications. In Payara, this can be solved on an application-by-application basis by including a glassfish-application.xml file with the contents:


Including this solved everything…