Openfire

also, some older issue probably havent been fixed JM-1380

Also, one cant delete a service with space in name. It throws exception and such service stays in list.

Still happens on 3.6.2 and with underscores in the service name:

I created a conference service called "conference_dev" which threw an exception, but it still shows up now in the list. Cant delete it anymore now, only get a

java.lang.NullPointerException
at org.jivesoftware.openfire.component.InternalComponentManager.removeComponent(InternalComponentManager.java:190)

today i tried to delete a conference service with a simple name "chat" and i've got similar exception

Exception:

java.lang.NullPointerException
at org.jivesoftware.openfire.component.InternalComponentManager.removeComponent(InternalComponentManager.java:190)
at org.jivesoftware.openfire.muc.MultiUserChatManager.unregisterMultiUserChatService(MultiUserChatManager.java:151)
at org.jivesoftware.openfire.muc.MultiUserChatManager.removeMultiUserChatService(MultiUserChatManager.java:276)
at org.jivesoftware.openfire.muc.MultiUserChatManager.removeMultiUserChatService(MultiUserChatManager.java:261)
at org.jivesoftware.openfire.admin.muc_002dservice_002ddelete_jsp._jspService(muc_002dservice_002ddelete_jsp.java:95)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093)
at com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:118)
at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:52)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at org.jivesoftware.util.LocaleFilter.doFilter(LocaleFilter.java:66)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at org.jivesoftware.util.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:42)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at org.jivesoftware.admin.PluginFilter.doFilter(PluginFilter.java:70)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at org.jivesoftware.admin.AuthCheckFilter.doFilter(AuthCheckFilter.java:146)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:324)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:829)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488)

assigning as a blocker to next release, so many bugs with multi-conference console code

Is there now way to manually delete the exeptioned conference service?
(yes, im experiencing this issue)

http://www.igniterealtime.org/community/message/188354#188354

I wrote 2 patches, see http://www.igniterealtime.org/community/thread/38383

also Guenter commented (after adding third patch):

I'm not familiar with the database updating process. So for running systems we should check the ofID table entry with idType=26 (SELECT * FROM ofID WHERE idType=26 if the id is 1, we must only update this and set it to 2, but if not, we must check the ofMucService table if there are two entrys with serviceID 1 (SELECT * FROM ofMucService WHERE serviceID=1 and get a new serviceID for one of them and copy all rooms from serviceID=1 to this new serviceID.

The patches should work fine for new installations but for running systems someone should write an update process which perform the above checks and corrections.

replacement of initializeDB.patch

Thanks in advance for having a look at this issue.

Split this issue in smaller issues for a better handling.

Now after spliting the issue only the createMUCService patch is related to this issue. The validation of the service name is done by creating a new JID before the service is created. The maybe thrown IllegalArgumentException and the AlreadyExistsException is handled by the admin console.

The proposed fix has one drawback: the validation of the service name of a MUC service is not done in the MUC service implementation (implementations of org.jivesoftware.openfire.muc.MultiUserChatService, where it belongs.

Guenther explained me offline that modifying the patch is not as straight-forward as it looks. Currently, the service name is persisted before it gets used in the constructor of MultiUserChatServiceImp, which in turn (indirectly) depends on the values being persisted.

We might be able to fix this by having the MUC component being initialized by the initialize-method provided by the Component interface, instead of through the constructor. This method is called when the MUC service is added to the Component manager. Moving code around like this would not only solve our original problem, but also clean up some of the MUC code.

The new patch verifies the service name on the creation of a MultiUserChatService Object. Therefore the initialization is modified to allow the creation without database access. Also a separate error message is added for already existing services.

Guenther's latest patch is cleaner than the previous one, and makes sure that every attempt to create a MUC service with an illegal name fails. The patched code works flawlessly for me, locally.