Bug 458286 – =net-im/openfire-3.8.0 shared group support for read-only GroupProviders (LDAP) broken

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Timo Gurr (RETIRED) 2013-02-19 13:02:55 UTC]

Since upgrading to 3.8.0 I'm experiencing the same issue the reporter on the community forums (see URL) is experiencing.

Reproducible: Always

Steps to Reproduce:
1. Use Openfire with an LDAP/Active Directory backend (perhaps not mandatory)
2. Try to edit a group and enable/disable "Contact List (Roster) Sharing"
3. Hit "Save Contact List Settings"
Actual Results:  
HTTP ERROR 500

Problem accessing /group-edit.jsp. Reason:

    Server Error
Caused by:

java.lang.UnsupportedOperationException
	at java.util.AbstractMap.put(AbstractMap.java:203)
	at org.jivesoftware.openfire.admin.group_002dedit_jsp._jspService(group_002dedit_jsp.java:176)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:547)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1359)
	at com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:118)
	at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:52)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1330)
	at org.jivesoftware.util.LocaleFilter.doFilter(LocaleFilter.java:74)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1330)
	at org.jivesoftware.util.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:50)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1330)
	at org.jivesoftware.admin.PluginFilter.doFilter(PluginFilter.java:78)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1330)
	at org.jivesoftware.admin.AuthCheckFilter.doFilter(AuthCheckFilter.java:164)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1330)
	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:478)
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:520)
	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:227)
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:941)
	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:409)
	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:186)
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:875)
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
	at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250)
	at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)
	at org.eclipse.jetty.server.Server.handle(Server.java:349)
	at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:441)
	at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:919)
	at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:582)
	at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:218)
	at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:51)
	at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
	at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
	at java.lang.Thread.run(Thread.java:722)


The corresponding bug report seems to be:
http://issues.igniterealtime.org/browse/OF-610
Which states the bug will be fixed in 3.8.1 and is also already fixed in the current nighlies. I've done a quick test with openfire_src_2013-02-18.tar.gz (Openfire 3.8.1 Alpha) and can confirm that the group editing feature works properly again.

My main concern is that it's not only affecting editing groups, but also the existing groups won't show up on the clients. Perhaps the fix can be backported or openfire-3.8.0 can be masked to prevent other users from running into this.

[Comment 1 Timo Gurr (RETIRED) 2013-03-06 16:42:37 UTC]

Openfire 3.8.1 has been released these days which fixes this issue.

[Comment 2 Sergei Trofimovich (RETIRED) 2013-03-06 19:56:42 UTC]

Pushed as:

>*openfire-3.8.1 (06 Mar 2013)
>
>  06 Mar 2013; Sergei Trofimovich <[e-mail]> +openfire-3.8.1.ebuild,
>  -openfire-3.8.0.ebuild:
>  Version bump. Upstream fixed 'shared group support for read-only
>  GroupProviders (LDAP)' by Timo Gurr (bug #458286).

I was afraid to mask 3.8.0 as was not sure 'upgrade->downgrade' path
would not corrupt openfire's base.

Thank you!