1.0 Beta 7 Released

Hi folk! 1.0 Beta 7 has been released alongside Wildfire 3.2.0. I mention the two together because it’'s important to note that Widlfire 3.2.0 is the minimum requirement for 1.0 Beta 7, and visa versa no version of the IM Gateway plugin before 1.0 Beta 7 will work with Wildfire 3.2.0. This requirement was due to some API changes that occurred within Wildfire. That said, upgrading to 3.2.0 will be a good thing all-around.

Anyway, this new release includes a lot of bug fixes as mentioned in the change log. The Yahoo transport is no longer on the roadmap for full support in version 1.0. I am focusing my energy on the other protocols that have more stable backends to work with.

Database Fixes

There are also a couple of database fixes. It turns out that some of the decisions I made with the database for 1.0 Beta 6 were poor decisions, and as a result I have restored the databases to the state they were in before 1.0 Beta 6. If 1.0 Beta 6 was your first release, you may need to do some tweaking in your database to get the INTEGER columns set to BIGINT or whatever the equivalent of that is. This effects PostgreSQL and Microsoft SQL Server. For older servers that do not support the BIGINT type, you may need to manually set up your tables to use the NUMERIC data type instead of INTEGER/BIGINT. If you are using either of these two database types and don’‘t care about losing your current IM Gateway plugin data (note that most likely you weren’'t able to use them anyway if you were having problems), you can correct the problem by connecting to your database and performing the following steps:

drop table gatewayRegistration

drop table gatewayPseudoRoster

drop table gatewayRestrictions

delete from jiveVersion where name = “gateway”

After that, you can reload the plugin from the plugins page in your admin console and the database should get recreated properly by 1.0 Beta 7.

Where Is It?

You can find the 1.0 Beta 7 release from the beta plugins. It’‘s readme and change log are also available if you’'d like to look them over before downloading. As always, download the plugin (gateway.jar) and place it in your wildfire plugins directory, overwriting whatever gateway.jar file might already be there. Soon after Wildfire will notice the change and load up the new version.

doesn’'t work for me, since apparently Wildfire 3.2 has a problem with pandion, i do need to downgrade back to gateway plugin 1.0 beta 6 - where to download?

with Spark 2.5 Beta 2 and Wildfire 3.2.0 i still see some random offline contact in my General group upon first login. If i relogin it dissapears and only online contacts are in there. And i just noticed that after closing chat windw and opening it again i see chat history grayed, but my contact nickname is replaced with UIN then.

I recently upgraded to Wildfire 3.2 and the 1.0 Beta 7…my public IMs are working, but we keep on getting this error in the logs:

2007.02.08 01:15:37 org.jivesoftware.wildfire.session.OutgoingServerSession.createOutgoingSession(Ou tgoingServerSession.java:258) Error trying to connect to remote server: msn.im.warmlyyours.com(DNS lookup: msn.im.warmlyyours.com:5269)

java.net.UnknownHostException: msn.im.warmlyyours.com

at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:177)

at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)

at java.net.Socket.connect(Socket.java:507)

at org.jivesoftware.wildfire.session.OutgoingServerSession.createOutgoingSession(O utgoingServerSession.java:253) at org.jivesoftware.wildfire.session.OutgoingServerSession.authenticateDomain(Outg oingServerSession.java:142)

at org.jivesoftware.wildfire.server.OutgoingSessionPromise$PacketsProcessor.sendPa cket(OutgoingSessionPromise.java:199)

at org.jivesoftware.wildfire.server.OutgoingSessionPromise$PacketsProcessor.run(Ou tgoingSessionPromise.java:184) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java: 650)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)

at java.lang.Thread.run(Thread.java:595)

It is not serious but it keeps coming up so you should know.

hi,

this is related to all beta plugins:

why not offering a checkbox in the wildfire admin panel (“show beta plugins”) and allowing

easier installation of those plugins? (instead of manual updating via commandline)

So it wount be to easy to crash whole server, maybe Though this is a server part and is accessible only for admin.

That looks like the msn transport isn’‘t really enabled. Wildfire thinks that : msn.im.warmlyyours.com isn’‘t handled internally and so it’'s trying to route it elsewhere.

You can’‘t use 1.0 beta 6 with wildfire 3.2.0. And you can’'t use 1.0 beta 7 with pre wildfire 3.2.0. You can actually still get beta 6 here:

http://www.igniterealtime.org/forum/servlet/JiveServlet/download/59-24335-138847 -2629/gateway.jar

I really don’‘t know how to debug the thing you are seeing with the uin vs nickname and the greyed chat history window. =/ No idea if that’‘s Spark or something else. As for the random offline contact . . . a contact that’'s online is shown as offline, or a contact that offline is shown as online?

I actually brought that up with the Wildfire peeps in the past. I would recommend bringing it up in the Wildfire forum.

jadestorm wrote:

I really don’‘t know how to debug the thing you are seeing with the uin vs nickname and the greyed chat history window. =/ No idea if that’'s Spark or something else.

