powered by Jive Software

Openfire Support needs an announcement

Or Openfire 3.6.5 release We need an announcement about 3.6.4 bug, until 3.6.5 released. Of course, i would prefer to see 3.6.5 released as soon as possible. But now, especially after Google have posted instructions how to use Openfire with Google Wave server, there are many and many new users in the forums facing the infamous bug JM-1537.

So, an announcement would be great, like “Openfire 3.6.4 has a bug (JM-1537), which prevents user to login to Administration Console right after the final setup step. One has to restart Openfire server before trying to login for the first time.”

Gato and I briefly discussed and totally agree. We’d like to come out with a minor release as quickly as possible. Gato did an initial assessment of work effort and it doesn’t look too bad. We’ll have more details in a day or so.

I think Wave is a fantastic oppurtunity that we (as a community) should jump ALL OVER.

Before the release will be build the used Tinder libary should be updated to the current snapshot version. Because the TINDER-10 bug causes an internal error for every attempt to configure a groupchat room. I’m not sure if I should create an issue for Openfire.

Best regards and good work!

So, do you have any details or we will have an announcement?

Hey Wroot,

Coincidentally, I discussed this with Guenther this morning over chat. I’ll copy the logs (because I’m too lazy to type it again )

Guus: one note, on Openfire and Tinder
Guus: as you mentioned, the version of Tinder in Openfire must be updated, before a new release of Openfire can be made
Guus: (because of the DataForms bug that you identified)
Guus: I’m close to completing Tinder 1.1, so I would like to wait until that’s done
Guus: I’ve had a couple of talks with Gato
Guus: there are two remaining issues
Guus: TINDER-4
Guus: I need info from Gato to finish that. I have an implementation ready, but Gato suggested that this would break or severely impact performance of clustering
Guus: I don’t agree with him, yet, but he’s a smart guy, and I want it to be absolutely clear what the problem is (or is not), before I commit my work
Guus: The other problem lies with Openfire logging
Guus: Gato has a good argument why he wants to see ComponentManager.getLog() back
Guus: (I removed that in Tinder 1.0)
Guus: as a counter-proposal, Gato and me agreed to replace the custom logging implementation that’s implemented in org.jivesoftware.log.* with a open source solution.
Guus: this would remove Gato’s need for having ComponentManager.getLog() back
Guus: and, additionally, we would replace custom code with a more flexible, dedicated product, that should require less maintenance… advantages all around
Guus: I’m almost ready with the implementation
Guus: (need to do the documentation, such as creating a JIRA issue for it)
Guenther: wow, sounds cool
Guus: those are the two issues that I would like to wait for, before releasing Openfire 3.6.5 and Tinder 1.1
Guus: so, now you’re up to speed
Guus: I’ll send you a patch for that logging framework later, if you would like to review it
Guus: it needed a bit of a hack, to retain all backwards compatibility
Guus: probably a good idea if we look at it again, before committing it

Ok. Thanks for the info. So now it is only two Tinder issues holding 3.6.5? But i see more issues on the 3.6.5 road map. Unless everything will be pushed to 3.6.6.

To be more precise: one Tinder issue and one Openfire issue, which we want in because of a Tinder modification.

We’ll need to update Tinder in Openfire, that’s a hard requirement (MUC and other dataform-dependent functionality will fail otherwise). From a Tinder perspective, these changes is what’s required. I didn’t look further than that, and haven’t investigated the other Openfire issues yet. If there are blockers in there (such as the MUC related issues, perhaps) we should consider waiting with 3.6.5 until that’s resolved. I’ll have a look later today.

Feel free to create the announcement. I’ve just given Key Community Members that ability since its clearly needed.

Regarding releases… I can say that Chris and I continue to work on the new build servers when we have time. I could have a working Openfire build system very soon, minus the ability to build Solaris packages. Installing a Solaris system is our last big hold up.

If you all would prefer we get it running and add Solaris later, let me know.

Feel free to create the announcement. I’ve just given Key Community Members that ability since its clearly needed.

I wonder. Maybe we should put it on the Community index page? As this is the first place everyone is coming. And with SBS you can monitor and participate without going deeper to the forums. What do you think?

If you all would prefer we get it running and add Solaris later, let me know.
Make a poll, make a poll! And seriously i would vote for adding Solaris later. In my latest poll about the platforms being used Solaris got only few percents.


Any updates on this?


…been over a year since latest Openfire release. Any “new” news on the next version?

Yeah. We’re actually getting pretty close. We’re currently in the progress of rebuilding the infrastructure of this website on new hardware. The code for Openfire is nearly done (there’s already an unofficial beta RPM floating around). I expect a new release in a couple of weeks (no promises though!)