We are proud to announce the release of Wildfire 3.0.0. The new release includes an important list of new features and also a big number of bug fixes. One major new feature is support for connection managers, which improve the scalability of the server.
Download server from: http://www.jivesoftware.org/downloads.jsp
See complete change log from: http://www.jivesoftware.org/builds/wildfire/docs/latest/changelog.html
Download Connection Manager from: http://www.jivesoftware.org/wildfire/connection_manager.jsp
Excellent. I really like new plugins install, update notify, etc. feature. Btw, it should notify about server updates too? And i will be able to upgrade server directly in Admin Console? No manual downloading, extracting and upgrading in cmd?
P.S. Start Page of Admin Console still doesnt look perfect. There is some ugly white space around logo and “Wildfire” word. And maybe Logo+Wildfire could be somewhere else, e.g. at top of Administration Console.
P.S.S. found out that it looks ugly only with Firefox, with IE light part of gradient is higher so white space is not seen around logo and “Wildfire”.
Can you try a shift-reload to make sure it’'s not a browser cache issue?
Also, on new server versions – yes it will notify. However, we don’‘t have automatic upgrades yet. It’‘s definitely something we’'d like to add in the future.
Is there a changelog somewhere of what got fixed between the beta and the release?
Didnt even had to reload. Just started Firefox now and it now shows ok. My fault
The list of issues fixed between beta and final are:
- Presence changes are not being broadcasted to other connected resources
- Fix NPE while deleting items from a pubsub node
- Privacy list should implement Cacheable
- Fix PK length error when upgrading jivePrivate in MySQL using utf8
- Server is not processing IQ errors triggered by IQ requests made by the server
- DNS lookups may fail with some DNS servers
- mucConversationLog is storing room’‘s JID instead of the sender’'s raw JID
- Wildfire is not correctly sending TLS availability status for client-server to CMs
- Server Should Pass Presence from Remote Entities to All Connected Local Resources
- Presence packets sent to bare JIDs are not being sent to all connected resources
- Add commit statement to Oracle db scripts
- Fix invalid character error when upgrading Oracle database
- Wildifire is no longer able to find db upgrade scripts
- Add support for Kerberos/NTLM (experimental status)
- Add support for notifications of new server or plugins updates
- Add support for adding/removing SASL mechanisms at runtime
I understand the jm-281 code in this version is experimental, and I assume there’‘s no documentation for it since it just went in. If anyone is diving into this and wouldn’'t mind providing a short guide to get started with it and pandion (and spark, when SMACK-142 is complete), it would be appreciated.
Thanks, matt! Nice fix for the MySQL issue.
I’'ve installed it, seems to be running just fine.
I’‘ve been also working on a new client library in Python. One thing I’‘ve noticed is that on the first bind when a client is connecting, Wildfire still has some old, random resource in the to-field, while the contents of the IQ contain the new full JID. Is that how it should be? It makes a certain amount of sense, but it’'s also a little inconsistent.
No manual downloading, extracting and upgrading in cmd?[/i]
This sounds good, but where do I configure a proxy to download it or does the browser downloads it first and then uploads it to Wildfire?
No manual downloading, extracting and upgrading in
This sounds good, but where do I configure a proxy to
download it or does the browser downloads it first
and then uploads it to Wildfire?
LG – do you mean for plugin downloading? Wildfire itself will do the download. I suppose proxy support may be useful. We could let people configure that in the update manager settings if people actually need that feature.
I mean the plugin downloads. I wonder which company is not using a proxy server to access the internet and it is usually a good idea to use one instead of opening the firewall.
did I miss the 3.0 wildfire.war and connectionmanager.war files on url=http://www.jivesoftware.org/downloads.jsphttp://www.jivesoftware.org/downloads.jsp[/url]?
Maybe it can be released including JM-690.
Or are users of servlet and application servers encouraged to compile both products themself?
PS: Currently I get for Wildfire “The method getTextContext() is undefined for the type Element.” in org.jivesoftware.wildfire.launcher#launchBrowser() line 483 while build.xml runs fine.
PPS: And a connectionmanager_src.zip seems not to be available.
“However, we don’'t have automatic upgrades yet.” would probably a very bad feature as you often change a lot of things between the releases and one could call the feature “automated problem” as the admin may wonder why an error occurs which did not occur before.
Actually i didnt mean “automatic”, maybe Matt either. I just asked if it’’ possible to do upgrade via Admin Console. Manually of course.
did I miss the 3.0 wildfire.war and
There are some major problems with the WAR deployment method:
It just doesn’'t work in several app-servers such as Websphere
Plugins don’'t work since plugins currently rely on compiled JSP, which is not portable between containers.
For the time being, WAR deployments have been deprecated. If we can find time to make them work more reliably, we’'ll support them again.
PS: Currently I get for Wildfire "The method
getTextContext() is undefined for the type Element."
line 483 while build.xml runs fine.
Can you explain what you mean?
PPS: And a connectionmanager_src.zip seems not to be
Ahh, yep. I’'ll need to make some changes to the website to provide access. For now, all the connection manager code is available directly from SVN.
I did never see problems with Tomcat and the few plugins I currently use, while the new version complains that /WEB-INF/dwr.xml is missing and there are some other debug and warn messages I don’'t want to mention as you seem to be aware of those issues. So these are bad news for JWChat / JHB admins and in general for those who prefer servlet containers over stand-alone applications.
Can you explain what you mean?[/i]
I use Eclipse and there after opening the project it complains that there is this error. Does org.w3c.dom.Element really contain a method getTextContent()?
I discussed the servlet issue with Matt on the wednesday chat about two weeks ago. The solution we (well, I) came up with was to set up an apache server, let the wildfire server run separately and just let the apache proxy between its own space and the admin console (using a RewriteRule). For this feature, the admin console would have to be set up in the way to bind only to ::1 (or 127.0.0.1 for the IPv4-lovers). Matt added a feature request for this:
This way, the admin interface could still be hooked up to the regular web server, and you don’'t even need mod_jk+tomcat for it.
I want to deploy Wildfire in Tomcat, and I don’'t need an Apache or mod_jk to do this.
How does a proxy solve possible problems with plugins? I can block port 8080 and use Apache and a Rewrite Rule to make the plugins available on port 80 … but that seems to change nothing for the plugins. Or one can bind Wildfire to localhost and use a connection manager for external connections …