Yes. That’‘s Spark. With Jabber accounts it shows username instead of Name in greyed history and in history log. Will post that in Spark’'s Beta thread.

As for the random offline contact . . .

Maybe that’‘s Spark doing again. It’‘s not really random. Well, some time ago it was other contact always showing at first login, now it’‘s the other one. I’'m saying random, because i cant understand why this contact is showing up.

a contact that’'s online is shown as offline, or a contact that offline is shown as online?

a contact that’'s offline is shown as offline (no presence icon near) in General group, though it should be in Offline group

But i have seen the “UIN in contact list” problem again. Recently i have added one new contact via Miranda. And in Spark it showed up as UIN. So i had to rename it manually.

That one hasn’'t been fixed yet: GATE-49

The only way the nickname will show up if is you’‘ve already set it and it’'s been stored in your server side OSCAR roster.

Hi Daniel,

is there any reason why you don’'t use the auto update function from wildfire to upgrade the database?

It would be easier for all users.

Uhmmm I do

Oh I think I see where you were going with that. I didn’'t aim for an upgrade in this case because:

  1. I don’‘t know if all databases support alter table syntax well (i know, for example, sybase < 12 didn’‘t support changing column types on the fly), and I didn’‘t want to "just up and delete people’'s databases")

  2. The problems folk were seeing that those lines would have fixed only affected two database types and more importantly, meant they weren’'t able to register in the first place, so the tables were already empty. Figured it would be easier to just wipe.

  3. In some cases, to support all versions of some of the databases, I’'d have to add some serious logic to the update script which I saw no point in doing.

That said, this “wipe your tables and let it recreate” crap isn’‘t going to happen anymore once 1.0 is released. I’'m only ''willing" to do that during beta stage.

Hi,

for me, there is one persisting issue missing from changelog, and that’‘s GATE-166 (contacts being removed). This happens repeatedly for me. I always add some contacts via the official ICQ client, and when I log on via IM Gateway, they’'re removed, pretty much like the first time I posted the problem. How can I help resolve this?

Cheers,

Filip

Which official ICQ are you adding from? (which version) Does the official one use groups? (did you choose a group when you added the contacts?) My theory is that the contacts that are being removed are in a “not a group” group. One thing that might help is if you add some contacts via real ICQ, have debug logged turned on in your Wildfire server, and log into ICQ via the plugin. You should see some lines in your debug.log that indicate that it’‘s “found buddy XXXX” and also somewhere along the lines start seeing where it actually removes the buddies in question. I guess what I’‘m getting at is, if possible I’‘d like to see the debug log for an ICQ login session after you’'ve previously added contacts through a real ICQ client.

I’‘m using the official ICQ 5.1 client. The groups that I originally had still remained in my contact list, so I re-used them and re-added some of the contacts into these groups. So I did exactly what you propose. The log shows very much the same what I posted first time - there’‘s the “Found buddy…” lines with info that they are not in group and therefore someone (gateway?) is removing them. I wondered, if it is gateway who’'s removing the contacts, why would it ever need to remove contacts automatically??

BTW, I post a log from one of my previous attempts. You can see that gateway receives info about a group “Rodina” and then 2 contacts (one of which is “awaiting authorization” and the other is “always authorize”). Both get removed.

2007.02.09 08:00:39 AIM got group item GroupItem for Rodina, groupid=0x1, buddies: 0x90c, 0x1311, 0x1e4d, 0x7ae0, 0x7d77, 0x643c, 0x477c, 0x692c,

2007.02.09 08:00:39 Found group item: GroupItem for Rodina, groupid=0x1, buddies: 0x90c, 0x1311, 0x1e4d, 0x7ae0, 0x7d77, 0x643c, 0x477c, 0x692c, at id 1

2007.02.09 08:00:39 AIM got buddy item BuddyItem for 223100190 (buddy 0x90c in group 0x1): awaiting auth - alias=Caroig, comment=“null”, alerts:

2007.02.09 08:00:39 Found buddy item: BuddyItem for 223100190 (buddy 0x90c in group 0x1): awaiting auth - alias=Caroig, comment=“null”, alerts: at id 2316

2007.02.09 08:00:39 AIM got buddy item BuddyItem for 308718380 (buddy 0x1311 in group 0x1): alias=Lana, comment=“null”, alerts:

2007.02.09 08:00:39 Found buddy item: BuddyItem for 308718380 (buddy 0x1311 in group 0x1): alias=Lana, comment=“null”, alerts: at id 4881

2007.02.09 08:00:39 icq: contactUpdated fkonvick:308718380@icq.pc217

2007.02.09 08:00:39 contact = 308718380, grouplist =

2007.02.09 08:00:39 Found buddy item: BuddyItem for 308718380 (buddy 0x6 in group 0x4313): alias=308718380, comment=“null”, alerts: at id 6

2007.02.09 08:00:39 Removing BuddyItem for 308718380 (buddy 0x1311 in group 0x1): alias=Lana, comment=“null”, alerts: because not in list of groups

2007.02.09 08:00:39 icq: contactUpdated fkonvick:223100190@icq.pc217

