Problems with the applet login to the Wildfire

Smack Smack Dev
1

Hi all,

I have a problem with an applet I wrote few months ago. The applet worked fine in collaboration with Jive messenger server, but now refuses to log in to the Wildfire.

I’'m making the connection using the traditional way

XMPPConnection conn=new XMPPConnection(“server”, “port”);

/code

but when I try to login, I’'m getting the ClassCastException thrown at SASLAuthentication.java, method authenticate, line 175 (Smack 2.0).

I tried Smack 2.1, and I get the same exception from the same method, but only this time the exception was in fact thrown out of bindResourceAndEstablishSession method, at line 300 of SASLAuthentication.java file.

Then I checked out the newest Smack build from svn repository to see what the problem might be, and I found out that in bindResourceAndEstablishSession method, a Bind object is expected from the PacketCollector, but instead of that object, method is getting an IQ object! And that would be a particular IQ object created in the PacketReader, in method parseIQ, in the part where the method is determining what to do if an IQ packet was not understood (I think it’‘s either line 610 or line 625 of PacketReader.java, but I’'m betting on the second one).

I really didn’‘t want to go any further before consulting with the forum. Does anyone know what might be causing the problem? I guess it’‘s the Wildfire responding in a way that Smack doesn’'t understand?

Also, I found in nightly build that the System.getProperty(“java.home”) is used in the ConnectionConfiguration.java constructor, and I want to inform the developers that that particular property is not available in applets. I guess you’'ll want to change that so that newest Smack code could be used in applets as well

2

Hi,

I can provide a solution which works for me, but please don’'t ask me why it is working. I still asume that something is missing/wrong, maybe in SASLAuthentication.java which starts like this:

static

{

// Register SASL mechanisms supported by Smack

registerSASLMechanism(0, “PLAIN”, SASLPlainMechanism.class);

}

/code

LG

Solution:

con = new XMPPConnection(Servername, Serverport);

/* TODO why is is necessary ?? */

SASLAuthentication.unregisterSASLMechanism(“PLAIN”);

SASLAuthentication.registerSASLMechanism(0, “foo”, SASLMechanism.class);

/code

3

Thank you for your reply, I tried it for a minute and it worked, but since I already decided to stick with the old version, I’'ll wait until the newest Smack API goes out of beta to check if all issues are solved before switching to it.

Thanks again!

4

I was having a similar problem when running a Smack 2.0.0 client invoked via JNLP against Wildfire 2.5.1, and your unregister/register trick worked for me!

Does anyone know whether this issue has been addressed in later Smack versions?

Also, regarding the System.getProperty(“java.home”) is used in the ConnectionConfiguration.java constructor (as mentioned above in this thread): this caused our JNLP client applications problems connecting when I tried to upgrade to Smack 2.2.0. Has this been modified, or is there a recommended way around it?

Thanks.

–Art

5

Hi Art,

I think it is a problem with the classpath, loading the jar files or the JVM. I think that using the normal JRE causes this problem, using the JDK-JRE did if I remember right solve this problem for me.

I have no idea what’'s the difference between

%programfiles%\Java\jdk1.5.0_06\jre\bin\java.exe and

%programfiles%\Java\jre1.5.0_06\bin\java.exe

but it seems that there is one.

Maybe http://www.jivesoftware.org/community/thread.jspa?threadID=19261 also helps a bit to solve this problem without “patching” the Smack code.

LG