2007.02.09 08:00:39 contact = 223100190, grouplist =

2007.02.09 08:00:39 Found buddy item: BuddyItem for 223100190 (buddy 0x12 in group 0x4313): alias=223100190, comment=“null”, alerts: at id 18

2007.02.09 08:00:39 Removing BuddyItem for 223100190 (buddy 0x90c in group 0x1): awaiting auth - alias=Caroig, comment=“null”, alerts: because not in list of groups

2007.02.09 08:05:21 OSCAR bos snac response received: SnacResponseEvent: request=SnacRequest for CreateItemsCmd: 1 items: : listeners: , responses: null - SnacPacketEvent: snacProcessor=ClientSnacProcessor: lastreqid=66, requests: 66, paused=false, snacPacket=SnacPacket type 0x13/0xe, flag1=0x80: 2 bytes (id=14), snacCommand=SsiDataModAck: results=0xa (RESULT_ID_TAKEN) - FlapPacketEvent: flapProcessor=FlapProcessor: seqNum=SeqNum: min=0, max=65535, last(current)=67, flapCommand=SnacFlapCmd: packet=SnacPacket type 0x13/0xe, flag1=0x80: 10 bytes (id=14), flapPacket=FlapPacket (channel=2, seq=7183)

2007.02.09 08:05:21 OSCAR bos snac response received: SnacResponseEvent: request=SnacRequest for CreateItemsCmd: 1 items: : listeners: , responses: null - SnacPacketEvent: snacProcessor=ClientSnacProcessor: lastreqid=66, requests: 66, paused=false, snacPacket=SnacPacket type 0x13/0xe, flag1=0x80: 2 bytes (id=15), snacCommand=SsiDataModAck: results=0xa (RESULT_ID_TAKEN) - FlapPacketEvent: flapProcessor=FlapProcessor: seqNum=SeqNum: min=0, max=65535, last(current)=67, flapCommand=SnacFlapCmd: packet=SnacPacket type 0x13/0xe, flag1=0x80: 10 bytes (id=15), flapPacket=FlapPacket (channel=2, seq=7184)

2007.02.09 08:05:21 OSCAR bos snac response received: SnacResponseEvent: request=SnacRequest for DeleteItemsCmd: 1 items: : listeners: , responses: null - SnacPacketEvent: snacProcessor=ClientSnacProcessor: lastreqid=66, requests: 66, paused=false, snacPacket=SnacPacket type 0x13/0xe, flag1=0x80: 2 bytes (id=16), snacCommand=SsiDataModAck: results=0x0 (RESULT_SUCCESS) - FlapPacketEvent: flapProcessor=FlapProcessor: seqNum=SeqNum: min=0, max=65535, last(current)=67, flapCommand=SnacFlapCmd: packet=SnacPacket type 0x13/0xe, flag1=0x80: 10 bytes (id=16), flapPacket=FlapPacket (channel=2, seq=7185)

2007.02.09 08:05:21 OSCAR bos snac response received: SnacResponseEvent: request=SnacRequest for CreateItemsCmd: 1 items: : listeners: , responses: null - SnacPacketEvent: snacProcessor=ClientSnacProcessor: lastreqid=66, requests: 66, paused=false, snacPacket=SnacPacket type 0x13/0xe, flag1=0x80: 2 bytes (id=49), snacCommand=SsiDataModAck: results=0xa (RESULT_ID_TAKEN) - FlapPacketEvent: flapProcessor=FlapProcessor: seqNum=SeqNum: min=0, max=65535, last(current)=67, flapCommand=SnacFlapCmd: packet=SnacPacket type 0x13/0xe, flag1=0x80: 10 bytes (id=49), flapPacket=FlapPacket (channel=2, seq=7231)

2007.02.09 08:05:21 OSCAR bos snac response received: SnacResponseEvent: request=SnacRequest for DeleteItemsCmd: 1 items: : listeners: , responses: null - SnacPacketEvent: snacProcessor=ClientSnacProcessor: lastreqid=66, requests: 66, paused=false, snacPacket=SnacPacket type 0x13/0xe, flag1=0x80: 2 bytes (id=50), snacCommand=SsiDataModAck: results=0x0 (RESULT_SUCCESS) - FlapPacketEvent: flapProcessor=FlapProcessor: seqNum=SeqNum: min=0, max=65535, last(current)=67, flapCommand=SnacFlapCmd: packet=SnacPacket type 0x13/0xe, flag1=0x80: 10 bytes (id=50), flapPacket=FlapPacket (channel=2, seq=7232)

blink I wonder why set of events is causing that. I clearly see the group exists. The contactUpdated spawns from when the contact is added to your XMPP contact list “and then is updated”. Thing is that shouldn’‘t occur (due to some ‘‘locking’’ i have in place) unless the client makes a change after the fact. Still, something is very wrong here in that just because the contact ends up with no groups, doesn’'t mean I should nuke it altogether. I do already have an open issue for this, but this information was very handy, thank you!

I believe there’'s something amiss in my logic.